python idioms : some are confusing

V

Vineet

Amongst the python idioms, how the below-mentioned make sense?

## There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.

--- In programming, there can be a number of ways, equally efficient, to do certain thing.

## Although never is often better than *right* now.

--- How come "never" is better that "right now" ?


Any thoughts?...
 
A

alex23

Amongst the python idioms, how the below-mentioned make sense?
## There should be one-- and preferably only one --obvious way to do it.
--- In programming, there can be a number of ways, equally efficient, to do certain  thing.

This isn't talking about your Python code as much as about Python
itself. For example, in Python 2.x you can use either `open` or `file`
to open a file, with `file` being a factory function for creating file
objects, and `open` using it internally. In Python 3.x, `file` is no
longer a built-in, as it produced a point of confusion as to which was
the one obvious way to open a file.
## Although never is often better than *right* now.
--- How come "never" is better that "right now" ?

It's better to not add a language feature than it is to add it poorly,
especially when you endeavour to provide backwards compatibility as
much as possible within major versions.
 
C

Chris Rebert

Amongst the python idioms, how the below-mentioned make sense?

These aren't idioms (that term has a specific technical meaning in
programming); they're *way* too abstract to be idioms. "Design
principles" or "design guidelines" would be a better description.
## There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.

--- In programming, there can be a number of ways, equally efficient, to do certain thing.

Yes, but that brings with it the cost of having to understand/learn
them all, because you'll encounter them when
reading/maintaining/modifying others' code. And you'll have to
evaluate them all to choose which one you should use (which might even
vary from moment to moment depending on the circumstances). And you'll
have to watch out for subtle variants that actually do something
significantly different. Better to keep things simple in the X% of
cases where the differences don't matter enough, and save those brain
cycles for other, more important things.

See also: the so-called "paradox of choice".
Further reading: the criticisms on
http://c2.com/cgi/wiki?ThereIsMoreThanOneWayToDoIt
## Although never is often better than *right* now.

--- How come "never" is better that "right now" ?

Because "right now" is so quick that it was likely hastily hacked
together and thus of poor (or at least lesser) quality.

Cheers,
Chris
 
C

Chris Angelico

I'm responding to the OP here, not to Alex, but I'm quoting his text
to expand on it. :)

This isn't talking about your Python code as much as about Python
itself.

The "it" in the zen there refers to some programming task. For
instance, there's only one obvious way to increment an integer:

spam += 1

Python's philosophy is to have just that, and to not trouble itself
with "spam++" and "++spam" and the distinction between them. As a C
programmer, I'm quite accustomed to them, and know what they mean, but
not everyone does. And don't get me started on "&&" vs "and" in PHP...
Python is a simpler and cleaner language for not having superfluous
operators.
It's better to not add a language feature than it is to add it poorly,
especially when you endeavour to provide backwards compatibility as
much as possible within major versions.

The compatibility issue is the thing here. It's better to get
something good now rather than dither for another fifty years, because
the longer you dally, the more code will be written using third party
libraries. But it's better to not put it into the standard library at
all than to put in a messy API that now can't be changed because
code's using it.

The Zen of Python is a whole lot of tradeoffs and ideas. Several of
them balance each other directly. Some, while not contradicted in the
Zen itself, are still violated at times in the language and/or stdlib.
They're principles, not laws, and need to be read with the
understanding that people who write code are intelligent, thinking
beings (though a quick look at TheDailyWTF.com proves that this is not
universal).

ChrisA
 
S

Steven D'Aprano

Amongst the python idioms, how the below-mentioned make sense?

They're not Python idioms. Idioms are common pieces of code, like looping:

for item in sequence:
do_something

What you have quoted are parts of the Zen of Python, which is
deliberately named. Zen koans are notorious for being contradictory and
impossible to understand.

As Terry Pratchett wrote:

In the second scroll of Wen the Eternally Surprised a story
is written concerning one day when the apprentice Clodpool,
in a rebellious mood, approached Wen and spake thusly:
"Master, what is the difference between a humanistic, monastic
system of belief in which wisdom is sought by means of an
apparently nonsensical system of questions and answers, and a
lot of mystic gibberish made up on the spur of the moment?"
Wen considered this for some time, and at last said: "A fish!"
And Clodpool went away, satisfied.
-- (Terry Pratchett, Thief of Time)


So be careful about over-interpreting the Zen of Python. Half of it is
meant to followed seriously, half is meant as a joke, and half is meant
as a guideline only.

## There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.

This tells us that for any task you might want to do in Python, there
should be some way to do it which is obvious. It is not enough that there
is some (hard to find, convoluted) way to do it, it should be obvious.
And while it isn't forbidden to be two or more obvious ways, it is better
if there is only one.

The joke is that even this single sentence goes against its own advice.
There are at least three obvious ways to put a parenthetical aside in a
sentence:

There should be one--and preferably only one--obvious way to do it.
There should be one -- and preferably only one -- obvious way to do it.
There should be one (and preferably only one) obvious way to do it.

The author of the Zen deliberately choose a fourth, non-obvious way.

Finally, the second line warns that although Python has many obvious ways
to solve things, they may only be obvious to the creator of Python, Guido
van Rossum, who is Dutch.

--- In programming, there can be a number of ways, equally efficient, to
do certain thing.

The Zen refers to the philosophy that Python the language should provide
an obvious way to solve a problem. The emphasis is on the *obvious* part,
not the *one* part.

## Although never is often better than *right* now.

--- How come "never" is better that "right now" ?


Solving a problem in the language -- adding a new language feature such
as a keyword, new syntax, a library, etc. -- should only be done when
that new feature brings more benefit than problems. But sometimes a new
feature might bring more problems than benefits. In this case, it is
better to *never* solve that problem *in the language* than to add a
feature that solves the problem badly and causes more problems than it
solves. E.g. multi-line lambdas.

The problem is that once you add a feature to the language, it becomes
almost impossible to remove it. You are stuck with it nearly forever, or
at least for many years. So better to not add it than to be stuck with a
bad feature.
 
S

Steven D'Aprano

This isn't talking about your Python code as much as about Python
itself. For example, in Python 2.x you can use either `open` or `file`
to open a file, with `file` being a factory function for creating file
objects, and `open` using it internally. In Python 3.x, `file` is no
longer a built-in, as it produced a point of confusion as to which was
the one obvious way to open a file.

I don't think that's the reason. I think the reason is that moving the
built-in file into the _io library gives the developers a lot more
flexibility in how they handle text and binary files. E.g.:


py> open('junk', 'w')
<_io.TextIOWrapper name='junk' mode='w' encoding='UTF-8'>

py> open('junk', 'wb')
<_io.BufferedWriter name='junk'>

py> open('junk', 'wb', buffering=0)
<_io.FileIO name='junk' mode='wb'>


The open() function now can return three (or more?) types instead of
having a single built-in type handle all cases.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top