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

[Steven Bethard]

[Duncan Booth]

aList = ['a', 1, 'b', 2, 'c', 3]
it = iter(aList)
zip(it, it)

[('a', 1), ('b', 2), ('c', 3)]

[Alan Isaac] That behavior is currently an accident.
http://sourceforge.net/tracker/?grou...il&aid=1121416
[Bengt Richter] That says
"""
ii. The other problem is easier to explain by example.
Let it=iter([1,2,3,4]).
What is the result of zip(*[it]*2)?
The current answer is: [(1,2),(3,4)],
but it is impossible to determine this from the docs,
which would allow [(1,3),(2,4)] instead (or indeed
other possibilities).
"""
IMO left->right is useful enough to warrant making it defined
behaviour

And in fact, it is defined behavior for itertools.izip( ) [1].

I don't see why it's such a big deal to make it defined behavior for
zip() too.

STeVe

[1]http://docs.python.org/lib/itertools-functions.html# l2h-1392

[Fredrik Lundh]

ru***@yahoo.com wrote:

led to more serious flaws like the missing if-then-else expression,
something I use in virtually every piece of code I write, and which
increases readability.
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.
(Well, ok that is not the end of the world either but it's lack is irritating
as hell, and yes, I know that it is now back in favor.)

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

</F>

[bonono]

Fredrik Lundh wrote:

(Well, ok that is not the end of the world either but it's lack is irritating
as hell, and yes, I know that it is now back in favor.)

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

there it comes :-)

[Antoon Pardon]

Op 2005-11-23, Fredrik Lundh schreef <fr*****@python ware.com>:

ru***@yahoo.com wrote:

led to more serious flaws like the missing if-then-else expression,
something I use in virtually every piece of code I write, and which
increases readability.

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.

What does this mean?

It could mean that python works better with those concepts that are
already implemented in python. That seems obvious, but isn't
an argument for or against implementing a particular language
feature.

It could also mean that some language feature will never work well
in python even when implemented. Are you arguing that a conditional
expression is such a feature?

(Well, ok that is not the end of the world either but it's lack is irritating
as hell, and yes, I know that it is now back in favor.)

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

Well I don't know about the previous poster, but I'm mostly interesseted
in a conditional expression. Whether it is "then-if-else" or "if-then-else"
seems less important to me.

--
Antoon Pardon

[Dave Hansen]

On Tue, 22 Nov 2005 23:17:31 -0700 in comp.lang.pytho n, Steven Bethard
<st************ @gmail.com> wrote:

rh********@gma il.com wrote:

[...]

IIRC, this was discussednd rejected in an SF bug report. It should not
be a defined behavior for severals reasons:

[snip arguments about how confusing zip(it, it) is]

Overall, I think anyone using zip(it,it) is living in a state of sin,
drawn to the tempations of one-liners and premature optimization. They
are forsaking obvious code in favor of screwy special cases. The
behavior has been left undefined for a reason.

Then why document itertools.izip( ) as it is? The documentation there is
explicit enough to know that izip(it, it) will work as intended. Should
we make the documentation there less explicit to discourage people from
using the izip(it, it) idiom?

ISTM that one would use itertools.izip in order to get some
functionality not available from zip. Perhaps this is one of those
bits of functionality.

But I admit, I'm not all that familiar with itertools...

In any case, the solution seems obvious: if you want the guarantee,
use the tool that provides it.

Regards,
-=Dave

--
Change is inevitable, progress is not.

[rhettinger]

[Steven Bethard]

Then why document itertools.izip( ) as it is? The documentation there is
explicit enough to know that izip(it, it) will work as intended. Should
we make the documentation there less explicit to discourage people from
using the izip(it, it) idiom?

[Dave Hansen] In any case, the solution seems obvious: if you want the guarantee,
use the tool that provides it.

True enough :-)

FWIW, the itertools documentation style was intended more as a learning
device than as a specification. I combined regular documentation,
approximately equivalent generator code, examples, and recipes.
Hopefully, reading the module docs creates an understanding of what the
tools do, how to use them, how to combine them, and how to roll your
own to extend the toolset. Another goal was providing code fragments
to support scripts needing to run on Py2.2 (itertools were introduced
in Py2.3).
Raymond

[Fredrik Lundh]

Steven Bethard wrote:

Then why document itertools.izip( ) as it is? The documentation there is
explicit enough to know that izip(it, it) will work as intended. Should
we make the documentation there less explicit to discourage people from
using the izip(it, it) idiom?

depends on whether you interpret "equivalent " as "having similar effects"
or "correspond ing or virtually identical especially in effect or function" or
if you prefer some other dictionary definition...

because there are of course plenty of subtle differences between a Python
generator C type implementation. let's see...

from itertools import izip as izip1
from library documentation import izip as izip2 izip1 <type 'itertools.izip '> izip2 <function izip2 at 0x00A26670>

alright, close enough.
izip1.func_name Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: type object 'itertools.izip ' has no attribute 'func_name' izip2.func_name 'izip'

hmm.
class myiter: .... def next(self):
.... raise ValueError("oop s!")
.... izip2(myiter()) <generator object at 0x00A2AB48> izip1(myiter()) Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: izip argument #1 must support iteration

oops.
class myiter: .... def __iter__(self):
.... return self
.... def next(self):
.... raise ValueError("oop s!")
.... izip1(myiter()) <itertools.iz ip object at 0x00A2AC88> izip2(myiter()) <generator object at 0x00A2AB48>

that's better. now let's run it:
list(izip1(myit er())) Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 5, in next
ValueError: oops! list(izip2(myit er()))

Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "i.py", line 6, in izip2
result = [i.next() for i in iterables]
File "<stdin>", line 5, in next
ValueError: oops!

different stack depths. hmm.

so how equivalent must something be to be equivalent?

</F>

[bonono]

yet another :-)

Fredrik Lundh wrote:

Steven Bethard wrote:

Then why document itertools.izip( ) as it is? The documentation there is
explicit enough to know that izip(it, it) will work as intended. Should
we make the documentation there less explicit to discourage people from
using the izip(it, it) idiom?

depends on whether you interpret "equivalent " as "having similar effects"
or "correspond ing or virtually identical especially in effect or function" or
if you prefer some other dictionary definition...

because there are of course plenty of subtle differences between a Python
generator C type implementation. let's see...

from itertools import izip as izip1
from library documentation import izip as izip2 izip1 <type 'itertools.izip '> izip2 <function izip2 at 0x00A26670>

alright, close enough.
izip1.func_name Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: type object 'itertools.izip ' has no attribute 'func_name' izip2.func_name 'izip'

hmm.
class myiter: ... def next(self):
... raise ValueError("oop s!")
... izip2(myiter()) <generator object at 0x00A2AB48> izip1(myiter()) Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: izip argument #1 must support iteration

oops.
class myiter: ... def __iter__(self):
... return self
... def next(self):
... raise ValueError("oop s!")
... izip1(myiter()) <itertools.iz ip object at 0x00A2AC88> izip2(myiter()) <generator object at 0x00A2AB48>

that's better. now let's run it:
list(izip1(myit er())) Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 5, in next
ValueError: oops! list(izip2(myit er()))

Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "i.py", line 6, in izip2
result = [i.next() for i in iterables]
File "<stdin>", line 5, in next
ValueError: oops!

different stack depths. hmm.

so how equivalent must something be to be equivalent?

</F>

[Steven Bethard]

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

Steven Bethard wrote:

rh********@gm ail.com wrote:

>ii. The other problem is easier to explain by example.
>Let it=iter([1,2,3,4]).
>What is the result of zip(*[it]*2)?
>The current answer is: [(1,2),(3,4)],
>but it is impossible to determine this from the docs,
>which would allow [(1,3),(2,4)] instead (or indeed
>other possibilities).
>"""
>IMO left->right is useful enough to warrant making it defined
>behaviou r

And in fact, it is defined behavior for itertools.izip( ) [1].

I don't see why it's such a big deal to make it defined behavior for
zip() too.
IIRC, this was discussednd rejected in an SF bug report. It should not
be a defined behavior for severals reasons:
[snip arguments about how confusing zip(it, it) is]

Overall, I think anyone using zip(it,it) is living in a state of sin,
drawn to the tempations of one-liners and premature optimization. They
are forsaking obvious code in favor of screwy special cases. The
behavior has been left undefined for a reason.

Then why document itertools.izip( ) as it is? The documentation there is
explicit enough to know that izip(it, it) will work as intended. Should
we make the documentation there less explicit to discourage people from
using the izip(it, it) idiom?

[snip]
But technically speaking, you are still referring to the implementation
detail of izip(), not the functionality of izip().

I do now agree with another poster that the documentation of both zip
and izip should state clear that the order of picking from which
iterable is undefined or can be changed from implementation to
implementation, to avoid this kind of temptation.

Actually, it's part of the specificiation. Read the itertools
documentation[1]:

"""
izip(*iterables )
Make an iterator that aggregates elements from each of the
iterables. Like zip() except that it returns an iterator instead of a
list. Used for lock-step iteration over several iterables at a time.
Equivalent to:

def izip(*iterables ):
iterables = map(iter, iterables)
while iterables:
result = [i.next() for i in iterables]
yield tuple(result)
"""

So technically, since itertools.izip( ) is "equivalent to" the Python
code above, it is part of the specification, not the implementation.

But I certainly understand Raymond's point -- the code in the itertools
documentation there serves a number of purposes other than just
documenting the behavior.

[1]http://docs.python.org/lib/itertools-functions.html# l2h-1392

STeVe

[Fredrik Lundh]

rh********@gmai l.com wrote:

[Dave Hansen]

In any case, the solution seems obvious: if you want the guarantee,
use the tool that provides it.

True enough :-)

FWIW, the itertools documentation style was intended more as a learning
device than as a specification. I combined regular documentation,
approximately equivalent generator code, examples, and recipes.
Hopefully, reading the module docs creates an understanding of what the
tools do, how to use them, how to combine them, and how to roll your
own to extend the toolset.

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.

</F>

[rhettinger]

> > FWIW, the itertools documentation style was intended more as a learning

device than as a specification. I combined regular documentation,
approximately equivalent generator code, examples, and recipes.
Hopefully, reading the module docs creates an understanding of what the
tools do, how to use them, how to combine them, and how to roll your
own to extend the toolset.

[Fredrik Lundh] 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.

Will do.

This is doubly a good idea because there are small differences in
argument processing. For example, count() makes an immediate check for
a numerical argument but the generator version won't recognize the
fault until the count(x).next() is called.