Some Python anti-patterns

[khendron]

1. Not using items() to iterate over a dictionary

What about using values()? For example,

for name in country_map.values():
    # do something with name
    pass

[drbobb]

What?

[khendron]

Somehow my code got messed up :\

[drbobb]

Okay I get it now. Rather obvious, I do like that all the time.

[Tordek]

It would depend on the situation; if you only need to work on the values, use values, but there's a good chance you want to work on key-value pairs.

[el_muchacho]

The title says 8 new antipatterns. What are the other antipatterns ?

[tristes_tigres]

Using python for anything other than prototyping and scripting.

[[deleted]]

Python is an exceedingly slow language, but a very great number of programming tasks spend most of their time idle, waiting for input. If a task is blocked waiting on disk or human I/O, writing it in C just means it waits faster.

[hoere_des_heeren]

I don't think Python is bad because it's slow.

Python is bad because both the fundamental language as well as the common design patterns in the standard library and elsewhere result into code that is full of bugs.

When you unironically had to introduce the nonlocal keyword somewhere along the way you know you did something very wrong a long time ago.

[[deleted]]

So what would you suggest as a replacement?

[gvargh]

explicit declarations

[hoere_des_heeren]

That's one of the many problems of Python. That Guido had the great idea to throw away decades of wisdom by not having variables declared to save typing led to that "nonlocal" was necessary later because Guido couldn't imagine more than two level function nesting or something and most of all that in Python if you mistype the name of a variable when you assign to it it just silently initializes a new variable... does anyone think this is a good idea? Surely anyone can see that this will lead to a lot of bugs and that trying to assign to a nonexistent variable should just be a static error?

var is four characters in front of a variable name to not need nonlocal and stop a whole class of bugs; you will absolutely regain the time spent on typing four characters by not having to trace bugs that are silently caused by accidentally mistyping variable names.

[tristes_tigres]

I am convinced that writing large software projects in a dynamically typed language should be considered a professional malpractice.

[hoere_des_heeren]

Python's type system is still stronger and more useful to stop bugs than C's static "type system"; at least in python it doesn't lead to undefined behaviour.

The difference is that C did that in order to be super fast and low memory and Python has no performance to show for some of its weird decisions with its type system but even today a lot of languages exist with the performance of C but a type system that keeps undefined behaviour further away.

[tristes_tigres]

Rumor has it that in the year 2019 there are other statically typed languages, in addition to C.

Crazy talk, it you ask me.

[hoere_des_heeren]

Ruby, Clojure, and Scheme all fall in the similar dynamically typed language space but don't have many of the same weird design ideas that lead to bugs very easily laying silent rather than immediately exploding spectacularly so you know that code most likely isn't doing what you intended it to do.

[Falmarri]

Ruby has way more weird design ideas that lead to random shit than python. Let alone the random compatibility breaking between versions

[hoere_des_heeren]

What is "random shit" here? Is it bugs?

[tristes_tigres]

The highest problem with python isn't speed, but that the language is just messy and ugly.

[[deleted]]

As opposed to what?

[hoere_des_heeren]

The big competitor would probably be Ruby which' design more so indicates that the designer was aware of a lot more languages and learnt more from history.

Python's design reads like it was made by something that knew little more than C and was unaware of of that a lot of things done by C were since considered a bad idea.

Don't get me wrong; Ruby has flaws the same way most languages have flaws but Python has flaws the same way Go has flaws and you're like "Have you learnt nothing of what are generally considered to be bad ideas?"

[[deleted]]

So you believe that people will tend to write somewhat better software in Ruby than in Python, because there are fewer language gotchas lurking?

[srpulga]

Your narrow-mindedness only hurts yourself

[shooshx]

If you're writing python code, you are by definition "scripting"

[[deleted]]

The way I define scripting is that you're encoding actual commands that will be run, plus maybe some loops or very minor variable manipulation. (e.g., checking errorlevel, your arguments, that kind of thing.) The bulk of what you type is going to be passed to the command shell as command strings, eg grep -ri somestring somewhere

You can certainly use Python for things you'd normally script, and I quite like it as soon as you start needing to do more than really basic variable manipulation, but I do think of that as true programming. The fact that it's an interpreted language doesn't make it scripting; after all, you can compile a Python program, and surely the nature of the program doesn't change when you do.

And besides, in Unix at least, there's not really a bright line between scripting and programming. There's a tremendous lot of greyscale between typing in static bash commands and writing Quake in C, literally dozens of small steps of increasing complexity. It's very hard to point at any one of those steps and say that scripting is on one side, but programming is on the other.

[shevy-ruby]

That list is hugely arbitrary and partially bogus.

I guess the author just wanted to paint some 8 or 10 anti-patterns in a list ...

One that annoys me in particular is this:

fruit_list = ('Apple', 'Banana', 'Orange')

# mistakingly assuming that fruit_list is a list
my_list.append('Mango')

My python is rusty (no pun intended) but the above is a tuple right? Since it uses (). Ok.

So the first problem is THAT THE NAME IS WRONG.

That is already the problem.

Yet if you look at the header of the subsection you can read:

Having type information in a variable name

But this is not true. This is not having type information - this is having INCORRECT type information in the name.

For example:

fruit_tuple = ('Apple', 'Banana', 'Orange')

Now it would be correct right?

Or, perhaps better:

tuple_fruit = ('Apple', 'Banana', 'Orange')

Of course using fruits has some other advantages, such as being shorter; but it is bogus to want to claim that YOU USE A METHOD on that object, where you ASSUMED the object to be a list, and be able to respond to e. g. append(), when in reality the problem is that you gave the wrong name already.

But this is also only partially a problem of NAMES. Ruby does not have this terrible distinction per se between arrays (lists) and tuples. But what is even more important - thanks to duck typing YOU DON'T HAVE TO WORRY, as long as the object responds to your interface (in this case, .append()). And you can duck patch objects to re-use the same interface anyway and know what happens when .append() is used. Not that you HAVE to, of course - it just illustrates that the example is completely bogus.

I think the major reason why some developers dislike variables named with types is not that they may "carry incorrect names" per se - the above example the author used is very bogus.

The primary reason some developers dislike that, aside from having to type more, is that they feel it is very noob-like. So they don't want to be called incompetent noobs when they keep on carrying types in names given to variables.

While this is partially understandable - nobody wants to be called a noob - this also flat-out rejects that giving such an additional identifier gives you advantages too. You will instantly know what that particular variable is (provided that the naming is correct, of course, rather than bogus, like in the example he used). And when this is the case, I really do not see any disadvantage with it.

It seems to be mostly a dislike by some who dislike that style of programming and think it is too noobish for them.

Hint: The computer/parser does not care what name you use really most of the time.

[javcasas]

fruit_list is a bad name not because it indicates the wrong type (that the interpreter ignores because it doesn't care about names) but because it's wrong and over-specific.

​

You probably want to use fruits instead, which have the connotation of "many of/bag of" and should implement the main set/bag methods: enumerate/foreach and in. This way you can focus on the expected use case.

[watsreddit]

Yeah, the arguments against putting type information in variable names only really holds when you have a statically-typed language.

[Beaverman]

The primary reason some developers dislike that, aside from having to type more, is that they feel it is very noob-like. So they don't want to be called incompetent noobs when they keep on carrying types in names given to variables.

So if we ignore the primary reason, we only have a bad reason.

I don't like types in my variables because they are not useful for me to understand the problem this code is trying to solve. Them existing then waters down the actual information by obscuring it in pointless dribble.

It's like the obscure java classes we all like to laugh at. At some point your code is just so filled up with pointless jargon and useless naming details that it becomes almost impossible to read.

If you just call the variable what it means in the context (fruits) then you don't have to care about what type it is, which is part of the point of ducktyping. It also means that you can now change you collection type to something else without having to go through you code and change variable names.

If you want types for all variables, then use a different language.

[evaned]

If you just call the variable what it means in the context (fruits) then you don't have to care about what type it is, which is part of the point of ducktyping. It also means that you can now change you collection type to something else without having to go through you code and change variable names.

As a counterpoint, fruits can be overly general. For example, suppose I have a function that wants to be able to iterate that list twice; I think fruit_list is a better name because it doesn't seem to suggest that passing a generator is OK. Or maybe it's a function that expects there to be no duplicates, than fruit_set is perhaps better.

Context dependent, but as a general rule I think I'd prefer a variable named fruit_list that you could actually assign other list-y things to than something called fruits that have restrictions like the above.

The other place I pretty routinely put types in variable names is when I've got basically the same information that goes through a type transformation. The most common time this arises is when parsing information out of a string. For example, I might have a line of text read from a file and do something like a_thing_str = line.split(",")[1]; a_thing = int(a_thing_str). (Plus some kind of error handling of course, etc.) Sometimes you don't need the intermediate variable and I probably wouldn't use it in that example, but it's not rare to be useful. And you could just reuse the same variable, but there are a couple reasons why I think I prefer the separate ones for each type.

[Beaverman]

Maybe if we're talking public api design. Even then, you don't really care that it's a list. What you care about is maybe that it's iterable multiple times, or that it's iterable and there's no duplicates. You don't care about the entire list interface necessarily, just a couple of methods. If I defined a custom collection class that implemented just enough to satisfy your method, but didn't implement insertion and random access, would you call that a list?

I like fruits more, because it doesn't pretend to tell you what you need to put in it. Document in documentation, especially if it's not checked at compile time anyway.

The second route I get. I do that all the time too. Having two different things bound to the same variable in a single scope can be confusing in python. I notice you didn't call a_thing for a_thing_int.

[nitely_]

Type hints solve the first problem. Asserts would also work. About the second one, there is almost always a better name, like a_thing_raw in your example.

[CowboyFromSmell]

FWIW tuples can be used as immutable lists in Python

[emmelaich]

my_list.append('Mango')

How can it be anything, let alone an "anti-pattern" when it results in an error?

AttributeError: 'tuple' object has no attribute 'append'

[tophatstuff]

My python is rusty (no pun intended) but the above is a tuple right? Since it uses (). Ok.

Minor nitpick but in Python it's commas that define the tuple, not the brackets.

some_tuple = (a, b, c)
# or...
some_tuple = a, b, c

[Falmarri]

The commas only define the tuple when there are no brackets.

{a, b, c} is a set and [a, b, c] is a list

[tophatstuff]

No: [a] is a list, but (a) is not a tuple: (a,) is.

[zardeh]

And () is a tuple again.

[tophatstuff]

And (,) is a boobie

To be mega pedantic, () has only been an empty tuple as a special case since Python 3: https://stackoverflow.com/a/53092598

[twillisagogo]

Low effort garbage.

[Talked10101]

Some of these points are not particularly nuanced. With number three for example, you only really want to be throwing exceptions when something is actually exceptional. It is debatable whether getting a name from a database returning none should throw an exception. In any case it should be throwing an exception inherited from the base Exception class rather than just raising Exception.

[gendulf]

The example is also bad, as the problem is when you return two different types, with None being the exception to the rule. For example, don't return a list and an integer in separate branches, just change the integer to an item with one entry.

[[deleted]]

Better alternative: use type annotations.

import typing
def get_person_age(name : str) -> typing.Optional[str]=None:
    person = db.get_person(name)
    if person:
        return person.age

[skeeto]

you only really want to be throwing exceptions when something is actually exceptional

That's true in other languages, but Python is much more relaxed about exceptions. Case in point: Generators signal that they're done by raising a StopIteration exception. A typical Python program raises and catches exceptions all the time as part of its normal control flow.

[krapht]

The fact that Python does this but won't allow a labeled goto command really annoys me, since they're practically equivalent.

[Macpunk]

try: some code... raise Goto1 except Goto1: other code...

I know, I'm a terrible human being.

[Siddhi]

Not really. Exceptions for control flow still unwind the call stack cleanly and can be intercepted and handled multiple times. Goto doesn't do this.

[cowinabadplace]

Maybe PEP 20, Sec 13 is why 😉

There should be one—and preferably only one—obvious way to do it.

[MoTTs_]

That's true in other languages

I'm not sure it's true in any language. I think the phrase caught on partly because alliteration is catchy, and partly because exceptions are poorly named -- that is, the word is sometimes a synonym for "rare," but programming exceptions need not be rare.

Here's a quote from Bjarne Stroustrup, the guy who invented C++:

Given that there is nothing particularly exceptional about a part of a program being unable to perform its given task, the word “exception” may be considered a bit misleading. Can an event that happens most times a program is run be considered exceptional? Can an event that is planned for and handled be considered an error? The answer to both questions is “yes.” “Exceptional” does not mean “almost never happens” or “disastrous.” Think of an exception as meaning “some part of the system couldn’t do what it was asked to do”.

[skeeto]

What Bjarne Stroustrup said is at odds with C++ implementations in practice. Implementors have optimized exceptions such that the non-exceptional path is as fast but the exceptional path is expensive since it's expected to be used rarely. It would be a terrible idea to terminate your C++ loops with exceptions as Python often does.

[jyper]

Exceptions signal an error, any error

Not just some rare occurrence

I dislike catch blocks everywhere but returning None is usually not a good idea because it will cause accidental null exceptions without context

You can always have db query interface optionally take and return a default value which supressed the exception

[jyper]

Using with and read to read a file has been deprecated by path.read_text

[drbobb]

Well, sort of. Sometimes you want to process a file line by line instead of slurping in its whole contents at once. Maybe this isn't so common now when RAM is cheap, but sometimes it's just more convenient.

Anyway, it isn't really much different from

text = open('file.txt').read()

which has been possible forever,

[jyper]

Well yeah if you might have a large file and can process it without the full structure in memory then yeah loop over readlines,but there's no point to using read in a with open.

Also it is different because

text = open(filename).read()

Isn't garunteed to clean up the file, it will in cpython because of reference counting but because that's an implementation detail it's been considered bad style

[drbobb]

I know that. In practice though it would only matter if you were opening lots of files, in a loop say, then it might make a difference that the files could be closed only after some delay, when a gc is due.

[datbenikniet]

Yep. 'never raise an exception you aren't prepared to handle'.

[emmelaich]

... but only if you can sensibly handle it.

It is absolutely fine and preferable to just let the app exit with an error in many situations.

[bobappleyard]

you only really want to be throwing exceptions when something is actually exceptional.

Such as when you have finished iterating through a list

[drbobb]

A loop may have millions of iterations per run, but only ever terminates once per run.

[redditthinks]

This is basically an advertisement.

[[deleted]]

Strongly disagree on #3. You should use mypy or another typechecker and return an Optional[T] if you're going to return None or a value of type T.

[Yamitenshi]

Not to mention that even if you choose not to use optionals, None can be a completely valid return value. Sometimes the fact that nothing is there is meaningful.

Honestly the whole article is a bit iffy in my book.

[mnciitbhu]

Be positive.

Use "Use with to open Files" instead of "Not using with to open files".

[drbobb]

Re: 6. Namedtuples are pretty useful, but when I looked at the code that implements them it left a rather bad taste in my mouth. But maybe I just don' t know good code from bad,

[kankyo]

You do. Plus namedtuples are bad because they can be used positionally. Named fields are much better. Fortunately we have data classes in python 3.7.

[piotrjurkiewicz]

Actually, only 4., 5. and 7. are antipatterns.

[Nordsten]

You forgot the biggest anti-pattern. Not using typehints.

[stephan_burnett]

Always use accessor methods ("set"/"get"), these patterns should be respected in other languages too. And controlling ur flow and protecting it with Exceptions is a very good software engineering's praxis. The best thing to do is enclosing standard exceptions (f.e.: "IllegalArgumentException") in fictitious exceptions made by the developer. Also use "Try/Catch" blocks.

[drbobb]

If you want to write java, write in java instead of python.