
On Fri, Apr 23, 2010 at 3:47 PM, Andrey Fedorov <anfedorov@gmail.com> wrote:
I like this, and I'd like for it to be in python, although I don't think it will be widely supported because it only saves one line, and the idiom it replaces isn't very common. [Which facts didn't prevent the adoption of '@' decorator syntax, but I digress...] A question for the sake of completeness: would the following: if not foo() as x: ... x mean this: x = foo() if not x: ... x cheers, Jess

On 04/23/2010 07:23 PM, Jess Austin wrote:
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). 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. Yes it reduces the line count by one, but what meaningful use case is enabled with this that we can't already do? Ron

On Sat, Apr 24, 2010 at 1:13 PM, Ron Adam <rrr@ronadam.com> wrote:
Err, that is *not* "correct behavior". 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. Another issue would be, what if x already existed? would it just write over
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. 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". - Andrey

On Sat, Apr 24, 2010 at 11:05, Andrey Fedorov <anfedorov@gmail.com> wrote:
Well, I suspect I am not alone with having never heard of the term "anaphoric if" (and Google backs me up; this very thread is now search result #4 for [anaphoric if]). It seems to come from the Lisp world and is literally nothing more than syntactic sugar for inlining the assignment statement of what is being tested by an 'if' statement. So no fancy restrictive scoping of the variable; this would be dead-simple syntactic sugar. Unless I am wrong in which case poor Andrey will have to repeat himself a fifth time. =) But back to the ``if not foo() as x`` example, that does water down this syntax for me. I would suspect that the places where this occurs I would want what foo() returned to be assigned to x instead of ``not foo()`` as the latter is guaranteed to be a boolean and not some false object that I might want to populate with stuff to make true. -Brett

On Apr 24, 2010, at 11:34 AM, Brett Cannon wrote:
Well, I suspect I am not alone with having never heard of the term "anaphoric if" (and Google backs me up; this very thread is now search result #4 for [anaphoric if]). It seems to come from the Lisp world and is literally nothing more than syntactic sugar for inlining the assignment statement of what is being tested by an 'if' statement. So no fancy restrictive scoping of the variable; this would be dead-simple syntactic sugar.
The term anaphoric reference seems to be from the field of linguistics. Wikipedia gives this explanation: """ An anaphoric reference, when opposed to cataphora, refers to something within a text that has been previously identified. For example, in "Susan dropped the plate. It shattered loudly" the word "it" refers to the phrase "the plate". """ Raymond

On 4/25/2010 1:17 AM, Raymond Hettinger wrote:
And one should take the lesson from linguistics that such constructs are often confusing and ambiguous (e.g., "The dog ate the bird and it died.") This is related to the problem with "if not foo() as x" and moreover "if not foo() and bar() as x:". This doesn't appear to be an obvious win of clarity over "x = not foo() and bar(); if x:" Let's not inherit the bad grammar of natural languages into programming languages. -- Scott Dial scott@scottdial.com scodial@cs.indiana.edu

not to go too far off on an unrelated tangent here but couldn't your use case be covered by polymorphism on the return value of foo, one potential return value representing the if x case while another value representing the branch if none case. this would be similar to the 'maybe' monad in haskell, 'optional' in the ml languages, or the 'null object' pattern in OO. completely representable in python without any addition to the syntax. On 4/24/10, Andrey Fedorov <anfedorov@gmail.com> wrote:

On 04/24/2010 01:05 PM, Andrey Fedorov wrote:
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.
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.
I'm still not sure what you are expecting... Python 2.6.5:
Python 3.1.2
The behavior of the local variable (x in this case) has been changed so it works the same as generator expressions.
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

On 04/23/2010 07:23 PM, Jess Austin wrote:
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). 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. Yes it reduces the line count by one, but what meaningful use case is enabled with this that we can't already do? Ron

On Sat, Apr 24, 2010 at 1:13 PM, Ron Adam <rrr@ronadam.com> wrote:
Err, that is *not* "correct behavior". 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. Another issue would be, what if x already existed? would it just write over
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. 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". - Andrey

On Sat, Apr 24, 2010 at 11:05, Andrey Fedorov <anfedorov@gmail.com> wrote:
Well, I suspect I am not alone with having never heard of the term "anaphoric if" (and Google backs me up; this very thread is now search result #4 for [anaphoric if]). It seems to come from the Lisp world and is literally nothing more than syntactic sugar for inlining the assignment statement of what is being tested by an 'if' statement. So no fancy restrictive scoping of the variable; this would be dead-simple syntactic sugar. Unless I am wrong in which case poor Andrey will have to repeat himself a fifth time. =) But back to the ``if not foo() as x`` example, that does water down this syntax for me. I would suspect that the places where this occurs I would want what foo() returned to be assigned to x instead of ``not foo()`` as the latter is guaranteed to be a boolean and not some false object that I might want to populate with stuff to make true. -Brett

On Apr 24, 2010, at 11:34 AM, Brett Cannon wrote:
Well, I suspect I am not alone with having never heard of the term "anaphoric if" (and Google backs me up; this very thread is now search result #4 for [anaphoric if]). It seems to come from the Lisp world and is literally nothing more than syntactic sugar for inlining the assignment statement of what is being tested by an 'if' statement. So no fancy restrictive scoping of the variable; this would be dead-simple syntactic sugar.
The term anaphoric reference seems to be from the field of linguistics. Wikipedia gives this explanation: """ An anaphoric reference, when opposed to cataphora, refers to something within a text that has been previously identified. For example, in "Susan dropped the plate. It shattered loudly" the word "it" refers to the phrase "the plate". """ Raymond

On 4/25/2010 1:17 AM, Raymond Hettinger wrote:
And one should take the lesson from linguistics that such constructs are often confusing and ambiguous (e.g., "The dog ate the bird and it died.") This is related to the problem with "if not foo() as x" and moreover "if not foo() and bar() as x:". This doesn't appear to be an obvious win of clarity over "x = not foo() and bar(); if x:" Let's not inherit the bad grammar of natural languages into programming languages. -- Scott Dial scott@scottdial.com scodial@cs.indiana.edu

not to go too far off on an unrelated tangent here but couldn't your use case be covered by polymorphism on the return value of foo, one potential return value representing the if x case while another value representing the branch if none case. this would be similar to the 'maybe' monad in haskell, 'optional' in the ml languages, or the 'null object' pattern in OO. completely representable in python without any addition to the syntax. On 4/24/10, Andrey Fedorov <anfedorov@gmail.com> wrote:

On 04/24/2010 01:05 PM, Andrey Fedorov wrote:
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.
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.
I'm still not sure what you are expecting... Python 2.6.5:
Python 3.1.2
The behavior of the local variable (x in this case) has been changed so it works the same as generator expressions.
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
participants (7)
-
Andrey Fedorov
-
Brett Cannon
-
Jess Austin
-
John Graham
-
Raymond Hettinger
-
Ron Adam
-
Scott Dial