[Python-ideas] Adding __getter__ to compliment __iter__.

[Ron Adam]

On 07/21/2013 12:33 AM, Steven D'Aprano wrote:
> On 21/07/13 14:04, Ron Adam wrote:
>
>> 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.
>
> Ron, either I haven't explained myself clearly enough, or you haven't been
> paying attention :-) I'm not opposed to this particular spelling. I'm
> opposed to optimizing method calls with syntax *regardless of the spelling*.

Yes, I understood this, and was paying attention.

Often, the less ordered a persons mind is, the more creative they are, and 
they are more likely to find new ways to think about things, or find new 
solutions that are not readily apparent to others.  (and solutions that 
don't always work too.)

It's a trade off...  The other side of that is someone who has a highly 
ordered mind, they often are very literate, and have exceptional memories. 
  (I'm not one of these types. ;-)




Looking through the opcode.h, there is LIST_APPEND.

When and where that is used?  It doesn't appear to be used with the append 
method.




> This opposition should be considered provisional. Obviously if there is a
> good enough reason to give something syntax, like item lookups have syntax
> seq[item], then I do not oppose it. But as a general rule, Python does not
> add syntax for every little thing that might happen to be micro-optimized
> by a special byte-code.

Yes, and I agree.


> Let me put it this way, to give an analogy... in some of my code, I have a
> class with a "calculate" method. I use this class *all the time*, it is
> really important to me. If I were to propose special syntax to call the
> "calculate" method, so as to avoid the method lookup and argument passing
> overhead, I would expect that most people would ask the same question I
> asked earlier:
>
> What's so special about this that it needs dedicated syntax?

I don't have a concrete answer for you.  It's not a completely new feature, 
and it isn't a bug.  The best I can do is tell you that it doesn't feel (to 
me) like it should be a function call.

When we call a function, what usually happens, Is a new frame instance is 
created, and a name space is initialised with the values passed though the 
signature.  And then after that... the code object is started and evaluated.

When a generator is resumed, the value just replaces the yield expression. 
  That is quite different from creating a new frame and initialising a name 
space.  It feels more like a communication port to me.

Small talk is an interesting comparison where everything is done with 
messages.  But that's the other extreme.




David mentioned that it might be possibly to use the peepholer to optimise 
the bytecode.  I think that would be a good first experiment to try.

But I'm not sure it can do this..  I think it has a limitation of not 
optimising over blocks or frames.



> "It will be a tiny bit faster, because it avoids the method call lookup" is
> not an answer. That would be true for *any* method. What is so special
> about *this method* (whether it is "calculate" or "send" that it is worth
> paying the extra cost of new syntax in order to avoid that overhead?
> Normally Python only uses syntax for things that people absolutely expect
> to be syntax (like operators), or to give features that can't
> (conveniently, or at all) work as regular function calls (like del and
> import).
>
> If you have a good answer to that question, then I might change my mind and
> support your proposal.

One method can't be a special case.  Is this what you are trying say here? 
  If so, then I agree.


Cheers,
    Ron



> [...]
>> The thing that got me on this is, if generators aren't faster than a
>> class with method calls.  Then why do we generators?
>
> Because typically a generator is much easier to read and write. And also
> because once you have the infrastructure to support generators, that can be
> generalised to give you coroutines as well.
>
> Besides, are you sure that generators aren't faster?
>
>
>