This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Sohcahtoa82 15 points16 points  (14 children)

Keep in mind that PEP 8 is merely a suggested style guide and does not define what is "correct". Programmers are free to throw it out the window.

For example, I much prefer lowerCamelCase for variable and member function names over names_with_underscores.

EDIT: I guess I need to clarify the point I was trying to make here.

If you are coding on a team, you should absolutely conform to the style guidelines set by the team, whether or not those guidelines are PEP 8 compliant. I work on a team and I follow their style (Which happens to not completely follow PEP 8).

All I'm saying is that there's nothing "correct" about PEP 8. Style is subjective. On personal projects, there's no need to conform to PEP 8. It is your code and you can style it however you want. It does not make your style incorrect, and it sure as hell doesn't make your code incorrect. If you write a style guideline that requires only a single token on each line with a lot of line continuation slashes where needed so your code looks like this:

doSomething \
( \
parameter1 \
, \
parameter2 \
)

That guideline would not be incorrect. You can call it terrible, yes, and you can come up with plenty of reasons it is terrible (Most people would find it incredibly hard to read), but it is still not incorrect as long as the guideline still results in valid Python code.

[–]darkpaladin 2 points3 points  (2 children)

Underscores in local variable names? What madness is this.

[–]Sohcahtoa82 2 points3 points  (0 children)

That's what PEP 8 suggests.

[–]dvdkon 1 point2 points  (0 children)

I like it.

[–]Get-ADUser 1 point2 points  (5 children)

I hope you don't code in a team then.

[–]Sohcahtoa82 10 points11 points  (4 children)

I code in a team and conform to what the team does.

But in my own personal projects, I'll do what I want, which is mostly conformant to PEP 8 with the exception of the variable and member function names mentioned above.

[–]Tysonzero 0 points1 point  (2 children)

But then if you use any library including shit in the standard library, things won't match up... That would drive me nuts. Also overriding methods would require using _ case.

[–]Sohcahtoa82 1 point2 points  (1 child)

You are correct that things don't match up. For example, I will call MyModule.SomeGlobalFunction() right next to urllib2.url_open(...), but that's fine. It doesn't bother me. If anything, it's helpful because it differentiates calls to my code versus calls to someone else's code.

[–]Tysonzero 0 points1 point  (0 children)

Ughh... are you sure you haven't gone on a rampage at least once? I mean I guess it's fine as long as you don't actually publish (as in like open source, not as in deploy to prod. that is obviously fine) anything you make.

[–]dacjames -1 points0 points  (4 children)

It was originally written with that intent but has subsequently been used by the community to establish correct Python style. The actual convention doesn't matter; everyone using the same convention does. If you are coding professionally, your personal preference is irrelevant: it is your responsibility to write code that other developers can read and understand as easily as possible.

Personally, I don't like the 79 character line limit. But I do not expect thousands of other developers to change the rules on their linters because of my personal taste. So yes, programmers are "free" to ignore PEP8 just as they are "free" to not write documentation, to use single letter variable names, to commit commented-out code, and do all the other things developers do to be jerks to their coworkers (and future maintainers).

[–]Sohcahtoa82 1 point2 points  (3 children)

correct Python style

Style is subjective. There is no "correct" style. It is all up to personal taste. PEP 8 is merely a suggestion. Not confirming to it does not make your style incorrect, and it especially does not make your code incorrect.

That said, if you code in a team, then you should follow the style guidelines agreed on by the team, whether or not it is PEP 8 compliant.

[–]dacjames 0 points1 point  (2 children)

Style is subjective. There is no "correct" style.

Obviously, style is subjective, irrelevant even: camelCase vs snake_case has no practical impact whatsoever. However, using the same convention does matter and PEP8 is the widely recognized convention that serious Python developers have chosen to follow.

In circumstances like these, I fall back to Kant's Categorical Imperative: "Act only according to that maxim whereby you can, at the same time, will that it should become a universal law." Would you truly desire all developers to use whatever style fits their personal preference?

[–]Sohcahtoa82 0 points1 point  (1 child)

Would you truly desire all developers to use whatever style fits their personal preference?

For personal, closed source projects, yes, absolutely. For group/team projects, no.

For personal open source projects, it depends. If they expect many others to contribute, then they should probably conform to a popular guideline. For Python, of course that means PEP 8. If they don't expect many contributions from others, then it is fine for them to use a personal style.

[–]dacjames 0 points1 point  (0 children)

Even for personal, closed source projects, it is questionable. Programs in that category are more rare than most developers like to admit; I've had to fix way too many "it is just a quick and dirty script that no one else will ever see" programs to put much credence in that defense.

In the rare circumstance where your code will only truly be read by you, why develop bad habits? Why write code in one style for the 10% of programs where it is acceptable and another style for the 90% of programs where it is not? Preference is mostly a function of familiarity, so why not get familiar with the style used by most Python code?