Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!news.stack.nl!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: <CAOFbRmL_w4QJaCdP8bo1YOi-u0i=SPtAcV51PsQOTytKhsJFVw@mail.gmail.com>
References: <CAOFbRmL_w4QJaCdP8bo1YOi-u0i=SPtAcV51PsQOTytKhsJFVw@mail.gmail.com>
From: Devin Jeanpierre <jeanpierreda@gmail.com>
Date: Fri, 16 Dec 2011 14:03:44 -0500
Subject: Re: Making the case for "typed" lists/iterators in python
To: Nathan Rice <nathan.alexander.rice@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: python-list <python-list@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.3749.1324062269.27778.python-list@python.org>
Lines: 110
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:17378

> 2. One comprehension:
>
> L2 =3D [Z(X(Y(e))) for e in L1]
> or
> L2 =3D [e.X().Y().Z() for e in L1]

I want to say that maybe this is better done by functions like map()
(although, Python is missing a composition operator which might be
handy, and mapping method calls isn't pretty).

I don't know that it belongs as a method on lists, especially since
that means you can't do the same thing on, for example, generators.

Or I guess, the easy answer to that lattermost objection is to make it
typed iterators rather than typed lists.

-- Devin

On Fri, Dec 16, 2011 at 12:48 PM, Nathan Rice
<nathan.alexander.rice@gmail.com> wrote:
> 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. =C2=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). =C2=A0Additionally, "typed" lists/iterators will allow
> improved code analysis and optimization. =C2=A0The PyPy people have alrea=
dy
> 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()
>
> Also, this would provide a way to clean up stuff like:
>
> "\n".join(l.capitalize() for l in my_string.split("\n"))
>
> into:
>
> my_string.split("\n").capitalize().join_this("\n")
>
> Before anyone gets up in arms at the idea of statically typed python,
> what I am suggesting here would be looser than that. =C2=A0Basically, I
> believe it would be a good idea in instances where it is known that a
> list of single type is going to be returned, to return a list subclass
> (for example, StringList, IntegerList, etc). =C2=A0To avoid handcuffing
> people with types, the standard list modification methods could be
> hooked so that if an object of an incorrect type is placed in the
> list, a warning is raised and the list converts to a generic object
> list. =C2=A0The only stumbling block is that you can't use __class__ to
> convert from stack types to heap types in CPython. =C2=A0My workaround fo=
r
> this would be to have a factory that creates generic "List" classes,
> modifying the bases to produce the correct behavior. =C2=A0Then, converti=
ng
> from a typed list to a generic object list would just be a matter of
> removing a member from the bases for a class. =C2=A0This of course
> basically kills the ability to perform type specific list optimization
> in CPython, but that isn't necessarily true for other implementations.
> =C2=A0The additional type information would be preserved for code analysi=
s
> in any case. =C2=A0The case would be even simpler for generators and othe=
r
> iterators, as you don't have to worry about mutation.
>
> I'd like to hear people's thoughts on the subject. =C2=A0Currently we are
> throwing away useful information in many cases that could be used for
> code analysis, optimization and simpler interfaces. =C2=A0I believe that
> "typed" lists that get "demoted" to normal lists with a warning on out
> of type operations preserve this information while providing complete
> backwards compatibility and freedom.
>
> Nathan
> --
> http://mail.python.org/mailman/listinfo/python-list