[Python-ideas] Adding "Typed" collections/iterators to Python

[Nathan Rice]

>>>> L2 = [X(e) for e in L1]>>  L3 = [Y(e) for e in L2]>>  vs>>  L2 = X(L1) #
>>>> assuming X has been updated to work in both vector/scalar>>  L3 = Y(L2) #
>>>> context...>>>  L = ['a', 'bc', ['ada', 'a']]>>  What is len(L)? 3 or [1, 2,
>>>> 2] or [1, 2, [3, 1]]?>>>>  L2 = [Z(Y(X(e))) for e in L1]>>  vs>>  L2 =
>>>> Z(Y(X(L1)))>>>>  L2 = [e.X().Y().Z() for e in L1]>>  vs>>  L2 =
>>>> L1.X().Y().Z() # assuming vectorized versions of member methods>>  #are
>>>> folded into the collection via the mixin.>>>  What is L.count('a')? 1 or [1,
>>>> 0, 1] or [1, 0, [2, 1]]?
>>
>>
>> A fair concern; if the vectorized version of the child method were
>> given the same name as the child method, I agree that this could
>> result in ambiguity.
>>
>> There are multiple ways that member methods could be made available on
>> the collection, including a proxy attribute, renaming, etc.
>
>
> len is not method, it is function (although it uses method __len__). There
> are many functions applicable to list and to its elements (in particular
> when members of list are lists).

I am aware of this.  I was talking about the "collection inside a
collection" example after that.  Additionally, now I realize my
initial reading of your example was too hasty. You violate the
contract in the mixed list example with strings and lists, and that
should rightfully not provide vectorized methods; providing type
decorators for very abstract notions such as "iterable" is a bad idea
imho.  Of course, [[1, 2], [3, 4], [5, 6]] could serve as an alternate
example of why you can't directly map child methods with the same
names.