[Python-ideas] Object grabbing

[Steven D'Aprano]

On Mon, May 02, 2016 at 12:05:13PM +1000, Chris Angelico wrote:

> This would be restricted to lookups on simple names. Frankly, I
> wouldn't expect anything else. 

And I completely disagree.

If this proposal is for simple names alone, I don't want it -- it would 
be one more syntactic feature to learn for virtually no benefit to the 
reader or the writer. (If the name is so long as to be a burden to type, 
copy and paste it.)


> If you want to call
> "myobject[1].lookup['key'].property.a" and "etc etc .b", you should
> probably be giving that a name *for the benefit of humans*

That goes completely against the advice "use a temporary one-letter 
name". Using, let's say, "x" or "m" for the variable name is not really 
for the benefit of the reader, otherwise it would be given a 
meaningful name like current_record_address. But that obviously goes 
against the idea of reducing the amount needed to type/read.

*Whatever* solution you use, whether it is the one-letter temp name, or 
some variation on Pascal-with/using, you are compromising explicitness 
for convenience and/or efficiency. If this is worth doing, it has to be 
worth doing for complex references not just simple names. Otherwise, 
what's the point? Just use a shorter name.


> never mind
> about the interpreter! And if you want it optimized, definitely assign
> that to a local name.

If you have to create a one-off function just to get access to a local 
variable, the cost of creating a function will surely blow away any 
realistic gains you might get from using a local name.

That shouldn't apply to the "using" block, which can use the same 
reference without needing to create a function object.

If I'm reading you correctly, you're suggesting that (1) "using" should 
be limited to simple names, and (2) any (hypothetical) optimization 
should be only applied if the name is a function local, not inside a 
class definition or global scope.

With these restrictions, the value of this feature keeps going down and 
down and down, to the point that it is not worth adding it. There is 
cost to new syntactic features, and once you strip away most of the 
benefits, you're left with something that is no longer worth the effort 
of adding and learning the new syntax.

So a very strong -1 on the crippled/restricted version of "using", and a 
tentative +1 for the unrestricted version if it can be shown that there 
are significant performance gains to be made over the temp name version.

(I'm still not quite 100% convinced that the benefit outways the "grit 
on Tim's monitor rule", but I'm leaning that way.)


-- 
Steve