defining the behavior of zip(it, it) (WAS: Converting a flat list...)

[bonono]

maybe it's time to change "equivalent to" to "similar to", to avoid
messing things up for people who reads the mostly informal library
reference as if it were an ISO specification.

That is their fault as the library reference is supposed to be "(keep
this under your pillow)", not for reading.

 

[Fredrik Lundh]

That is their fault as the library reference is supposed to be "(keep
this under your pillow)", not for reading.

you haven't made much sense in your most recent posts. why not
just give it up, and leave the design issues to people who don't re-
ply "I don't know" to every question.

</F>

 

[rurpy]

you obviously need to learn more Python idioms. Python works better
if you use it to write Python code; not when you mechanically translate
stuff written in other languages to Python.

The current Python idiom is the if-then-else statement, isn't it?
I know about that, and use it. Unfortunately in some cases it
produces code that is less clear, hence my belief that Python
wll be a better language with an if-then-else expression.

As an aside, I would like to see a well written "Python Idioms"
book or howto as part of the standard documentation. Not
cookbook recipies of which there are already several good
collections, but shorter things like, copy(sequence) is spelled
"sequence[:]".

the thing that's in favour is "then-if-else", not "if-then-else".

Sorry if I confused you, I though it was clear that I meant the
concept, not a specific syntactical implementation.

 

[bonono]

you haven't made much sense in your most recent posts. why not
just give it up, and leave the design issues to people who don't re-
ply "I don't know" to every question.

Oh, find a need to shut other up ?

 

[Alex Martelli]

cookbook recipies of which there are already several good
collections, but shorter things like, copy(sequence) is spelled
"sequence[:]".

No way:

from collections import deque
d=deque([1,2,3])
d[:]

Traceback (most recent call last):

deque(d) deque([1, 2, 3])

I.e., NOT all sequences implement the unreadable x[:] form.

The way that DOES work with all sequences is typeyouwant(sequence).


Alex

 

[Fredrik Lundh]

Sorry if I confused you, I though it was clear that I meant the
concept, not a specific syntactical implementation.

yup, but if you care readability about, the words order appear in
would to seem matter too.

<F/>

 

[bonono]

yup, but if you care readability about, the words order appear in
would to seem matter too.

Not in the context of this conversation though.

 

[Antoon Pardon]

yup, but if you care readability about, the words order appear in
would to seem matter too.

Well I do wonder what would be more readable.

1) That the constructs are consistent within the (programming) languague.

2) That some constructs resemble english.


(2) May make some constructs more readable for the beginners, but
IMO (1) makes for more readabiliy over the long term.

 

[Bengt Richter]

so how equivalent must something be to be equivalent?

quack, quack? ;-)

Regards,
Bengt Richter

 

[Magnus Lycka]

What does this mean?

It means that the hammer works better if you learn how to hold
and swing it, instead of trying to modify it so that it's more
comfortable to use it in a non-optimal way.

 

[Magnus Lycka]

Oh, find a need to shut other up ?

Oh, find a need to get the last word?

/Magnus

P.S. Yes, this *is* a test.

 

[rurpy]

yup, but if you care readability about, the words order appear in
would to seem matter too.

Yes, order does matter. Which is why I chose the order I
did. Anyone familiar with programming (including Python
programmers) will understand what an "if-then-else" statement
and expression are. The term "then-if-else" will make sense
only to people who use Python and are familiar with the
twists and turns of the PEP-308 debate. Why would I choose
to intentionally restrict the audience of my post when there
is no need to? (That this is a Python newsgroup read by
Python users is not relevant. Other people read it too.)

It is very interesting I think, because this is the core of my
complaint about Python. Python seems unwilling to adapt
to any unapproved styles, even when it could do so at
little cost. Like you, it prefers targeting a narrow(*)
audience willing to adopt the "one true programming style"
even when it could appeal to a wider audience.

That you extend this Python philosophy even to english
and newsgroup posting is fascinating...

(*) I mean narrow in their view of what constitutes good
style, not narrow or small in numbers.

 

[Steve Holden]

Yes, order does matter. Which is why I chose the order I
did. Anyone familiar with programming (including Python
programmers) will understand what an "if-then-else" statement
and expression are. The term "then-if-else" will make sense
only to people who use Python and are familiar with the
twists and turns of the PEP-308 debate. Why would I choose
to intentionally restrict the audience of my post when there
is no need to? (That this is a Python newsgroup read by
Python users is not relevant. Other people read it too.)

It is very interesting I think, because this is the core of my
complaint about Python. Python seems unwilling to adapt
to any unapproved styles, even when it could do so at
little cost. Like you, it prefers targeting a narrow(*)
audience willing to adopt the "one true programming style"
even when it could appeal to a wider audience.

Now, see, that's the thing. The more ways there are to write the same
program, the harder any given program will be to understand.

This is indeed a fairly deliberate approach in the Python world, and
contrasts with languages where readability is low because of the
multiple different ways of expressing the same idea.

That you extend this Python philosophy even to english
and newsgroup posting is fascinating...

I think Fredrik was trying to make a point about the need to be accurate
in discussing language features, but I could be wrong.

(*) I mean narrow in their view of what constitutes good
style, not narrow or small in numbers.

regards
Steve

 

[rurpy]

cookbook recipies of which there are already several good
collections, but shorter things like, copy(sequence) is spelled
"sequence[:]".

No way:

from collections import deque
d=deque([1,2,3])
d[:]

Traceback (most recent call last):

deque(d) deque([1, 2, 3])

I.e., NOT all sequences implement the unreadable x[:] form.

The way that DOES work with all sequences is typeyouwant(sequence).

I'm sorry, I don't understand. Does deque return a sequence?
The doc says it returns a deque object, and without further info
I would not expect [:] to work. Is it a sequence because it has
the same methods as a sequence?

Whatever, I gather my old book is outdated and the blessed
way now to (shallow) copy a sequence is (as you say)
"typeyouwant(sequence)" which I will make a note of.

Thanks for updating me.

 

[Alex Martelli]

d=deque([1,2,3])
d[:]

Traceback (most recent call last):

deque(d) deque([1, 2, 3])

I.e., NOT all sequences implement the unreadable x[:] form.

The way that DOES work with all sequences is typeyouwant(sequence).

I'm sorry, I don't understand. Does deque return a sequence?

There is no universally accepted definition of what "is a sequence" in
Python, but the deque type meets most criteria.

The doc says it returns a deque object, and without further info
I would not expect [:] to work. Is it a sequence because it has
the same methods as a sequence?

Workable definitions are usually operational ones, yes.

Whatever, I gather my old book is outdated and the blessed
way now to (shallow) copy a sequence is (as you say)
"typeyouwant(sequence)" which I will make a note of.

Thanks for updating me.

You're welcome, but be aware that this is MY thesis and not all accept
it. somesequencetype(someiterable) is a general way to make a new
instance of type 'somesequencetype' and accepts a wide variety of types
for arguments, namely all iterables. list(somelist) is slightly less
compact than somelist[:] when you know you start with a list instance
and want a shallow copy thereof, but I see no good reason to specialcase
this occurrence AND use an unreadable idiom in it, when the nice,
general, readable idiom is perfectly serviceable.


Alex

 

[bonono]

Oh, find a need to get the last word?

like you ?

 

[Fredrik Lundh]

Now, see, that's the thing. The more ways there are to write the same
program, the harder any given program will be to understand.

This is indeed a fairly deliberate approach in the Python world, and
contrasts with languages where readability is low because of the
multiple different ways of expressing the same idea.

you can express ideas in many ways in Python (just witness all the web
frameworks and xml toolkits ;-). the deliberate approach you're referring
to is more about using a consistent spelling.

seriously, if anyone has a job so boring that his only way to express his
creativity is to be able call a trivial library operation in many different
ways somewhere deep inside his program, his problems are a lot more
fundamental than the choice of programming language.

(in a way, this is related to what creative programmers sometimes refer
to as python's "pencil-like qualities"; the fact that once you've grokked
python's way to do things, the language pretty much disappears from
sight. *your* ideas is what matters. see e.g. the venners interview
with bruce eckel:

http://www.artima.com/intv/aboutme.html
http://www.artima.com/intv/prodperf.html
http://www.artima.com/intv/typing.html
http://www.artima.com/intv/tipping.html

for more on this.

here's the keynote they're referring to, btw:

http://www.mindview.net/FAQ/FAQ-012

</F>

 

[Steve Holden]

Oh, find a need to get the last word?

/Magnus

P.S. Yes, this *is* a test.

Looks like you hooked him, Magnus ;-)

 

[bonono]

Looks like you hooked him, Magnus ;-)

and he is permenantly hooked