The Kinds of Bad Python

I spent a day re-doing about 30% of the functionallity of 8,600 lines of elses Java-style Python into 200 lines of cleaner Python that is also more flexible. I've observed a few major kinds of code I would call "Bad Python":

"Bad Python" is often "Old Python": using only the conveniences available in Python before 2.4/2.5. In a fast-moving language, the old ways are often going to look bad. "Bad Python" is often "Java Python": Python written in Java idioms. It's poor form to write in one language using the idioms of another, and forgoing the benefits of dynamic typing, first-class functions, native iterators, properties, and so forth "Bad Python" is often "Bad Programming": many of the practices would be poor form in any programming language.

Specific Examples

Accessor methods such as getDistance() and setDistance(), instead of using an attribute. In Python, attributes can be turned into properties later, preserving the class interface.

Asserting the type of every argument and returned value, taking up maybe 30% of the code itself and 80% of the unit test code. Checking is usually pointless because the interpreter itself will let you know if someduck didn't .quack() like a duck, and makes the code less flexible.

didn't like a duck, and makes the code less flexible. Using super-private attributes for everything, so far as to use double-underscores on each side, which are supposed to be reserved for language features.

Dozens of customising parameters in constructors, such as reversed and strip and maxlen - when passing in a general transform function would be so much more elegant and could do so much more than just reverse the strings that the class works with.

and and - when passing in a general function would be so much more elegant and could do so much more than just reverse the strings that the class works with. Using delegates where first-class function will do.

Wrapping things classes that offer no more behavior than a dict or a tuple, while adding a whole lot of intermediate code. namedtuple could help there.

Java Patterns in Python

Bad Programming

Vague and misleading identifiers (topic of future post)

Massive 'god' classes

Source files having no discernable structure

Awkward decompositions of function

Forces similar logic to be repeated in dozens of places



Prevents parts from being reused e.g. in unit tests



Prevents dependencies from being stubbed out e.g. in unit tests



Mixing logic with orthogonal aspects like error-handling and logging for a harder-to-maintain mess.

Further Reading

A controversial post about bad code that I observed on an unnamed Python project, in which I describe outdated idioms, Java-style code, and bad programming practices. [3 minutes]Fun fact: an earlier version of this post (which also disparaged the programmers - not cool) made the Reddit front page after someone posted it to r/programming , granting me 15 minutes of internet fame. I take it that controversial opinions get more attention that bland facts.Some specific examples of Bad Python eyesores:Some Bad Python comes from using certain Design Patterns that can in Python be expressed in one-line idioms, not worth writing a chapter about. Singleton Pattern? Write a module. Iterator? It's fundamental to the language. Factory Pattern? Write a functionand substitute it within tests. Flyweight Objects and Command Dispatch? Use a dictionary. A good resources is Python Patterns for patterns specific to the language. I think it's too common to assume that the Gang-of-Four Design Patterns apply to every language, not just Java/C++/C#.One can of course write bad code in any language, Python included, by doing: