What are the most frustrating Python hacks to unwind, rewrite, etc.? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed last year.

Improve this question

My impression of Python from the short time I've been developing with it is that it's incredible powerful and flexible, but I can't help but feel like "with great power comes great responsibility." So while I've read numerous blog posts about simple and elegant Python snippets that solve a problems, I wonder if there are design patterns or abuses of Python language features that, once built into an application or library, cause the code to be incredibly brittle and near impossible to refactor.

So the question is basically what are the most frustrating, but somewhat common, Python "hacks" or lang开发者_StackOverflow中文版uage feature abuses that someone can introduce that will cause nightmares for future maintainers of that code?

---

Excessive usage of from module import *.

Having a lot of such imports at the module you don't know where each variable came from and have to look though all imported modules. Searching doesn't help much in this case.

---

Magic that works but not always. For example, when metaclasses are abused to create a DSL. Such DSL could be suitable for most tasks but breaks horribly on a complex (unexpected by author) one.

---

Using eval or exec on user input may be the most common abuse of Python features.

---

It's not a hack, but there's been a somewhat large issue with Python 2.X's print keyword.

People would rely on print to be called for output throughout an entire project, and then when it finally came time to, say, change output to a file and to stdout, they'd have to go in and refactor all those print keywords to another custom output function.

Python 3 solved this by making print an actual function rather than a keyword (therefore automatically making output loosely coupled to the rest of the system), so if need be you can replace the original print with a new print that does more than just write to stdout.

See PEP3105 for the specific reasoning from Guido and more details.

---

..what are the most frustrating, but somewhat common, Python "hacks" or language feature abuses that someone can introduce that will cause nightmares for future maintainers of that code?

Hard to refactor:

nested list comprehensions (as in: multiple levels deep).

Most people (when learning Python) are fascinated by the power and utility of list comprehensions. This can cause a tendency to over-use them and build deeply nested, complicated ones. Most of the time the same code should have been written with simple loops for readability and maintainability. I consider three levels already too deeply nested.

--

And also (not so hard to refactor but mostly irritating):

trying to use Python as if it was another language (without it's own specific constructs); e.g.:

for i in range(len(mylist)):
    item = mylist[i]
    # do stuff with item

instead of

for i, item in enumerate(mylist):
    # do stuff with item

or even (why do you need the index anyway):

for item in mylist:
    # do stuff with item

This includes: reinventing the wheel (badly) when functionality is already (aptly named) in the rich standard library.

And type-checking, making stuff impossible to subclass, etc...

---

The single biggest issue I've come across is use of double-leading-underscore attributes. The perpetrators are practically always new Python programmers or programmers who prefer another language (in particular Java, for some reason.) Double leading underscores causes the attributes to be name-mangled (using the current class name), avoiding collisions in subclasses. It's too frequently seen as 'private', even though it isn't. (See this answer I once wrote.) The same classes are usually littered with accessors -- not properties, but regular methods called directly -- to get at these name-mangled attributes. The end result is always a horribly convoluted class that's impossible to subclass to specialize or bugfix or monkeypatch or test.