views:

429

answers:

6
+2  Q: 

Python Notation?

I've just started using Python and I was thinking about which notation I should use. I've read the PEP 8 guide about notation for Python and I agree with most stuff there except function names (which I prefer in mixedCase style).

In C++ I use a modified version of the Hungarian notation where I don't include information about type but only about the scope of a variable (for instance lVariable for a local variable and mVariable for a member variable of a class, g for global, s for static, in for a function's input and out for a function's output.)

I don't know if this notation style has a name but I was wondering whether it's a good idea not to use such a notation style in Python. I am not extremely familiar with Python so you guys/gals might see issues that I can't imagine yet.

I'm also interested to see what you think of it in general :) Some people might say it makes the code less readable, but I've become used to it and code written without these labels is the code that is less readable for me.

+2  A: 

It'll depend on the project and the target audience.

If you're building an open source application/plug-in/library, stick with the PEP guidelines.

If this is a project for your company, stick with the company conventions, or something similar.

If this is your own personal project, then use what ever convention is fluid and easy for you to use.

I hope this makes sense.

Alan
+6  A: 

(Almost every Python programmer will say it makes the code less readable, but I've become used to it and code written without these labels is the code that is less readable for me)

FTFY.

Seriously though, it will help you but confuse and annoy other Python programmers that try to read your code.

This also isn't as necessary because of how Python itself works. For example you would never need your "mVariable" form because it's obvious in Python:

class Example(object):
    def__init__(self):
        self.my_member_var = "Hello"

    def sample(self):
        print self.my_member_var

e = Example()
e.sample()
print e.my_member_var

No matter how you access a member variable (using self.foo or myinstance.foo) it's always clear that it's a member.

The other cases might not be so painfully obvious, but if your code isn't simple enough that a reader can keep in mind "the 'names' variable is a parameter" while reading a function you're probably doing something wrong.

Steve Losh
+1: Give up Hungarian notation. The extra letters are wasted. Just name the variables with their purpose -- forget scope, type, size, weight, color or any other attributes.
S.Lott
Google's style guide recommends this too: http://google-styleguide.googlecode.com/svn/trunk/pyguide.html
Otto Allmendinger
+4  A: 

I violate PEP8 in my code. I use:

  • lowercaseCamelCase for methods and functions
  • _prefixedWithUnderscoreLowercaseCamelCase for "private" methods
  • underscore_spaced for variables (any)
  • _prefixed_with_underscore_variables for "private" self variables (attributes)
  • CapitalizedCamelCase for classes and modules (although I am moving to lowercasedmodules)

I never liked hungarian notation. A variable name should be easy and concise, provide sufficient information to be clear where (in which scope) it's used and what is its purpose, easy to read, concerned about the meaning of what it refers to, not its technical mumbo-jumbo (eg. type).

The reason behind my violations are due to practical considerations, and previous experience.

  • in C++ and Java, it's tradition to have CapitalizedCamel for classes and lowercaseCamel for member functions.
  • I worked on a codebase where the underscore prefix was used to indicate private but not that much private. We did not want to mess with the python name mangling (double underscore). This gave us the chance to violate a bit the formalities and peek the internal class state during unit testing.
Stefano Borini
+5  A: 

Use PEP-8. It is almost universal in the Python world.

Marius Gedminas
Please please please do this. The whole point of having a standard defined so early on is so people would follow it. Do you really have to go off on a tangent and name things in your own way? I did this myself but quickly thought better of it when people in IRC wouldnt look at my code at all.
jkp
+3  A: 

There exists a handy pep-8 compliance script you can run against your code:

http://github.com/cburroughs/pep8.py/tree/master

rizumu
+1  A: 

You should simply be consistent with your naming conventions in your own code. However, if you intend to release your code to other developers you should stick to PEP-8.

For example the 4 spaces vs. 1 tab is a big deal when you have a collaborative project. People submitting code to a source repository with tabs requires developers to be constantly arguing over whitespace issues (which in Python is a BIG deal).

Python and all languages have preferred conventions. You should learn them.

Java likes mixedCaseStuff.

C likes szHungarianNotation.

Python prefers stuff_with_underscores.

You can write Java code with_python_type_function_names.
You can write Python code with javaStyleMixedCaseFunctionNamesThatAreSupposedToBeReallyExplict

as long as your consistant :p

ascotan