Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #17372

Re: Making the case for "typed" lists/iterators in python

From Stefan Behnel <stefan_ml@behnel.de>
Subject Re: Making the case for "typed" lists/iterators in python
Date 2011-12-16 19:23 +0100
References <CAOFbRmL_w4QJaCdP8bo1YOi-u0i=SPtAcV51PsQOTytKhsJFVw@mail.gmail.com>
Newsgroups comp.lang.python
Message-ID <mailman.3744.1324059823.27778.python-list@python.org> (permalink)

Show all headers | View raw


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.  This 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 = [X(e) for e in L1]
> L3 = [Y(e) for e in L2]
> L4 = [Z(e) for e in L3]
> or
> L2 = [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 = [Z(X(Y(e))) for e in L1]
> or
> L2 = [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).  Additionally, "typed" lists/iterators will allow
> improved code analysis and optimization.  The 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 = X(L1)
> L2 = L1.X()
>
> L2 = Z(Y(X(L1)))
> L2 = L1.X().Y().Z()

What keeps you from implementing this? You don't need to change the 
language for it, just wrap the list in a class that overrides __getattr__() 
to return something that does the appropriate transformation for each 
element. I would be surprised if you needed more than a couple of lines of 
Python code for that.

Stefan

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread


Thread

Re: Making the case for "typed" lists/iterators in python Stefan Behnel <stefan_ml@behnel.de> - 2011-12-16 19:23 +0100

csiph-web