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

Groups > comp.lang.python > #17377 > unrolled thread

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

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Making the case for "typed" lists/iterators in python Nathan Rice <nathan.alexander.rice@gmail.com> - 2011-12-16 13:51 -0500

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

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.  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
>
> --
> http://mail.python.org/mailman/listinfo/python-list

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web