Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <jcg2av$jck$1@dough.gmane.org>
References: <CAOFbRmL_w4QJaCdP8bo1YOi-u0i=SPtAcV51PsQOTytKhsJFVw@mail.gmail.com> <jcg2av$jck$1@dough.gmane.org>
Date: Fri, 16 Dec 2011 13:51:08 -0500
Subject: Re: Making the case for "typed" lists/iterators in python
From: Nathan Rice <nathan.alexander.rice@gmail.com>
To: python-list <python-list@python.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.3748.1324061472.27778.python-list@python.org>
Lines: 71
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:17377

Nothing stops me from implementing it, in fact it is VERY trivial to
wrap member class methods onto a list subclass, and wrap functions to
support vectorized behavior.  The problem is that as soon as you hit
anything outside your code that returns a list or iterator, everything
gets blown away unless you explicitly wrap the return value, which
entirely defeats the point.

On Fri, Dec 16, 2011 at 1:23 PM, Stefan Behnel <stefan_ml@behnel.de> wrote:
> Nathan Rice, 16.12.2011 18:48:
>
>> I realize this has been discussed in the past, I hope that I am
>> presenting a slightly different take on the subject that will prove
>> interesting. =A0This is primarily motivated by my annoyance with using
>> comprehensions in certain circumstances.
>>
>> Currently, if you want to perform successive transformations on the
>> elements of a list, a couple of options:
>>
>> 1. Successive comprehensions:
>>
>> L2 =3D [X(e) for e in L1]
>> L3 =3D [Y(e) for e in L2]
>> L4 =3D [Z(e) for e in L3]
>> or
>> L2 =3D [e.X() for e in L1]
>>
>> This gets the job done and gives you access to all the intermediate
>> values, but isn't very succinct, particularly if you are in the habit
>> of using informative identifiers.
>>
>> 2. One comprehension:
>>
>> L2 =3D [Z(X(Y(e))) for e in L1]
>> or
>> L2 =3D [e.X().Y().Z() for e in L1]
>>
>> This gets the job done, but doesn't give you access to all the
>> intermediate values, and tends to be pretty awful to read.
>>
>> Having "typed" lists let you take preexisting string/int/etc methods
>> and expose them in a vectorized context and provides an easy way for
>> developers to support both vectors and scalars in a single function
>> (you could easily "fix" other people's functions dynamically to
>> support both). =A0Additionally, "typed" lists/iterators will allow
>> improved code analysis and optimization. =A0The PyPy people have already
>> stated that they are working on implementing different strategies for
>> lists composed of a single type, so clearly there is already community
>> movement in this direction.
>>
>> Just compare the above examples to their type-aware counterparts:
>>
>> L2 =3D X(L1)
>> L2 =3D L1.X()
>>
>> L2 =3D Z(Y(X(L1)))
>> L2 =3D L1.X().Y().Z()
>
>
> What keeps you from implementing this? You don't need to change the langu=
age
> for it, just wrap the list in a class that overrides __getattr__() to ret=
urn
> something that does the appropriate transformation for each element. I wo=
uld
> be surprised if you needed more than a couple of lines of Python code for
> that.
>
> Stefan
>
> --
> http://mail.python.org/mailman/listinfo/python-list