[Python-ideas] Adding __getter__ to compliment __iter__.

[Ron Adam]

On Thu, Jul 18, 2013 at 11:59 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> On 19 July 2013 00:29, Ron Adam <ron3200 at gmail.com> wrote:
> > I was thinking a generator would be more efficient if it's called many
> > times.  But I think this is easier to understand.  If there is more
interest
> > we can test both to see how much of a difference it makes.
>
> Suspending and resuming a generator is quite an expensive operation.
> send() has the triple whammy of method call + resume generator +
> suspend generator, so it's unlikely to outperform a simple method call
> (even one that redirects to another method).


I thought one of the things about generators was that they didn't have to
create a new frame, or store attributes.   And those features would make
them a bit faster than a function call.   Hmmm,  but that is wrapped in a
method call.

I did some tests with send(), and it is about 3% slower than a function
call.  Some of that difference is due to the loop in the generator.  So
it's pretty close.

Could we have syntax for generators to bypass the method calls?

    x = gen[]                 # next

    gen[] = x                 # send;   or    "gen[] x"

    x = gen[]; gen[] = x      # or   "x = gen[] x"

Currently using empty brackets like this is a syntax error.   The brackets
imply it is a type of iterator.  Which is the most common use for
generators.


> Independent of performance though, I think the mutable sequence API
> inspired append(), extend() and += are a better API for what you're
> trying to achieve than "send", so it doesn't make sense to me to try
> to shoehorn this into the generator API.

I'm 50/50 on this right now.  So I want to test both out in different
situations.  Keeping the behavior as dead simple as possible may be better
because then it creates an object that would be used in a very consistent
way.  I think that is one of the benefits of the simple iterator design.

Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130719/4f9670e8/attachment-0001.html>