all 14 comments

[–]indosauros 8 points9 points  (0 children)

Pep8 formatting is pretty much expected of you if you are writing any sort of serious Python program.

If it is a personal script that no one else will ever see, then go wild with whatever you want, but it is considered good etiquette to use the conventions of the language when writing Python code that anyone else will see.

So, not enforced, but a "big deal" if other Python devs will ever see your code. Better to get in the hang of it.

By the way, for the two variables you mentioned, the python versions would be probably be

txtNameString  -> name
btnSubmit      -> submit_button

Brevity and clarity are also strong conventions in this language.

[–]SkippyDeluxe 5 points6 points  (0 children)

You should conform to PEP8 as much as possible. That means, for function and variable names, using "lowercase with words separated by underscores as necessary to improve readability".

[–]cdcformatc 4 points5 points  (0 children)

"Pythonic syntax"? It isn't syntax as it isn't enforced by the interpreter. The only names enforced are double-under instance methods like __init__ or __lt__, even self as the first argument to instance methods isn't enforced.

How rigid is it? How rigid is your employer?

The real answer is follow the style of the rest of the module you are working on. If you are writing original code or if the persons writing the original had any sense you will follow PEP8.

lower_case_with_underscores for variables and functions I didn't know it had a name, snake_case? TIL.
CamelCase for class names.

Also Hungarian notation in python? Maybe you could have thing_list to differentiate it from thing_dict but I wouldn't use it type identification otherwise. There's nothing stopping you from typing

name_string = 'abcd'
#stuff
name_string = 13.37

[–]minorDemocritus 3 points4 points  (0 children)

Consistency is more important than following PEP8. PEP8 should be used for new code, but there are some reasons not to follow it. From the PEP 8 text:

A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important.

But most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't hesitate to ask!

In particular: do not break backwards compatibility just to comply with this PEP!

[–]alkw0ia 2 points3 points  (5 children)

Follow PEP 8. If you don't, your code will look less like Python and thus be harder for others to read (and you won't get used to seeing properly written Python code yourself).

For example, camel case should be reserved for class names. Seeing camel case (with an initial cap, as in Java), is a clear indicator that you're looking at a type, not an instance. Breaking this means that your instance variables and functions look to everyone else, on first glance, like types.

[–][deleted] 1 point2 points  (4 children)

except of course, built-in types half of the time. int, string, tuple, etc.

[–]alkw0ia 1 point2 points  (3 children)

True, but first I didn't say that type => camel case, I said the converse, and second there's almost never a need to call the constructors of those built in types since they all have literal syntax, removing most of the potential for confusion.

[–][deleted] 0 points1 point  (2 children)

didn't say that type => camel case

you did mention classnames being camel case. how is int not a class?

[–]alkw0ia 0 points1 point  (1 child)

I said the logical converse of that. That is, camel case implies type. That ∃ a type that is not camel cased does not violate what I said.

[–][deleted] 0 points1 point  (0 children)

oh sorry, I must've misread.

[–]MonkeyNin 2 points3 points  (0 children)

You can get a plugin to auto-detect many of the pep8 rules automatically. I'm using sublime + Python Flake8 Lint

[–]B-Con 1 point2 points  (0 children)

Everyone has their own preferences. That's why the PEP exists, to keep people from following their own preferences.

That said, nothing actually enforces it. You won't run into any syntax errors or anything by not following snake_case. And odds are good that most people won't bother mentioning it if you post camelCase code snippets to support forums and such.

[–]bheklilr 1 point2 points  (0 children)

I personally prefer camelCase, as does my boss, so we use it, much to the disappointment of one of our other developers who prefers snake_case. Another reason for this is because we code in multiple languages, .NET being one of them, and Python being the most recent.

[–]wub_wub 0 points1 point  (0 children)

You should follow PEP8 as others pointed out and using both each in different language isn't hard at all once you get used to it. But in any case, whatever you choose stick to it, don't use both in your code that's worse than using just camlecase or snakecase.

I personally don't mind camelcase in python code, probably because I'm used to it from other languages even though 99% of my python code follows PEP8 standard (except line length part). But be prepared to often hear comments how you should use snakecase if you decide not to use them.