A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2000-July/006880.html below:

[Python-Dev] PEP 201 - Parallel iteration

[Python-Dev] PEP 201 - Parallel iterationThomas Wouters thomas@xs4all.net
Tue, 18 Jul 2000 11:59:47 +0200
On Tue, Jul 18, 2000 at 11:23:38AM +0000, Peter Schneider-Kamp wrote:
> Ken Manheimer wrote:

> > Evan Simpson (a colleague here at digicool, who'd be a good addition
> > to python-dev) noticed that unzip is unnecessary - zip is its own
> > inverse.  Since this is a worthwhile observation, i'll indulge a bit
> > and present it in evan's terms - particularly noting a different
> > packaging that i think is pretty cool, as methods on sequences.

> for x,y,z in [a, b, c].zip():

-1. Completely counter-intuitive, in my opinion... It would be nice if
having a list of lists to marry() is a common operation, but I doubt it is.
Having to create one just for the sake of zip() looks silly to me.

> for x,y,z in zip([a, b, c]):

-1. What's the point ? What's the difference ? What would
'zip([a,b,c],[d,e,f])' do ?

> for x,y,z in zip(a, b, c):

Still +0 on this. I still prefer the altered syntax 'for' loop :-) And
marry() over zip(). But I can live with this.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!



RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4