Mailman 3 Anaphoric if - Python-ideas - python.org

newer
Re: [Python-ideas] Anaphoric if

Anaphoric if

older
Re: [Python-ideas] Anaphoric if

Andrey Fedorov

23 Apr 2010 23 Apr '10

8:47 p.m.

I imagine this has been covered before, but somehow my Google-foo is failing. What are people's opinions about having an anaphoric-if syntax sugar like: if foo() as x: ... x meaning x = foo() if x: ... x ? I do this a lot, and it seems very un-Pythonically verbose to repeat "x" (especially when a longer variable name is appropriate). Cheers, Andrey

Attachments:

attachment.htm (text/html — 984 bytes)

Reply

Sign in to reply online Use email software

Show replies by date

Benjamin Peterson

23 Apr 23 Apr

8:56 p.m.

Andrey Fedorov writes:

I imagine this has been covered before

It's been rejected many times.

Reply

Sign in to reply online Use email software

Chris Rebert

11:18 p.m.

On Fri, Apr 23, 2010 at 1:47 PM, Andrey Fedorov wrote:

I imagine this has been covered before, but somehow my Google-foo is failing. What are people's opinions about having an anaphoric-if syntax sugar like:

if foo() as x: ... x

meaning

x = foo() if x: ... x

Master Yoda had me google "python-ideas if assignment", which was fruitful: [Python-ideas] Inline assignment expression: http://mail.python.org/pipermail/python-ideas/2009-March/003423.html Post in same thread summarizing rejection reasons: http://mail.python.org/pipermail/python-ideas/2009-March/003440.html Cheers, Chris -- The moratorium makes this pointless anyways. http://blog.rebertia.com

Reply

Sign in to reply online Use email software

Andrey Fedorov

24 Apr 24 Apr

12:39 a.m.

On Fri, Apr 23, 2010 at 7:18 PM, Chris Rebert wrote:

Master Yoda had me google "python-ideas if assignment", which was fruitful:

[Python-ideas] Inline assignment expression: http://mail.python.org/pipermail/python-ideas/2009-March/003423.html

Post in same thread summarizing rejection reasons: http://mail.python.org/pipermail/python-ideas/2009-March/003440.html

Thanks! But, I'm not really thinking about creating an inline assignment expressions: those feel un-Pythonic the same way the ++ operator is. I'm talking about anaphoric if: that is, extending the if_stmt to include ["as" target] after its expression. Actually, that seems to be what the original bug filed was about [1], *not* anything to do with assignment expressions or funky "backwards assignment" syntax who-knows-where. On Mar 15, 2009, Nick Coghlan wrote:

If you look at the current uses for 'as' it is never for direct assignment:

Right, it's used for a different kind of assignment each time. The commonality is that it's used for the "appropriate" assignment for the context, with the target appearing after "as". On Fri, Apr 23, 2010 at 8:23 PM, Jess Austin wrote:

A question for the sake of completeness: would "if not foo() as x: ... x" mean "x = foo(); if not x: ... x"?

No, it would mean: "x = not foo(); if x: ...x". That is, it would be part of the "if" statement, assigning the value of the expression after "if" to the target after "as". It doesn't make sense to me to make exceptions for one kind of expression over another. On Fri, Apr 23, 2010 at 8:26 PM, Raymond Hettinger < raymond.hettinger@gmail.com> wrote:

FWIW, I'm +1 on the idea, especially if it can be also applied to while-loops.

Yup, using doing the same for while-loops makes even more sense. It looks very readable

Agreed.

We do have a language moratorium in effect, so your odds of success are slim.

Patiently counting down the days... :) Cheers, Andrey

Reply

Sign in to reply online Use email software

Bill Janssen

7:58 p.m.

Andrey Fedorov wrote:

On Fri, Apr 23, 2010 at 8:26 PM, Raymond Hettinger < raymond.hettinger@gmail.com> wrote:

...
We do have a language moratorium in effect, so your odds of success are slim.

Patiently counting down the days... :)

You might try adding it to Boo first, which has the same Pythonic syntax and doesn't seem to have a language moratorium in effect. Bill

Reply

Sign in to reply online Use email software

Raymond Hettinger

12:26 a.m.

On Apr 23, 2010, at 1:47 PM, Andrey Fedorov wrote:

I imagine this has been covered before, but somehow my Google-foo is failing. What are people's opinions about having an anaphoric-if syntax sugar like:

if foo() as x: ... x

meaning

x = foo() if x: ... x

?

I do this a lot, and it seems very un-Pythonically verbose to repeat "x" (especially when a longer variable name is appropriate).

Yes, this has come up before. FWIW, I'm +1 on the idea, especially if it can be also applied to while-loops. It looks very readable We do have a language moratorium in effect, so your odds of success are slim. Raymond

Reply

Sign in to reply online Use email software

Nick Coghlan

8 a.m.

Raymond Hettinger wrote:

Yes, this has come up before. FWIW, I'm +1 on the idea, especially if it can be also applied to while-loops. It looks very readable

Agreed, of the sundry embedded assignment proposals that come up semi-regularly, adding "as" clauses to if and while statements is the most viable (although possibly still not a good idea). Any such proposal would be best promoted by mining existing code (such as the standard library) for examples that are improved by the new syntax. The while loop case is actually probably stronger, since it can avoid code repetition in calculating and saving the loop condition once before the start of the loop, and then recalculating it again at the end of the loop. Note that both decorators and the with statement were successful in large part due to the way that they brought visually distant code (after a function definition, after a try block) up to a more semantically appropriate location (before the function definition line, replacing the opening line of the try block). Any discussion of an "as" clause for while statements should at least mention PEP 315 (adding a "do" block to while loops), as that has a similar motivation for avoiding code duplication.

We do have a language moratorium in effect, so your odds of success are slim.

Yes, even if a good proposal is put together for this, it won't be seriously considered until the moratorium is over (which is still years away). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

Reply

Sign in to reply online Use email software

Guido van Rossum

10:48 p.m.

On Sat, Apr 24, 2010 at 1:00 AM, Nick Coghlan wrote:

Raymond Hettinger wrote:

...
Yes, this has come up before. FWIW, I'm +1 on the idea, especially if it can be also applied to while-loops. It looks very readable

Agreed, of the sundry embedded assignment proposals that come up semi-regularly, adding "as" clauses to if and while statements is the most viable (although possibly still not a good idea).

It is not a good idea. In particular it is a mistake to assume that endowing if- and while-statements with special syntax is going to solve anything -- the problem is more generally that *expressions* can't have such effects (in Python) and there's nothing particularly special about the top-level expression in an if-statement. It would be just as likely to have a use case that required (using C syntax) things like if ((p = foo() == NULL) || (q = p->next) != HEAD && q-> next != TAIL) ... Also note that local variable assignment is super-fast so that there is no need to worry about the speed of things like x = foo() if x: compared to the hypothetical if foo() as x: I expect Unladen Swallow would optimize the former anyway. -- --Guido van Rossum (python.org/~guido)

Reply

Sign in to reply online Use email software

Andrey Fedorov

11:01 p.m.

On Sat, Apr 24, 2010 at 6:48 PM, Guido van Rossum wrote:

On Sat, Apr 24, 2010 at 1:00 AM, Nick Coghlan wrote:

...
Raymond Hettinger wrote:

...
Yes, this has come up before. FWIW, I'm +1 on the idea, especially if it can be also applied to while-loops. It looks very readable

Agreed, of the sundry embedded assignment proposals that come up semi-regularly, adding "as" clauses to if and while statements is the most viable (although possibly still not a good idea).

It is not a good idea. In particular it is a mistake to assume that endowing if- and while-statements with special syntax is going to solve anything -- the problem is more generally that *expressions* can't have such effects (in Python) and there's nothing particularly special about the top-level expression in an if-statement.

What about endowing if/while statements with syntax to assign names to their entire predicates only? - Andrey

Reply

Sign in to reply online Use email software

Guido van Rossum

11:24 p.m.

On Sat, Apr 24, 2010 at 4:01 PM, Andrey Fedorov wrote:

On Sat, Apr 24, 2010 at 6:48 PM, Guido van Rossum wrote:

...
On Sat, Apr 24, 2010 at 1:00 AM, Nick Coghlan wrote:

...
Raymond Hettinger wrote:

...
Yes, this has come up before. FWIW, I'm +1 on the idea, especially if it can be also applied to while-loops. It looks very readable

Agreed, of the sundry embedded assignment proposals that come up semi-regularly, adding "as" clauses to if and while statements is the most viable (although possibly still not a good idea).

It is not a good idea. In particular it is a mistake to assume that endowing if- and while-statements with special syntax is going to solve anything -- the problem is more generally that *expressions* can't have such effects (in Python) and there's nothing particularly special about the top-level expression in an if-statement.

What about endowing if/while statements with syntax to assign names to their entire predicates only? - Andrey

Well my point is that it doesn't solve enough problems to make an exception. See the zen of Python: "Special cases aren't special enough to break the rules." Plus the problem it solves is not very important anyway (so the clever response of looking at the next line in the zen doesn't apply :-). -- --Guido van Rossum (python.org/~guido)

Reply

Sign in to reply online Use email software

5115

Age (days ago)

5116

Last active (days ago)

Download

9 comments

7 participants

tags

participants (7)

Andrey Fedorov
Benjamin Peterson
Bill Janssen
Chris Rebert
Guido van Rossum
Nick Coghlan
Raymond Hettinger