[Python-ideas] Adding __getter__ to compliment __iter__.

[David Mertz]

There really shouldn't be any need for new syntax to rest this idea. A
keyhole optimizer should be able to make this improvement to bytecode using
the existing method call syntax, I believe.
On Jul 21, 2013 12:05 AM, "Ron Adam" <ron3200 at gmail.com> wrote:

>
>
> On 07/20/2013 07:47 PM, Steven D'Aprano wrote:
>
>> On 21/07/13 07:17, Ron Adam wrote:
>>
>>>
>>>
>>> On 07/19/2013 12:32 PM, Steven D'Aprano wrote:
>>>
>>>> On 20/07/13 01:58, Ron Adam wrote:
>>>>
>>>>  Could we have syntax for generators to bypass the method calls?
>>>>>
>>>>>      x = gen[]                 # next
>>>>>
>>>>
>>>> Please no.
>>>>
>>>> What's so special about generators that they should have magic syntax
>>>> for
>>>> bypassing methods?
>>>>
>>>
>>> Generators are quite special.  Because they suspend and resume, and the
>>> values that are passed on each yield are limited to a single object in
>>> followed by a single object out.
>>>
>>
>> I know what generators do. I asked, what is so special that they need
>> *syntax for bypassing methods*. That's the part that you didn't answer.
>> Your syntax suggestion doesn't change either the fact that they suspend
>> and
>> resume, or that the values passed are limited to a single object. We
>> already have an idiom for passing multiple objects at a time: the tuple.
>>
>
> Unfortanantly I don't think we can generate the specific bytecode change I
> suggested without also adding new syntax.  (Does that help?)
>
>
>  Good uses for syntax include doing things that you can't
>>>> otherwise do, not as a mere alias for a method.
>>>>
>>>
>>> This is what I was trying to convey.
>>>
>>
>> But your proposal is exactly that, a mere alias. It doesn't add any new
>> functionality. It doesn't let you do anything that can't already be done.
>> That's my point. Instead of things that read like Python code and that you
>> can easily look up in the docs:
>>
>
> Correct it doesn't add functionality, it adds a way to accomplish that
> same functionality in a more efficient way.
>
>  next(gen)
>> gen.send(x)
>>
>> you have these mysterious syntax, one of which looks like a key/item
>> lookup
>> missing an argument, and one of which just looks like a key/item lookup:
>>
>> gen[]
>> gen[x]
>>
>
> You seem to be stuck on this point.  The exact syntax isn't important.
>  You are clearly -1 on this particular spelling.  That's fine.
>
> This was just a side comment in this thread.  The example syntax wasn't
> important.  If there was some interest in the underlying idea of producing
> more efficient byte code for generator next and send calls, then we can
> start another thread about it.  So far there isn't any.
>
> Maybe I'll try to implement it sometime and see how much difference it
> makes.  If it's more than a few percent, I'll come back here with the
> results.  It may not be anytime soon though.  I need to refresh my memory
> on how to add new grammar and syntax.
>
>
>  I haven't even mentioned that this proposal can't fly because the Python
>> compiler cannot tell ahead of time which code is intended. You could get
>> around that by changing the syntax:
>>
>
> Well, you just did...  ;-)
>
>  gen!!
>> gen!x!
>>
>
>  I'm questioning the need for this to be syntax in the first place.
>>
>
> It's what the syntax represents that I would like.  A bit faster generator
> suspend, resume, and value passing.  If it can be done without new syntax,
> That's even better. ;-)
>
> The thing that got me on this is, if generators aren't faster than a class
> with method calls.  Then why do we generators?
>
> Cheers,
>    Ron
>
> ______________________________**_________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/**mailman/listinfo/python-ideas<http://mail.python.org/mailman/listinfo/python-ideas>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130721/b1bb2784/attachment-0001.html>