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

[Nathan Rice]

> Ah, my mistake, I was thinking of title() rather than capitalize().>> Still:>> def capitalize_lines(s):>    return "\n".join(s.capitalize() for line in s.split("\n"))>> There comes a time when the contortions people go to to avoid naming a> frequently repeated operation just get silly. If you do something a> lot, pull it out into a function and name it. The named function can> even be a local closure if the usage is sufficiently specific to one> operation - then it can still reference local variables without> requiring a lot of additional parameters.
Oh, I agree that it is best just to make it a function, and I have
(several times!).  So have a lot of other people.
>> Yes, I love that feature of strings, it is a source of lots of bugs,
>> but I digress.  The reason this partially solves that problem is that
>> instead of having to do a bunch of guesswork on an iterable to see if
>> you should do the vectorized version of the function, you just check
>> to see if it is an instance of a certain TypedCollectionContract.  If
>> so, vectorize.  No "isinstance(foo, Iterable) and not isinstance(foo,
>> basestr)" silliness here.
>
> If you plan to introduce a new ABC to drive this, then I have a simple proposal:
>
> 1. Write a module that implements your "broadcast API for collections"
> 2. Publish it on PyPI
> 3. When it has popular uptake to indicate widespread user demand, then
> come back to us

I certainly plan to make an implementation for example purposes.  And
if this was Ruby and not Python, that module would actually be
universally useful, because they can rewire their internals better
than we can.  Unfortunately, in Python land it is very difficult to
hook into list/iterator/etc creation on a global scale.  As a result,
a user would have to be very careful about calling into other people's
code, and the type information would still get blown away pretty
frequently.  Kind of like if you subclass string; all the string
methods still return strings, so the language is working against you
there.  Regardless, I'm sure everything that gets added to the
language was first a hugely popular PyPI project, that is clearly the
way the language evolves.