[Python-ideas] Anaphoric if

[Ron Adam]

On 04/24/2010 01:05 PM, Andrey Fedorov wrote:
> On Sat, Apr 24, 2010 at 1:13 PM, Ron Adam <rrr at ronadam.com
> <mailto:rrr at ronadam.com>> wrote:
>
>     On 04/23/2010 07:23 PM, Jess Austin wrote:
>
>      > for the sake of completeness: would the following:
>      >
>      > if not foo() as x:
>      >      ... x
>      >
>      > mean this:
>      >
>      > x = foo()
>      > if not x:
>      >      ... x
>
>
>     I would think it would defined as
>
>          if expression as name:
>              block using name
>
>     Which would be...
>
>         x = not foo()
>         if x:
>             ... x
>
>     So it could be tricky to get the correct behavior unless (expression
>     as name) becomes a valid expression in it self, but then it wouldn't
>     be limited to the if block, so you might as well just use
>     (expression = name).

That should have been (name = expression).


> Err, that is *not* "correct behavior".

What I mean by correct behavior is what the programmer wants... or the 
intended behavior determined by what a programmer needs.


> This is the third time
> I'm repeating myself (not including the subject): I'm talking about an
> *anaphoric if*. That is an if statement which can refer back to its
> predicate, nothing more.

And we are asking you to be more specific about certain details which may 
be clear to you, but not so clear to us.  So rather than repeat yourself, 
try to give good python code examples that clarifies what will happen in 
specific situations as the posters here come up with them.  These details 
need to be worked out very precisely before any idea can be seriously 
considered.  It's nothing personal, it's just how things work here in 
python idea land.


>     Another issue would be, what if x already existed? would it just
>     write over it, or raise a NameError. If it wrote over it, would it
>     be restored after the block to it's previous value? All of this adds
>     unneeded complexity to the language without adding any real benefits.
>
>
> No extra complexity: make it identical to the expanded version. That
> also makes it identical to how the "local" variable in [x for x in ...]
> behaves, which is expected.

I'm  still not sure what you are expecting...

Python 2.6.5:
>>> x = 10
>>> [x for x in range(5)]
[0, 1, 2, 3, 4]
>>> x
4

Python 3.1.2
>>> x = 10
>>> [x for x in range(5)]
[0, 1, 2, 3, 4]
>>> x
10

The behavior of the local variable (x in this case) has been changed so it 
works the same as generator expressions.



>     Yes it reduces the line count by one, but what meaningful use case
>     is enabled with this that we can't already do?
>
>
> The benefit isn't the line, it's the aesthetic of a direct transcription
> of your intentions:
>
> x = foo()
>
> should be reserved for x having meaning in the local scope. Think of it
> this way: is it more natural to say "if you have kids, register them for
> swimming lessons", or "consider your kids. if there are any kids,
> register them for swimming lessons".

The exact order of my (or your) words isn't important to me as long as the 
intended meaning can be understood.

What is more natural has more to do with what I'm use to.  In this case the 
current way python does it is the more natural way for me to do it because 
that is what I'm use to.

Ron