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

[Tolga]

As far as I know, Perl is known as "there are many ways to do
something" and Python is known as "there is only one way". Could you
please explain this? How is this possible and is it *really* a good
concept?

[Steve Holden]

Ben Sizer wrote:

Steve Holden wrote:

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 ...

Interestingly - and somewhat related to this - the other day I was
looking for a do..while or do..until loop in the Python language
reference, thinking that there must be a statement for it, since
semantically they're distinct from while loops. I had a use case that
could have been slightly simplified by such a construct. The fact that
I didn't find one seemed slightly strange at first, coming from a
C/Pascal background, although it did occur to me that I've used Python
for years now and not noticed this lack before.

You'll find it's exercised the group frequently from time to time.
Without wishing to stir the whole thing up again, the essence of the
problem is the unnatural fit with Python's suite design.

Would you say

do:
suite
while condition

or what? Basically do ... while and do ... until most naturally put the
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.

In the end nobody managed to convince Guido that a suitable solution was
readily to hand, so nothing happened.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Carl J. Van Arsdall]

bo****@gmail.co m wrote:

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 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
cv*********@mvi sta.com
Build and Release
MontaVista Software

[Aahz]

In article <ma************ *************** ************@py thon.org>,
Steve Holden <st***@holdenwe b.com> wrote:

(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'
--
Aahz (aa**@pythoncra ft.com) <*> http://www.pythoncraft.com/

"Don't listen to schmucks on USENET when making legal decisions. Hire
yourself a competent schmuck." --USENET schmuck (aka Robert Kern)

[Xavier Morel]

Aahz wrote:

In article <ma************ *************** ************@py thon.org>,
Steve Holden <st***@holdenwe b.com> wrote:

(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'

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.

[Richie Hindle]

[Steve]

Since Python is Turing-complete

Is there some equivalent of Godwin's Law that we can invoke at this
point? 8-)

--
Richie Hindle
ri****@entrian. com

[bonono]

Carl J. Van Arsdall wrote:

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.

[Steve Holden]

Aahz wrote:

In article <ma************ *************** ************@py thon.org>,
Steve Holden <st***@holdenwe b.com> wrote:

(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'

Faster:

python -m this

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Simon Brunning]

On 12/15/05, Steve Holden <st***@holdenwe b.com> wrote:

Aahz wrote:

python -c 'import this'

Faster:

python -m this

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

--
Cheers,
Simon B,
si***@brunningo nline.net,
http://www.brunningonline.net/simon/blog/

[Rocco Moretti]

bo****@gmail.co m wrote:

Chris Mellon wrote:

Any time you want to write something in any way other than the obvious
way, ask yourself why? Is it more obvious *to you*, which is a good
reason as long as you're only writing code for yourself? Or is it just
to be different, or because you think it'll be faster, or just because
the slickness of it appeals to you?

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 "obviousnes s", 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.

[Brian Cully]

bo****@gmail.co m wrote:

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.