Why and how "there is only one way to do something"?

[bonono]

This would have the unfortunate side effect of only allowing changes to
Python that allowed users to do things which are currently impossible.

Since Python is Turing-complete, this would effectively inhibit all
further changes to the language.

I don't quite understand the above.

Would you, say, remove "for" loops because they could be written as
"while" loops. Don't forget the word "obvious" that appears in that
catchphrase ...

If every "for" usage can be done with "while" and that "while" is the
preferred way, why not ? As I said, the problem is that "obvious"
really is subjective in many case. And if it really is obvious, it
really is obvious and I doubt there would be that much disagreement. I
am a left handed and any time I use something that is designed to be
right-handed, I have the same feeling too, luckily there isn't that
much such thing in real life.

 

[bonono]

It says that Python is already adequately expressive to allow it to
solve all solvable problems: more briefly, "Python can already do
everything". Hence there is no need to change the language.

Of course I use this as a /reductio ad absurdum/ to try to show you the
falsehood of your position. Sadly I fear this will simply result in
another response which won't move the dialogue forwards.

Still don't quite understand what you intend to say.

It seems to me you either don't understand the words "obvious" and
"preferably".

My intepretation of "obvious" is that 99 out of 100 people would
immediately see that "this is the way to do it". I am not sure your
"right meaning" of it.

I believe I have also suggested that the phrases of the Zen aren't to be
taken too literally. You seem to distinguish between "obvious" meaning
"obvious to Steve but not necessarily to me" and "really obvious"
meaning "obvious to both Steve and me". So where does the subjectivity
creep in? And are you going to spend the rest of your life arguing
trivial semantics?

Again, don't quite understand what you what to say.

 

[Carl J. Van Arsdall]

I think comparing "for" and "while" loops in python is problematic.
Although yes a "for" loop could be done with a "while" in python a "for"
loop shouldn't be used for general looping, the "obvious" case for a
"for" loop is to iterate though a list or something similar to that. I
wouldn't typically use "while" loops for that, and although it could be
done, if you were familiar with python using a "for" loop would be the
most obvious. I think it really is obvious in most cases with python.

Although, obvious to whom is a good question. If you don't know the
language very little will be obvious to you, however one who is familiar
with python (rtfm) would know which cases should obviously use "while"
and which cases should obviously use "for"

2cents

--

Carl J. Van Arsdall
(e-mail address removed)
Build and Release
MontaVista Software

 

[Aahz]

(Part of) Python's credo (which you can read in context by typing

import this

at an interactive command prompt) is "There should be one (and
preferably only one) way to do it".

Actually, I've gotten used to doing

python -c 'import this'

 

[Xavier Morel]

Actually, I've gotten used to doing

python -c 'import this'

Which can be built even more easily with

$ python -m this
(no quotes needed btw)

It's usually useful to pipe it through grep too, in order to get only
the piece of zen knowledge you need.

 

[Steve Holden]

Actually, I've gotten used to doing

python -c 'import this'

Faster:

python -m this

regards
Steve

 

[Rocco Moretti]

The point is again, "obvious" is not so obvious sometimes. You seem to
be assuming that anyone that use style different from you is
intentionally doing it and that your style would first come to their
mind but they don't use it, for the sake of proving that they are
smart.

My take on it is that "obvious" is intended to be prescriptive, not
descriptive. (Note that in the Zen it is phrased "There *should* be
....".) It describes what Python aspires to, not what it is. If the
currently preferred method is not "the one obvious way", steps should be
taken to make the preferred way "the obvious way" (i.e. the way that you
reach for first, when you want to "do it").

Keep in mind that the Zen was written at a time when there was a certain
amount of "Perl vs. Python deathmatch" feeling in the air. That line in
the Zen was a reaction to Perl's "There's more than one way to do it
(TMTOWTDI)."

Perl took the view that flexibility was a virtue to be praised above all
others, and allows and encourages (or at least used to) different ways
of doing things. I don't think a syntactic construct was excluded from
Perl for the sole reason "well, we already can do that with this
construct ..."

Python, in part due to a backlash to the Perl philosophy, emphasized
clarity and readability. There are *many* constructs which have been
excluded from Python just because they weren't any clearer than what is
already in the language. (Once a language is "Turing complete", anything
you can program a computer to do, you can use that language to do. There
is no guarantee that it's short or pretty, though.) That's what the "one
obvious way" refers to - the clearest, most readable way of expressing
what you want to accomplish.

In this "obviousness", there is (often) little consideration for what
other languages you previously might have used, or might be trying to
drag idioms from. As an absurd analogy, if you were born and grew up in
a country with a crazed totalitarian leader who, under penalty of death,
made you turn around three times while hopping and whistling the
national anthem before you sat down for dinner, it might be "obvious" to
you that one must turn around three times, hopping and whistling before
sitting down for dinner. However, if you move out of that country to,
say, the Netherlands, for instance, you no longer need to
hop-whistle-turn, and your new countrymen will look at you strangely if
you do. That's not to say you can't hop-whistle-turn if the fancy
strikes you, but in any practical setting, people will expect you do the
simple, "obvious" thing -- just sit.


BTW. People who are quick to bring up the Zen (and I'm as guilty as
others at times) should also keep in mind that the Zen is found under
the *humor* section of the Python website. It's not an actual design
document, it's just a surprisingly intuitive description of Python's nature.

 

[bonono]

Although, obvious to whom is a good question. If you don't know the
language very little will be obvious to you, however one who is familiar
with python (rtfm) would know which cases should obviously use "while"
and which cases should obviously use "for"

So far, I haven't seen any for/while argument on this thread. So their
usage seems to be obvious to most if not all(which one to choose).

reduce/map/filter obviously is not the obvious way for people from C or
other imperative background, and may not be for those who never program
before.

However, for those who know these functions as well as the for style,
it is no longer so obvious(in the sense which is better/clearer). It
would then become a style choice. It can also be some policy choice,
like because an organisation want to be certain that newly hired
programmer(who would most likely be people from imperative background)
can pick up the program easily, it is better not to use the FP style.

 

[Simon Brunning]

Faster:

python -m this

So, there's two ways to do it. ;-)

 

[Brian Cully]

C-programmer learning python :

Hi, where is condition ? true : false

someone prefer the if/else statement type:

Can't you see that the following is much more readable, stupid(well not
the exact word but tone in such a way like words of messy or elegant
etc.)

if condition:
true
else:
false

Except that the latter isn't an expression, and thus can't be used
inline.

Where you can do: somevar = condition ? true : false

You have to do, instead:
if condition:
somevar = true
else:
somevar = false

It may not seem like a big deal to you, but this approach has a number
of problems, depending on what you're doing. When you're using the
ternary operator you avoid temporary variables, and if you use it a
lot, that's much less that you have to keep track of. It's embeddable
in other arbitrary code, so you can move it around as you need to, or
just keep the morass of side-effects down.

Readability isn't just line-by-line, but a whole work. if/else may work
well most of the time, but sometimes it's ugly, and even though it's
obvious, it doesn't necessarily make your code easier to read.

 

[Tim Peters]

[Steve Holden, to bonono]

...
I believe I have also suggested that the phrases of the Zen aren't to be
taken too literally.
Heretic.

You seem to distinguish between "obvious" meaning "obvious to Steve
but not necessarily to me" and "really obvious" meaning "obvious to both
Steve and me". So where does the subjectivity creep in?

For those who have ears to hear, it's sufficient to note that:

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

is followed by:

Although that way may not be obvious at first unless you're Dutch.

And are you going to spend the rest of your life arguing trivial semantics?

A more interesting question is how many will spend the rest of their
lives responding ;-)

perfect-dutchness-is-a-journey-not-a-destination-ly y'rs - tim

 

[Aahz]

Faster:

python -m this

Only in Python 2.4 and later:

starship:~> python2.3 -m this
Unknown option: -m
usage: python2.3 [option] ... [-c cmd | file | -] [arg] ...
Try `python -h' for more information.

Why, oh why, do so many people on this newsgroup only consider the latest
version "correct"? I've been guilty myself on occasion, but I do try to
label my suggestions with version warnings.

 

[Steve Holden]

So, there's two ways to do it. ;-)

You want a clip round the ear?

regards
Steve

 

[Steve Holden]

Faster:

python -m this

Only in Python 2.4 and later:

starship:~> python2.3 -m this
Unknown option: -m
usage: python2.3 [option] ... [-c cmd | file | -] [arg] ...
Try `python -h' for more information.

Why, oh why, do so many people on this newsgroup only consider the latest
version "correct"? I've been guilty myself on occasion, but I do try to
label my suggestions with version warnings.

Why, oh why, do people who don't run the latest version assume that a
solution for a more recent version labels their original solution
"incorrect"?

Dammit, the only word in my post apart from the command was "faster".
Not "wronger" or "righter" or even "better". So climb down off that high
horse. Sheesh.

regards
Steve

 

[Dave Hansen]

On Thu, 15 Dec 2005 14:57:18 +0000 in comp.lang.python, Steve Holden

[...]

Would you say

do:
suite
while condition

or what? Basically do ... while and do ... until most naturally put the

Works for me, though I wouldn't cry if the "while" was changed to
"until" to make the difference between this form and the "while" loop
more obvious. I don't think there's a good argument for _both_
do-while and do-until, but one or the other would be useful.

The biggest objection I see is the addition of one or two more
keywords, but I don't recall using "do" or "until" as a name in any of
my programs...

test after the loop body (suite), and it's difficult to think of a
consistent and natural syntax for expressing the construct. Not that
this stopped lots of people from coming forward with their personal
favourites ... some suggestions even offered "n and a half" looping
possibilities.

Syntax is the problem? Specifically the position of the condition
after the loop body? How do you explain the syntax of the new Python
ternary operation, with the test in the middle, even though it
logically has to be done first?

Right now, I tend to write these loops something like

while 1:
do_stuff()
if exit_condition: break

which offends my sense of aesthetics, but it works.

Regards,
-=Dave

 

[Dan Sommers]

$ python -m this
(no quotes needed btw)

*Three*. *Three* ways to do it: import, -c, -m, and an almost
fanatical devotion to the Pope.

It's usually useful to pipe it through grep too, in order to get only
the piece of zen knowledge you need.

That's just wrong. [throws hands and arms up in [mock] disgust]

Enlightenment does not come in discrete pieces, to be learned one at a
time, to be applied selectively.

Regards,
Dan

 

[Dennis Lee Bieber]

Right now, I tend to write these loops something like

while 1:
do_stuff()
if exit_condition: break

which offends my sense of aesthetics, but it works.

The implication of a test ("while <anything>") which does not
control the loop is the offender...

The minimalist loop in Ada is:

loop
pre-condition stuff
exit when condition -- when condition is optional, but <G>
post-condition stuff
end loop

while and for became variants of the above:

while condition loop
rest is same structure
end loop

for lv in range..spec loop
rest is same structure
end loop
--

 

[Tolga]

OhmiGod! I posted this message this morning and when I came home, I
said myself "umm, lemme check it" and I cannot believe what I see... 37
threads!

As long as Python is supported by such a hardworking and enthusiastic
community, I'm sure that he (=Python) will become the nightmare of many
other languages.

Thank you all...

 

[Chris Smith]

bonono> What I don't quite understand is, if it is "obvious",
bonono> whether there is a Zen, people would still code it that
bonono> way(unless of course they want to hide it from others or
bonono> make it difficult to understand on purpose), there won't
bonono> be any argument of "which one is the obvious way". And if
bonono> there is an argument(or disagreement), which one is the
bonono> obvious ?

Python seems to strive for consistency in all levels. The 'obvious
way' is the one with the greatest stylistic cohesion across the rest
of the language.

When you delve into a new realm, as I have lately been investigating
the logging module, consistency helps lower the learning curve; we're
re-cycling as much knowledge as possible.

bonono> I think it is more like there is a preferred way, by the
bonono> language creator and those share his view.

You're right. There is no way to factor out the subjective nature of
what becomes orthodoxy. Guido's taste, while perhaps imperfect, still
stands out. Props.

-Chris

 

[Mike Meyer]

The point is again, "obvious" is not so obvious sometimes.

You keep leaving out the context. We're writing *python*. What's
obvious when you're writing python won't be when you're writing
FORTRAN, or Scheme, or O'Caml, or Eiffel, or .... Generally (not
always, I'll admit), when you're writing python, there's one obvious
way to do something. If not, there's a good chance you're not writing
python, you're writing something else with python syntax.

For most of the question I see asking here, they are from another
language background and their obvious way is what they are asking for
that they cannot find in python.

Back in the dark ages, when computers had entire rooms, if not
buildings, dedicated to them, I worked the support desk at a large
state university. Most people learned FORTRAN as a first language, and
then some of them went on to other languages. The standing observation
was that "You can write FORTRAN in any language." This is because
people would write FORTRAN constructs no matter what language they
were using. If the language had a goto, they'd write:

if not condition: goto after
# if body
after:

If the language didn't have a goto, they'd write:

if not condition:
else:
# if body


And then they'd complain if the grader marked them down for doing
this kind of thing.

People coming from other languages trying to write the obvious way
from that language in python are doing the exact same thing as the
people who wrote the above fragments were doing: writing <fill in the
blank> in python. It's not as obviously wrong because the languages
are more recent than FORTRAN, but it's just as wrong.

<mike