[Python-ideas] use "as" for block scope support

[Daniel Greenfeld]

As a 'Joe Developer', someone not a computer scientist but your
'average user', I'm going to have to step in and agree that the
proposed syntax is *much* harder to read. I could follow Steven's code
but the other code comes across as obfuscated.

On Mon, Jul 25, 2011 at 5:24 PM, 海韵 <lyricconch at gmail.com> wrote:
> 2011/7/26 Steven D'Aprano <steve at pearwood.info>:
>> 海韵 wrote:
>>>
>>> 1.
>>> but what about ( t * s + t / s )? temp var always keep in memory.
>>> (should not reduce ( t + s ) to ( 2 * x ) since x, y may not a number.
>>> any operator here should be conside as  independent function. )
>>
>> What about it? The temporary variables will go out of scope when the
>> function exists, and be garbage collected, the same as every other local
>> variable.
>>
>>
>>> 2. you got an extra lambda, that means:
>>> In runtime:
>>> lambda = MAKE_FUNCTION/MAKE_CLOSURE =  PyFunction_New
>>> lambda call = CALL_FUNCTION =  PyFrame_New +  PyEval_EvalFrameEx
>>> all of them are heavy, (you can check the source code)
>>> but:
>>> as = PyCell_New
>>> as enter = SETUP_FINALLY = PyFrame_BlockSetup
>>> as leave = END_FINALLY = PyFrame_BlockPop
>>> which is much much much more more more cheaper than above.
>>
>> Sounds like premature optimization to me. I would like to see actual,
>> real-world code where the performance bottleneck is setting up functions.
>>
>>
>>> 3.
>>> try convert this to the lambda form as mention:
> <1>
>>> R= lambda x, y: (x+y as t, x-y as s)(t * s as u, t/s as v)(u << v as
>>> p, u>>v as q) p ** q
>>
>> I wouldn't even *try* to convert that to a lambda. That is ugly,
>> unmaintainable code. To understand it, I had to first write it out in block
>> form:
> <1>
>  A = (x + y as t, x - y as s)(t * s as u, t / s as v)(u << v as  p, u
>>> v as q) p ** q
> <2>
> t, s = x+y, x-y
> u, v = t*s, t/s
> p, q = u<<v, u>>v
> A =p**q
> is it really ugly? why i feel pretty = =?
>
> Stage: first time we read <1> <2>
> <1> evaluation from left to right all the time.
> add -> as -> sub -> as -> enter -> mul -> as -> div -> as -> enter ->
> shl -> as -> shr -> as -> enter -> pow -> leaveall -> return
> note that in most case there are no dupilcate NAMEs.
> so enter can be igorn. just keep moving
> temporary things cleanup by leaveall....
> no need to care about context, no one can read them, and they affect nothing
> <2> evaluation step by step and direction change every time
> add -> sub <- assign \/ mul -> div <- assign \/ shl -> shr -> assign
> \/ pow return
> should take some mind of context. it's possible that somewhere read
> the temporary var
>
> Stage: not the first time
> <1> calcing A; that is all, move next;
> <2> calc t,s; calc u,v; calc p,q; calc A; move next; step1-3 is useless.
>
>>
>> def R(x, y):
>>    with x+y as t, x-y as s:
>>        with t*s as u, t/s as v:
>>            with u << v as p, u >> v as q
>>                return p**q
>>
>>
>> which is much simpler to read and maintain when written like this:
>>
> <2>
>> def R(x, y):
>>    t, s = x+y, x-y
>>    u, v = t*s, t/s
>>    p, q = u << v, u >> v
>>    return p**q
>>
>>
>> I consider this proposal to encourage excess and unnecessary encapsulation
>> of variables. Not every expression needs to be it's own block.
>>
>>
>> --
>> Steven
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> http://mail.python.org/mailman/listinfo/python-ideas
>>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
'Knowledge is Power'
Daniel Greenfeld
http://pydanny.blogspot.com
http://cartwheelweb.com