Hey guys I was wondering what is the best way to specify that certain variables/functions are not meant to be accessed outside of the class/instance by other people?
I’ve seen people start function names with single underscore, but I’ve seen others use double underscore. How should I do it? And should this also be used for fields, or only methods?
I’ve noticed double underscores used in some direct package modules, but I’m not sure if they all are written by the same person and follow the same conventions.
The official Python site seems to be written in a dialect I don’t undertsand D:
Does “data member” mean attribute? So I gues this means you can use the convention for instance variables.
From what I understood double underscores are used to allow subclasses to define attribute names already present in the base class without overwriting it.
Or maybe it’s just my engrish, though I don’t have problems with other library manuals.
The bottom line is: a leading double underscore is special to Python, and it means the actual name gets changed to something else, unique to each class, so you can have the “same name” in a subclass and it doesn’t step on the one in the parent.
The leading double underscore is Python’s way of making “private” data. It’s not truly private because you can access it anyway if you know the renaming rule (which isn’t complicated), but it’s meant to keep people from accessing it accidentally.
A leading single underscore doesn’t mean anything special to Python, but some programmers advocate its use to mark stuff that’s “mostly” private, or perhaps “protected”. This is data that’s not meant to be used outside of the class, but there’s not even a sneaky renaming trick preventing you from accessing it anyway. This is convenient for subclasses that might want to (and maybe should) access it.
Personally, I always use the _single_leading_underscore convention, and stay away from the __double_leading_underscore convention - the single-underscore method is by far the more widely-used; in fact, Panda is the first Python library I’ve come across that uses the __double_leading_underscore convention.
Hm ok. So should you use that naming convention for attributes also, or just functions (methods)?
Another question, how do you guys name your variables?
myvar
myVar
my_var
?
I use camelCase for functions, classes (MyClass), but variables just “myvar”.
I’ve seen people use camelCase for functions but my_var for variables. Is this mixing things?
As far as compound words, I would advice you just stick to the convention your leading library you write with uses (in this case, Panda). This will give you consistent code and limit the probability of having to remember which class, method or variable is named how.
I wouldn’t advice mixing underscore notation with camel case, even if only for pure consistency. Obviously, sometimes you’ll have to, if you introduce additional libraries.
Do not, however, use “myvariableisnamedlikethis”, and I’m sure it’s clear why . If you use descriptive naming (and I very much advice you do), a month after writing the code you will have a problem seeing where each word begins and ends.
I’d go with the words_separated_with_underscores convention for variable, function, and module names, and CamelCase for class names. It’s what both PEP8 and Guido recommend, so the majority of Python libraries out there use that convention - again, Panda is more the exception rather than the rule on this subject.
My mixing you mean not to use my_Name? or not use myName for some data types, and my_name for others?
Do you mean not to use long variable names? Or not use this naming method at all?
I use MyName for module and class names, myName for functions, I thought myname is recommended to separate variable names from those two.
Well my main library is Panda, so I thought I’d use the same conventions. I’ve never seen people use underscores for module names though.
Well IMHO it’s all about finding the right balance between readability, clarity and adhering to certain conventions, with the ultimate goal of being able to quickly figure out what your code does - not just you, but others as well, especially when working in a team.
“myvariableisnamedlikethis” - That’s the opposite of readability, right there . That’s like having to read an entire paragraph of text that is completely devoid of punctuation, so you don’t even know where one sentence ends and another begins.
Using names like “my_Name” is the other extreme, because “my_name” and “myName” are already sufficiently readable (i.e. you can see at once that the name is composed of two parts, “my” and “name”) - no need to overdo it .
For the sake of clarity, I would indeed use different notations to easily distinguish between classes, methods/functions and variables. But for the sake of readability, I would not use “myname” (see above).
Of course, when writing code for or with others, it might be necessary to adapt your style. But if it is a solo project, I would suggest using whatever style you feel most comfortable with.
When I write a Python package, I even start the names of its modules with an underscore, just so it couldn’t possibly clash with any of Python’s built-in modules - but maybe that’s just me .
I think the people who have made the conventions have already found the balance.
I dont think you get my question. What about “myvariable”? It still doesnt use camelCase. But it’s readable. My question to coppertop was did he mean I should use camelCase or underscores for variable names, or did he just mean not to use long names.
Why reinvent the wheel? And no, I might release it for others and generate docs with doxygen, so just doing what works for you won’t work.
Probably just you. The only case Ive seen people using underscores in module names is when having versions for python 2 and 3, by appending “_pyX” and the end of the name.
. If you use descriptive naming (and I very much advice you do), a month after writing the code you will have a problem seeing where each word begins and ends.
. That’s like having to read an entire paragraph of text that is completely devoid of punctuation, so you don’t even know where one sentence ends and another begins.
.
.