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

Nathan Rice nathan.alexander.rice at gmail.com
Tue Dec 20 19:50:23 CET 2011


Nick:  My main issue with anything you've said is that I felt your
original statement about going off, creating a library, evangelizing
it vigorously until it is popular and coming back in several years as
a prerequisite to even engaging in a thoughtful discussion on the
subject was overly dismissive and phrased in a combative manner.  I do
appreciate the strong challenges you've presented though.

Terry:  My apologies for being unclear.  I do not take enough care in
using terminology in the standard way. In my case, I think code is a
better communication mechanism, so that is where I will be focusing
most of my efforts moving forward.


***Broadcasting/Elementwise operations***

I agree code speaks more clearly than words:

I put a module called "elementwise" on pypi
(http://pypi.python.org/pypi/elementwise/0.111220) that implements my
idea of what a nice broadcast proxy should do.  The proxy itself could
be leaner, I started out trying to make it in a very surgical manner,
but 1.) There are serious dragons in the way python handles lookup of
operator overloading special methods 2.) there are serious dragons in
how python handles complex inheritance graphs that result in
"object.__new__() takes no parameters", despite not having any builtin
bases and having no base class overriding __new__ or __init__ 3.)
Proxying EVERYTHING is pythonic in some sense.  I am aware that there
are probably issues around having some combination of special methods
defined that will confuse the interpreter.

The syntax is really simple:

your_iterable_elementwise = ElementwiseProxy(your_iterable)

your_iterable_elementwise.method_1().method_2().method_3()

(your_iterable_elementwise + 1) * 2 + 10

The __iter__ method is how you break the cycle,  so when you are done
working in an elementwise manner, just call
{list|set|tuple|...}(your_iterable_elementwise).  In place operator
modification should work as well.  All operations on an
ElementwiseProxy return another ElementwiseProxy with a parent
attribute that you can use to backtrack in the operation history, if
for some reason you were brought into the loop partway through.

I also included an ElementwiseProxyMixin that gives you a ruby-esque
class.each property for iterables, which is basically just returns a
"ElementwiseProxy(self)".  I think the syntax is nicer.


***I can haz moar Metadata (was "typed" collections)***

Because "typed" is sort of a dirty word in the python community, and
some people have had issues with other terms I have used, I am going
to settle on addressing things in term of the problem.  The problem is
metadata - languages with declared types have a lot of it, python has
a lot less.  Metadata is useful, and we should try to pack as much if
it in as we can, because it lets us do things in a intelligent ways on
a case by case basis.

I understand annotations are designed for this, but they are
absolutely pointless without some sort of schema or strong
conventions.  I see from the archived discussions that people wanted
to avoid a design by committee situation, but people working in the
tool-chain aren't going to mess with annotations unless there is one
metadata standard that is pretty much ubiquitous (at which point it
should be included in the stdlib anyhow).  I think it is a decent idea
to have it incubate outside the stdlib, but I don't see any progress
on that front at all.  With that being said, I would like to reopen
the discussion about an metadata annotation schema, so we can get an
incubation implementation going and begin evangelism.



More information about the Python-ideas mailing list