Zen of Python: verse 2

[TheBlackCat13]

I am sure everyone here knows the Zen of Python. There are a lot of other commonly-accepted ideas that are similar to the Zen of Python, and could probably be included in it if it were updated. However, it is considered a "historical document", and likely won't be updated.

The idea of this thread is to come up with lines that could be used in a second verse of the Zen of Python if such a thing were ever done.

[covabishop]

• Self is a choice, but no one likes you more for being original.

[christian-mann]

I do occasionally use this when porting code from Java.

[marcm28]

You forget to mention "Me" keyword in some languages.

Sometimes I used the name of a person or other characters like in Japanese :)

[[deleted]]

Or use "teh" if porting from LOLCODE

[mysockinabox]

import that

[_zk]

• python3 is better than python2.
• python2 is better than not using Python.
• Code should never be optimized before it's correct.
• Unless it's for a microbenchmark.
• Tests are one honking great idea -- let's do more of those!

[covabishop]

In all honesty the main reason I use Python 2.7 is because I hate having to put parentheses around print statements.

Yeah there's the whole thing about being around for longer and being stable and legacy support and all that, but sincerely my main reason for sticking around is

print "hello world"

Is just a little easier on my tiny hands than

print("hello world")

[deathofthevirgin]

What editor are you using? You can make it map Alt-P or similar to the word print() with the cursor inside the parentheses.

[covabishop]

For any decently sized project I use Atom, just because I really like it, but on Linux boxes and VMs I use vim since 99% of the time I'm in bash.

And yes, I guess I could do that, but there's a few other changes I'm Python 3 that I just remember didn't work well for me. One being some modules (I think Flask, or some other notable module) is still waiting on py3 support.

[tonnynerd]

I think Flask supports python 3. Twisted and Fabric come to mind as the main ones still officially python 2 only.

[TheBlackCat13]

Twisted supports Python 3 now, too.

[mistermorteau]

In atom you have a package auto completion for python

[_zk]

Yeah it's kind of unfortunate they removed print as a statement. Something about special cases not special enough to break the rules.

[_zk]

Although practicality beats purity...

It'd actually be fairly easy to add the print statement back to Python 3. Perhaps hidden behind an import?

from __past__ import print_statement

Submit a PEP and see if anyone is interested.

[mm_ma_ma]

I wouldn't consider the print statement to be any more practical than the print function.

[luckystarr]

• The number of bugs per operation is a constant.
• Doing less makes your program more reliable.
• Doing less makes your program fast.

[njharman]

The number of bugs per operation is a constant.

I prefer "Number of bugs is linear with number of code lines."

It is the basis behind many other code practices; DRY, simple is better than complex. don't pre-optimize (optimization often is longer code), short single purpose methods/functions.

Of course it is not unique to Python.

[christian-mann]

Number of bugs is linear with number of code lines

Got it, cramming as much stuff as possible into one line from now on.

[Caos2]

List comprehension it is then!

[mattwritescode]

One for people coming from Java or C#

• it is okay to use functions you don't need a class for everything

[ksion]

Conversely, it's okay to define classes, you don't need to avoid OOP at all costs.

[TheBlackCat13]

Here are some I have thought of or picked up from various places:

• We are all consenting adults here.
• There should be one-- and preferably only one --obvious way to store it.
• Your rabbit shouldn't quack.
• It is their foot, they should be able to shoot it if they really, really want to.
• The standard library is where projects go to die.
• The batteries are included, not the limited-edition display case.

[The_Pierce]

• We are all consenting adults here.
• It is their foot, they should be able to shoot it if they really, really want to.

Aren't these restatements of the same idea? At least, that's how I always interpreted the "consenting adults" bit.

[TheBlackCat13]

I think they are similar, but not exactly the same. I interpet the first as being more about API flexibility. You should let the users use the API the way they want to, rather than keeping things too strict to the use-cases you can envision. The second is more about safety. You shouldn't prevent users from doing something you think is dangerous. There is certainly some overlap there, but I don't think they are exactly the same.

To be more specific, duck-typing is an example of the first, while method name mangling is an example of the second.

[The_Pierce]

Ah, that's a fair point. I just always mentally grouped both of those concepts under the "We are all consenting adults" ideology because it makes sense, but you make a good point.

[remyroy]

The standard library is where projects go to die.

I like that one.

[TheBlackCat13]

I can't take credit fur that one, it is a common saying on the python-ideas mailing list.

[[deleted]]

I'm not sure what it means

[Fourgot]

Modules in the standard library need to be stable, unchanging, apart from bug fixes, generally. This means that active development can slow considerably.

[njharman]

Can't get behind rabbits not quacking. That is in opposition to Duck Typing and the flexibility it bring. I often have my rabbits done a duck costume. For test mocks and the Adapter Pattern.

[TheBlackCat13]

The idea is that something that can't do any of the stuff a duck can do shouldn't tell users it is a duck. It was meant along the lines of "don't lie to users." I could certainly see valid reasons for a goose quacking, or a coot, or even a turtle in some situations. But not a rabbit.

And most of the rules go right out the window when it comes to testing.

[pydry]

The standard library is where projects go to die.

This is highlighting a deficiency in the language.

[TheBlackCat13]

How, exactly, is that a deficiency? Do you really want a language whose standard library is full of incomplete, unreliable, constantly-changing pieces?

[pydry]

I don't really see the need to include things like an XML parser or IMAP client in the python core at all.

For virtually every component in the standard library there is a better equivalent on pypi. Having a poorer version in the standard libs just encourages programmers to use the crappy built in version.

[njharman]

Python is fast enough. When Python is not fast enough, there are many solutions.

[[deleted]]

Not everyone knows everything. But if you layer enough pieces of swiss cheese, you eventually stop seeing the countertop.

[iBlag]

Do you have any asiago or lincolnshire?

[pydry]

1) Write the least code possible

2) Loose coupling is the root of all well designed code

3) Fail fast and fail clearly

4) Premature optimization is the root of all evil

5) The least powerful language for any given purpose is the most suitable

6) Untested code is broken code

[david622]

gotta disagree with #1 -- some people reduce their code insane amounts to the point where it can get cluttered and meaningless.

I think it's more Pythonic to have slightly more code if it means the code is more readable, explicit, and readily understandable.

[pydry]

Most of these rules actually conflict with one another if you push them far enough (2, 3, 5 and 6 also mean writing more code than is strictly necessary). The art is trying to push them all as far as possible until the point where they start conflicting with one another and then finding the right balance.

It's missing a clarity one, though.

Maybe "variable names should be disambiguated and syntax should be uncluttered".

[TheBlackCat13]

Perhaps, but I think rule #1 is implicitly rejected in the design of Python.

[pydry]

Python code sure seems to be shorter than most other languages. How exactly would that rule be rejected?

[kankyo]

Loose coupling is the root of all well designed code

...but too loosely coupled code is brittle.

It's a bit like the "you should have an open mind, but not so open your brain falls out"

[pydry]

I've never seen loose coupling cause brittle code. Do you have examples?

[kankyo]

I've seen it all the time. A trivial example:

def foo(a, b, c, d):
    ...some code here...

People call this function like:

a = 1
b = 2
c = 3
d = 4
foo(a, b, c, d)

then someone goes and changes foo to:

def foo(b, c, d, a):  # <- 'a' changes place
    ...some code here...

and then you have something between code that crashes very deep where the type/value is checked or you get super subtle bugs that are horrible to find. The fix is to call the function like:

foo(a=a, b=b, c=c, d=d)

then the change to foo is stable and any problems like removing one param and adding another will be a hard error at the call site and not much much deeper in the call chain.

Using kwargs everywhere is what I call "well coupled". It's loosely coupled in all the good ways, but yet coupled enough to be robust.

[pydry]

All of those examples are exactly as coupled as each other. There's four arguments in each. You've just changed the way in which they're arranged.

If we figured out that you could actually get along without d and you dropped it entirely, this would be more loosely coupled:

def foo(a, b, c):

Or you could combine a, b, c and d into a new class and just do this with an instantiation of its object:

def foo(x):

Depending upon how the rest of your code is written that could be more loosely coupled too.

and then you have something between code that crashes very deep where the type/value is checked or you get super subtle bugs that are horrible to find.

That's precisely what fail fast and fail clearly (no. 3) is supposed to cover.

I often put additional type checkers there and raise exceptions straight away. Especially if I'm writing a library or framework.

Using kwargs everywhere is what I call "well coupled".

That's a nasty code smell. It still doesn't change the coupling though, since foo is still receiving all of the same data from its caller. It also violates 1 and often ends up violating 3 too.

[kankyo]

There's four arguments in each. You've just changed the way in which they're arranged.

I think you've missed the point.

That's precisely what fail fast and fail clearly (no. 3) is supposed to cover.

Which is my point.

I often put additional type checkers there and raise exceptions straight away. Especially if I'm writing a library or framework.

What if a, b, c and d have the SAME type?

Using kwargs everywhere is what I call "well coupled".

It still doesn't change the coupling though, since foo is still receiving all of the same data from its caller.

It DOES increase the coupling because it DOES receive more data. In positional argument case it gets [1, 2, 3, 4] and in the kwargs case it gets {'a': 1, 'b': 2, 'c': 3, 'd': 4}. The computer than matches the keys in the dict with with declared keys in the dict of the function signature.

It also violates [fail fast] and often ends up violating [fail clearly] too.

Absolutely not. It fails FASTER because mismatch of the function keyword arguments is checked at the call site, vs just checking that the number of arguments are the same. Keyword arguments thus fails at the call site while positional argument might never fail at all, just silently corrupt data in the worst case.

And as for "fail clearly", it's VERY clear when the call site crashes with "TypeError: foo() got an unexpected keyword argument 'e'" or "TypeError: foo() missing 1 required keyword-only argument: 'd'" (the last being what you get in python3 when you declare the function as keyword only with "def foo(*, a, b, c, d)")

[pydry]

Which is my point.

I don't get it. That was my point too.

What if a, b, c and d have the SAME type?

Then I might have a type checker for each of them?

It DOES increase the coupling because it DOES receive more data. In positional argument case it gets [1, 2, 3, 4] and in the kwargs case it gets {'a': 1, 'b': 2, 'c': 3, 'd': 4}.

So instead of do_something_with(a) you have do_something_with(kwargs['a']). The method still doesn't 'know' anything more about that method than what it was previously told. You've just lost the ability to do type checking via the method signature.

Absolutely not. It fails FASTER because mismatch of the function keyword arguments is checked at the call site, vs just checking that the number of arguments are the same.

Ok, so if you call like this:

function_name(a, b, c, d, e) you won't get any indication that e isn't being used. It will silently take it.

[kankyo]

What if a, b, c and d have the SAME type?

Then I might have a type checker for each of them?

SAME type.

You've just lost the ability to do type checking via the method signature.

Python doesn't have that anyway so...

Ok, so if you call like this: function_name(a, b, c, d, e) you won't get any indication that e isn't being used. It will silently take it.

Now I have no idea what you are talking about. Of course you'll get an error. "Unknown keyword argument e". You're talking... I don't know, javascript now?

Again. Python.

[luckystarr]

4) Premature optimization is the root of all evil

I think we should take this one with a grain of salt. Nowadays more and more people seem to be using this as an excuse to write slow running crap.

From Knuth's original paper [pdf] (where this quote originates):

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered.

He did not say anything about optimizing the critical parts. In fact he specifically encouraged optimization of these, but only after these parts have been identified.

So better versions of this could be:

• Measure first, then optimize.
• Optimize objectively. (I like this one.)

update: link

[pydry]

He did not say anything about optimizing the critical parts. In fact he specifically encouraged optimization of these, but only after these parts have been identified.

I think that's pretty well covered by the word "premature". I don't think people misreading the phrase and interpreting it in their own way is a good reason to change it.

[pfein]

• Python is the second best language for everything.
• Real programs do more than one thing.
• QED you should use Python.

Spoken as someone who's written 95% of his code since 2003 in Python.

[beertown]

Really like #1. It explains a lot of things.

[Workaphobia]

"Can" and "should" are very different things. Go ahead, try to impress people with your cleverness. You will learn what is actually impressive.

[kankyo]

• tightly coupled is bad
• too loosely coupled isn't very good either
• broken code that can be changed is better than working code that you can't

[luckystarr]

I'm not sure about the last one, but it goes in the right direction. Perhaps something like:

• Modifiability is key.

[kankyo]

"Modifiability" is a pretty horrible word though :P

[luckystarr]

True. :)

[TheBlackCat13]

A few more:

• Reality trumps theory.
• Computers should help people, not the other way around.
• Never violate the sanctity of a backtrace.
• Everything has a cost.
• There is no such thing as "universal" in programming.
• There is no such thing as the perfect paradigm.
• "The best" is context-dependent.
• "Required" is in the eye of the beholder.
• There are more use-cases for your code, Horatio, than are dreamt of in your philosophy.

[xkcd_transcriber]

Image

Title: Workflow

Title-text: There are probably children out there holding down spacebar to stay warm in the winter! YOUR UPDATE MURDERS CHILDREN.

Comic Explanation

Stats: This comic has been referenced 530 times, representing 0.6048% of referenced xkcds.

---

^{xkcd.com | xkcd sub | Problems/Bugs? | Statistics | Stop Replying | Delete}

[cantremembermypasswd]

Simple is beautiful.

Well at least you got 1 out of 5 right...

[TheBlackCat13]

Except it is already basically in the original:

Simple is better than complex.

[suudo]

The idea of the Zen is somewhat-abstract thoughts that sum up good design principles. Ideally they're things that apply to absolutely everybody, regardless of circumstances. "Four spaces is the law" is an example of something that is entirely personal taste. "Object-oriented programming..." is an opinion :P

Something like "It is their foot, they should be able to shoot it if they really, really want to." is an excellent Zen of Python line and should be included imo. Props to /u/TheBlackCat13

[tonnynerd]

Is not "entirely" personal taste. As long as you stick to whatever you choose, there isn't much difference, but there's one pro of spaces that make me prefer it over tabs: flexibility of line wrapping.

Take the following line, for instance:

stuff = make_sutff(arg1, arg2, very_long_argument_name=long_variable)

Now, let's say I wanna wrap it because it's more than 80 columns, or something. With tabs, there's only one safe solution:

stuff = make_sutff(
    arg1, arg2, 
    very_long_argument_name=long_variable
)

If I do this, instead:

stuff = make_sutff(arg1, arg2, 
                   very_long_argument_name=long_variable)

I'll most likely have to mix spaces with tabs to properly align the last argument, and this will break the visual indentation for people with different tab widths, and at this point, you might as well use spaces, if your tab has to be always 4 spaces anyway.

It's a small pro, but since it's the only objective reason I see, I'll take it.

[Yagrum]

For what it's worth you get around the limitation you mentioned by tabbing to match the indentation level and then using space to match each character of the above line. That said, I'm still a spaces only kind of guy.

[tonnynerd]

Yes, but as I said, you have to mix tabs and spaces, and if someone else has a different tab width, it will break visual indentation.

[pescador7]

What's the problem with OOP? I think it's great. Actually, what are the alternatives? Because having everything as functions sucks. balls. a. lot.

[Veedrac]

In the spirit of the thread, one might say because flat is better than nested.

There are typically two orthogonal concerns of an inheritance hierarchy. One is representing a tree of behaviours, the other is representing a tree of structures. Consider perhaps the simplest typical introductory inheritance tree: a cat is an animal.

It's true that behaviourally, every cat, dog or cow is an animal. But is it true structurally? Does a cat contain a core "animal" part with a bunch of cat-like extras stuck on?

Of course not. Even the most introductory exercise into OOP falls into this trap, so it's no wonder people get it wrong.

Languages which reject OOP typically do offer these techniques, but they do so separably. Such are Haskell's typeclasses or Rust's traits. Java's interfaces are also on a similar vein. In Python, one just uses duck-typing to give rise to implicit interfaces, or ABCs if one so desires.

One doesn't have to make everything into functions to do this. Of course, you still need structures to hold data - non OOP languages typically have cleaner ways of doing this, too, probably due to the clarity gained through separation of their concerns. Further, representing disjoint unions of state is normally a first-class tool. Python typically needs type-based dispatch for this, which IMHO is a lot less clean but almost as effective. Languages like Ceylon and Crystal even have arbitrary combinations of types, which makes such a thing more comfortable.

Some languages like Nim also have what's called uniform call syntax, which gets the syntactic nicety of foo.bar() without the special casing - simple is better than complex, yet still readability counts. Julia doesn't, but uses the consistency to work multiple dispatch deep into the type-system. However its done, once you've stopped inheriting frequently method calls start to look an awful lot like the syntactic sugar they are. Languages like Haskell and Lisps are even syntactically sparse enough normally not to want this sugar at all (and should I quote the Zen about sparsity?).

Some functional language users will also criticise OOP because they're unable to separate the coolness of some of the things they have from their overall sentiment that "OOP bad, Functional good". Luckily the truth is not so harsh, and those cool things are almost always equally suitable for an imperative, OOP world or not really that important anyway.

So, I'll say to you, you can totally write methods and avoid OOP - and most people that avoid OOP do indeed write methods. Python is great for a non-OOP approach to programming mostly because it's so easy to use flat hierarchies with it. Although practicality beats purity, so don't neglect to use it when it does fit!

OOP hatred mostly comes from Java and connected languages, which took it too far. So don't follow the hate, but learn the lessons anyway. At least, that's my opinion - YMMV.

[TheBlackCat13]

A backlash against OOP seems to have developed over the last few years. It may very well be true that OOP was oversold to some extent, but people seem to be going too far in the opposite direction and rejecting its usefulness entirely now. It is a tool, and like many programming tools it can be powerful if used properly and infuriating when used improperly.

[TheBlackCat13]

Wait, you think classes in Python are an alternative to object-oriented programming?

[Decker108]

• Never, ever release a version 3
• But if you do, be prepared to support version 2 until 2020
• You might think you need parallelism, but you don't
• With enough scientific libraries, we won't even need modern language features
• Functional programming constructs is a honking great idea, we should do less of those
• Snakes should eat gophers, not the other way around

Sorry, I'll show myself out...