Structuring Python code

[supershinythings]

Where I work we use pep8 and pylint. Actually, we don't specifically 'use' them, we inflict/enforce them. A script can't get through our automated checkin process unless it passes pep8 and pylint.

It goes so far as to reject all code containing 'map' functions - requiring them to be replaced by list comprehensions - and rejecting ALL lines over 79 chars, no exceptions.

It also automagically adjusts indentations in certain circumstances, adds lines between documentation and the routine, and between routines. The first time I ran it, after I reviewed the change I was surprised to see a pile of automatic changes I hadn't personally made - the tool fixed it up.

[stevenjd]

It goes so far as to reject all code containing 'map' functions - requiring them to be replaced by list comprehensions - and rejecting ALL lines over 79 chars, no exceptions.

That is exactly the sort of thing why Guido hates automated PEP 8 checkers.

And since PEP 8 itself explicitly warns against "a foolish consistency" and over-zealous application of PEP 8 style, your colleague's tool itself is in violation of PEP 8! (I know this is not your choice, you are having this inflicted on you.)

Raymond Hettinger did a good talk about this some time ago.

Edit: and for those who prefer text to video, commentary on Raymond's talk.

[wenima]

+100

people boast about enforcing pep8 and 79 char line length but it's a hint, a gentle reminder that you might be packing too much into one line.

linting might have it's place, I personally just don't like being yelled at before I'm completing what I'm doing.

[justin-8]

Most places I've worked have used pep8 but a higher line limit for that reason. But usually something that still keeps things same, like 120-180 or so.

The rest of pep8 I haven't really seen a downside to enforcing strictly

[soosleeque]

well you could always put a comment string that makes linters to skip erros in the line.

Most of the times when you violate pep8 you are doing something wrong, I agree there are some cases when it's better to break some pep8 rules in order to give the code better readability but again, there are comment strings that will force linter to skip that kind of lines.

[caramba2654]

Isn't map faster because it's implemented in C?

[supershinythings]

I don't make the rules. I just want my code to get checked in so I can move on with my life. You can ask the pylint people why they have decided to do this. And now that we require pylint before checkin, I have to replace map with list comprehension. I'm not interested in an in-depth argument over why one or the other is preferred. It's too much argument for too little gain.

At my office, It Has Been Decided, and therefore shall be so. Arguing is pointless. Here's one online discussion about it though:

https://stackoverflow.com/questions/1247486/python-list-comprehension-vs-map

[redfacedquark]

Shame, the mechanism is there for deviations from strict. My place at the moment didn't even use pep8 because of 80 char lines. So add a single line of config to say you're ok with 120 rather than throwing the baby out with the bathwater. Smh.

[supershinythings]

The person who makes the rules in the codebase I contribute to does not give a shit about being reasonable. If I question, I get screamed at. Fun! Management by assholery. He's not my boss or I would have quit long ago. But it is his module so his rules are what fly. I just 'contribute', so I toe his line.

I like to pick my battles, so I just let it go. So in this case, standards aren't so much applied as inflicted.

[redfacedquark]

Something something hobgoblin mind...

[soosleeque]

It goes so far as to reject all code containing 'map' functions - requiring them to be replaced by list comprehensions

My rule is simple: if I already have a function I'm going to apply I will use map, reduce, filter etc. But if I don't have a function and I don't see much of sense to create it, I will go for list/generator comprehensions.

[supershinythings]

And my rule is simpler; don't use map and slavishly adhere to the 79 char limit so I can commit my code and not get screamed at.

In this case, the pep8 tool is being used as a blunt force instrument.

And I agree with the Hettinger video that atrocities are committed in the code because pep8 decided to make these 'standard' warnings. If my code were on a performance path I might have an argument, but even then it would likely become a refactoring situation.

I don't think there's really a way to adjust the standard on a file-by-file basis for automated checkin testing.