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

[Guido van Rossum]

Right. I have always felt it important that Python remain usable for
'Joe Developer'.

2011/7/25 Daniel Greenfeld <pydanny at gmail.com>:
> 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
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
--Guido van Rossum (python.org/~guido)