the optional "as" statement inside "if" statements
the idea is to make an variable assignment at the same time that the existence of that variable -- which is being returned by a function -- is made. suppose we are returning a variable from the method 'get' from the 'request' object and them making some stuff with it, but that stuff we will only do if it exists, if not, we'll just pass, instead of writing: variable = self.request.get('variable') if variable: print variable we could write if self.request.get('variable') as variable: print variable seems stupid (or not?), but with lots of variables to process, this pre-assignment could be very unpleasant -- especially if, as the in the example case, very little use will be made of the tested variable. also, the "as" expression already exists and is very pythonic.
On Sat, Jun 30, 2012 at 9:59 AM, <fiatjaf@yahoo.com.br> wrote:
the idea is to make an variable assignment at the same time that the existence of that variable -- which is being returned by a function -- is made.
suppose we are returning a variable from the method 'get' from the 'request' object and them making some stuff with it, but that stuff we will only do if it exists, if not, we'll just pass, instead of writing:
variable = self.request.get('variable') if variable: print variable
we could write
if self.request.get('variable') as variable: print variable
seems stupid (or not?), but with lots of variables to process, this pre-assignment could be very unpleasant -- especially if, as the in the example case, very little use will be made of the tested variable.
also, the "as" expression already exists and is very pythonic.
This is probably the best solution to the problem that would fit in the language, but I'm not convinced doing it at all fits very well. +0
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy
Calvin Spealman wrote:
On Sat, Jun 30, 2012 at 9:59 AM, <fiatjaf@yahoo.com.br> wrote:
the idea is to make an variable assignment at the same time that the existence of that variable -- which is being returned by a function -- is made.
suppose we are returning a variable from the method 'get' from the 'request' object and them making some stuff with it, but that stuff we will only do if it exists, if not, we'll just pass, instead of writing:
variable = self.request.get('variable') if variable: print variable
we could write
if self.request.get('variable') as variable: print variable
seems stupid (or not?), but with lots of variables to process, this pre-assignment could be very unpleasant -- especially if, as the in the example case, very little use will be made of the tested variable.
also, the "as" expression already exists and is very pythonic.
This is probably the best solution to the problem
What problem? I'm not convinced that what fiatjaf@yahoo.com.br describes is an actual problem that needs solving. So what if you have to bind a reference to a name before using it in an if statement? That's not a problem. "Solving" it doesn't make programming any easier, or give you more power. There is absolutely no difference in programming power or expressiveness between: if func(a, b) as x: process(x) and x = func(a, b) if x: process(x) (In fact, I would argue that the second is *slightly* more readable, as the name binding comes first, not last.) At best, this proposal merely adds a trivial bit of syntactic sugar to the language. Contrast that with "import as", which truly does add expressiveness to the language. Working around the lack of "import as" if Python didn't have it would not be so easy. The obvious solution is also the wrong solution: # import long_name as ln import long_name ln = long_name del long_name That's wrong, because it has the side-effect of replacing, then deleting, any existing binding to long_name. "import as" does not do that. Good suggestions for syntactic sugar should add power or expressiveness to the language, not merely save a line of code or a few keystrokes. As given, this idea becomes one more special case for people to learn, with no corresponding benefit. -1 on the idea as given. By the way, to the Original Poster, please configure your mail client to display a name that we can refer to you by, or sign your posts. It doesn't have to be your real name, just something that you would like to be known as. It is annoying to have to refer to you by your email address. -- Steven
On Jun 30, 2012 9:00 AM, <fiatjaf@yahoo.com.br> wrote:
the idea is to make an variable assignment at the same time that the
existence of that variable -- which is being returned by a function -- is made.
suppose we are returning a variable from the method 'get' from the
'request' object and them making some stuff with it, but that stuff we will only do if it exists, if not, we'll just pass, instead of writing:
variable = self.request.get('variable') if variable: print variable
we could write
if self.request.get('variable') as variable: print variable
seems stupid (or not?), but with lots of variables to process, this
pre-assignment could be very unpleasant -- especially if, as the in the example case, very little use will be made of the tested variable.
also, the "as" expression already exists and is very pythonic.
I like it! I've found myself annoyed by writing an if statement using the result of a function call, then realizing "oh wait, I need a reference to that value" and have to go back and rewrite. This would eliminate that and, to my mind, it flows very nicely. +1 from me.
On Sat, Jun 30, 2012 at 11:59 PM, <fiatjaf@yahoo.com.br> wrote:
the idea is to make an variable assignment at the same time that the existence of that variable -- which is being returned by a function -- is made.
suppose we are returning a variable from the method 'get' from the 'request' object and them making some stuff with it, but that stuff we will only do if it exists, if not, we'll just pass, instead of writing:
variable = self.request.get('variable') if variable: print variable
we could write
if self.request.get('variable') as variable: print variable
seems stupid (or not?), but with lots of variables to process, this pre-assignment could be very unpleasant -- especially if, as the in the example case, very little use will be made of the tested variable.
also, the "as" expression already exists and is very pythonic.
This proposal has been considered and rejected many times. It's not general enough - it *only* works for those cases where the value to be retained *and* the interesting condition are the same. Consider the simple case of a value that may be either None (not interesting) or a number (interesting). Since the interesting values include "0", which evaluates as False along with None, this limited form of embedded assignment syntax would not help. Embedded assignment in C isn't that limited., but nobody has yet volunteered to take the radical step of proposing "(X as Y)" as a general embedded assignment syntax. I suggest anyone consider such an idea do a *lot* of research in the python-ideas archives first, though (as the idea has seen plenty of discussion). It is not as obviously flawed as the if-and-while statement only variant, but it would still involve being rather persuasive to make such a significant change to the language. You're also unlikely to get much in the way of core developer feedback until after the 3.3 release in August. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
thank you two for the responses. I'm a newbie here and I didn't find the archives (yes, I'm stupid, and I didn't search well). I have no hope of being persuasive, I only thought that if I introduced the idea other people would like it instantenously, but if the idea is good, obviously someone had already thought of it, so it makes me happy. I'll look for the archives and keep watching the development and see what I get from this. On Sat, Jun 30, 2012 at 12:06 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Sat, Jun 30, 2012 at 11:59 PM, <fiatjaf@yahoo.com.br> wrote:
the idea is to make an variable assignment at the same time that the existence of that variable -- which is being returned by a function -- is made.
suppose we are returning a variable from the method 'get' from the 'request' object and them making some stuff with it, but that stuff we will only do if it exists, if not, we'll just pass, instead of writing:
variable = self.request.get('variable') if variable: print variable
we could write
if self.request.get('variable') as variable: print variable
seems stupid (or not?), but with lots of variables to process, this pre-assignment could be very unpleasant -- especially if, as the in the example case, very little use will be made of the tested variable.
also, the "as" expression already exists and is very pythonic.
This proposal has been considered and rejected many times. It's not general enough - it *only* works for those cases where the value to be retained *and* the interesting condition are the same.
Consider the simple case of a value that may be either None (not interesting) or a number (interesting). Since the interesting values include "0", which evaluates as False along with None, this limited form of embedded assignment syntax would not help.
Embedded assignment in C isn't that limited., but nobody has yet volunteered to take the radical step of proposing "(X as Y)" as a general embedded assignment syntax. I suggest anyone consider such an idea do a *lot* of research in the python-ideas archives first, though (as the idea has seen plenty of discussion). It is not as obviously flawed as the if-and-while statement only variant, but it would still involve being rather persuasive to make such a significant change to the language.
You're also unlikely to get much in the way of core developer feedback until after the 3.3 release in August.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
The only hope for a large archive like this one is to wait long enough to make sure you dont re hash the really regular ideas. ... ponders... Do I have time to read the archives? Do people mind adminiing the repetitive ideas? -- Be prepared to have your predictions come true
On Sun, Jul 1, 2012 at 1:54 AM, Christopher Reay <christopherreay@gmail.com> wrote:
The only hope for a large archive like this one is to wait long enough to make sure you dont re hash the really regular ideas.
... ponders... Do I have time to read the archives? Do people mind adminiing the repetitive ideas?
It's more a matter of working out how to point Google (or the search engine of your choice) at the archives in a useful way. In this case: https://www.google.com/search?q=inurl%3Apython-ideas%20site%3Amail.python.or... Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
How many times have you told people that? -- Be prepared to have your predictions come true
On 6/30/2012 11:54 AM, Christopher Reay wrote:
The only hope for a large archive like this one is to wait long enough to make sure you dont re hash the really regular ideas.
... ponders... Do I have time to read the archives?
If you have time to post and discuss an idea, you have time to search gmane.comp.python.ideas at search.gmane.org and perhaps find out why not to bother posting. ? Do people mind adminiing the repetitive ideas? yes. -- Terry Jan Reedy
On Sun, 1 Jul 2012 01:06:39 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
This proposal has been considered and rejected many times. It's not general enough - it *only* works for those cases where the value to be retained *and* the interesting condition are the same.
Consider the simple case of a value that may be either None (not interesting) or a number (interesting). Since the interesting values include "0", which evaluates as False along with None, this limited form of embedded assignment syntax would not help.
What Nick failed to point out is that the existing uses of "as" all bind *specific classes of objects*, not general ones.
Embedded assignment in C isn't that limited., but nobody has yet volunteered to take the radical step of proposing "(X as Y)" as a general embedded assignment syntax. I suggest anyone consider such an idea do a *lot* of research in the python-ideas archives first, though (as the idea has seen plenty of discussion). It is not as obviously flawed as the if-and-while statement only variant, but it would still involve being rather persuasive to make such a significant change to the language.
Hasn't the BDFL rejected a general embedded assignment in any case? As a final note, reading checking the archives for your ideas will also give you an idea of what kinds of things are and aren't accepted (i.e. - what's "Pythonic") as well as process - including the kinds of questions you'll be asked here - that an idea goes through before being accepted. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
There's no point doing this in Python since scoping is function-level and not lexical. Just move the assignment to the line preceding the if statement. On Sun, Jul 1, 2012 at 8:48 AM, Mike Meyer <mwm@mired.org> wrote:
On Sun, 1 Jul 2012 01:06:39 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
This proposal has been considered and rejected many times. It's not general enough - it *only* works for those cases where the value to be retained *and* the interesting condition are the same.
Consider the simple case of a value that may be either None (not interesting) or a number (interesting). Since the interesting values include "0", which evaluates as False along with None, this limited form of embedded assignment syntax would not help.
What Nick failed to point out is that the existing uses of "as" all bind *specific classes of objects*, not general ones.
Embedded assignment in C isn't that limited., but nobody has yet volunteered to take the radical step of proposing "(X as Y)" as a general embedded assignment syntax. I suggest anyone consider such an idea do a *lot* of research in the python-ideas archives first, though (as the idea has seen plenty of discussion). It is not as obviously flawed as the if-and-while statement only variant, but it would still involve being rather persuasive to make such a significant change to the language.
Hasn't the BDFL rejected a general embedded assignment in any case?
As a final note, reading checking the archives for your ideas will also give you an idea of what kinds of things are and aren't accepted (i.e. - what's "Pythonic") as well as process - including the kinds of questions you'll be asked here - that an idea goes through before being accepted.
<mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/ Independent Software developer/SCM consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On Wed, Jul 4, 2012 at 12:19 PM, Matt Joiner <anacrolix@gmail.com> wrote:
There's no point doing this in Python since scoping is function-level and not lexical. Just move the assignment to the line preceding the if statement.
I'm not sure what distinction you want to draw here between "lexical scoping" and "function-level scoping". Is your issue that scopes cannot be inferred during the lexing phase? Or is it something else? Generally, AIUI, because lexical scoping is only really interesting in contrast to static scoping, any variable whose scope can be determined statically based on where it's defined is considered "lexically scoped". -- Devin
On 2012-07-04, at 18:35 , Devin Jeanpierre wrote:
On Wed, Jul 4, 2012 at 12:19 PM, Matt Joiner <anacrolix@gmail.com> wrote:
There's no point doing this in Python since scoping is function-level and not lexical. Just move the assignment to the line preceding the if statement.
I'm not sure what distinction you want to draw here between "lexical scoping" and "function-level scoping". Is your issue that scopes cannot be inferred during the lexing phase? Or is it something else?
Guessing he misused "lexical scoping" for block-based scoping (as in e.g. C) or explicit scoping constructs (e.g. `let`-type constructs).
Generally, AIUI, because lexical scoping is only really interesting in contrast to static scoping
And I see you miswrite as well, "lexical scoping" and "static scoping" are the same thing, and opposed to "dynamic scoping" (where name resolution traverses the call stack).
Sorry yes I meant block scoping. I assimilated terms from further up in the thread I think. I mean that there can be no temporary/block/localized scope for a name to within the if statement, so there's no reason not to put it on the line above. FWIW I've grown fond of function level scoping, it really reduces confusion in closures and encourages smaller functions to avoid name leaks. Go has something like the OP asks for: if x := SomeFunc(); x > 3 { // x scoped only within this block } Haskell also lets you name expressions like: someFunc y@x:xs = ... But in Python I still think this is best: x = some_func() if x > 3: # no scoping :) On Thu, Jul 5, 2012 at 1:30 AM, Masklinn <masklinn@masklinn.net> wrote:
On 2012-07-04, at 18:35 , Devin Jeanpierre wrote:
On Wed, Jul 4, 2012 at 12:19 PM, Matt Joiner <anacrolix@gmail.com> wrote:
There's no point doing this in Python since scoping is function-level and not lexical. Just move the assignment to the line preceding the if statement.
I'm not sure what distinction you want to draw here between "lexical scoping" and "function-level scoping". Is your issue that scopes cannot be inferred during the lexing phase? Or is it something else?
Guessing he misused "lexical scoping" for block-based scoping (as in e.g. C) or explicit scoping constructs (e.g. `let`-type constructs).
Generally, AIUI, because lexical scoping is only really interesting in contrast to static scoping
And I see you miswrite as well, "lexical scoping" and "static scoping" are the same thing, and opposed to "dynamic scoping" (where name resolution traverses the call stack). _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On 2012-07-07, at 18:03 , Matt Joiner wrote:
Haskell also lets you name expressions like:
someFunc y@x:xs = ...
as-patterns have very little relation with what was described in the thread, as they're about keeping the "packed" version of a pattern-matched expression. Guards are probably closer: case someFunc val of x | x > 3 -> …
On 2012-07-04, at 18:19 , Matt Joiner wrote:
There's no point doing this in Python since scoping is function-level and not lexical. Just move the assignment to the line preceding the if statement.
Technically, scoping is *both* lexical and function-level (as opposed to block-based), although writing to a lexical scope is slightly more complex than in other languages with mutable lexical scopes.
participants (11)
-
Calvin Spealman -
Christopher Reay -
Devin Jeanpierre -
fiatjaf＠yahoo.com.br -
Masklinn -
Matt Joiner -
Mike Meyer -
Nick Coghlan -
Steven D'Aprano -
Terry Reedy -
Zachary Ware