Omit using double underscores for variable names and imports

[RichardPflaum]

Hi, I might be interested in contributing to this project.
I just had a look at some of the files and have a few questions about your conventions.
I'm wondering why you are importing the modules with double under scores, e.g.

import numpy as __np__

I think this might be causing problems, since double underscores are kind of reserved for python's magic methods.
As far as I know, the normal way to do it would be just importing numpy as np.
I have a similar issue with the double-underscores around the class variables.
In particular I was looking at the Aperture class, using self.__scale__, self.__aper__ etc.
I would consider renaming the class variables so they have a single leading underscore.
That way they are marked as private, but not treated specially by the interpreter.
Also I think the project could profit from using a linter, e.g. pylint to keep the code following the python conventions described in PEP8 at least to some level.

[Xing Fan]

Hi Richard, Thanks for the email. Good ideas! I will take your advice when I am reworking on this module! Or any other new projects! When I was doing this, I just trying to hide the method from the end-user, making the search easier. Xing RichardHuenermann <[e-mail]> 于2019年12月18日周三 上午7:48写道：

…

Hi, I might be interested in contributing to this project. I just had a look at some of the files and have a few questions about your conventions. I'm wondering why you are importing the modules with double under scores, e.g. import numpy as __np__ I think this might be causing problems, since double underscores are kind of reserved for python's magic methods. As far as I know, the normal way to do it would be just importing numpy as np. I have a similar issue with the double-underscores around the class variables. In particular I was looking at the Aperture class, using self.__scale__, self.__aper__ etc. I would consider renaming the class variables so they have a single leading underscore. That way they are marked as private, but not treated specially by the interpreter. Also I think the project could profit from using a linter, e.g. pylint <https://pypi.org/project/pylint/> to keep the code following the python conventions described in PEP8 <https://www.python.org/dev/peps/pep-0008/> at least to some level. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#35?email_source=notifications&email_token=AAUIRBPWNQ2METNMPFJPSQDQZJA6DA5CNFSM4J4NB3QKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IBMEXUQ>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUIRBOENO35HFXKTW4TUVLQZJA6DANCNFSM4J4NB3QA> .