A PEP on introducing variables on 'if' and 'while'
Hello @here, Is there a guide about writing (and publishing) PEPs? I'd like to write one on `while expre as v: ...` using the context semantics of `with expr as v` (not `except E as e`). Cheers,
On Sat, Jun 09, 2018 at 08:43:47AM -0400, Juancarlo Añez wrote:
Hello @here,
Is there a guide about writing (and publishing) PEPs?
https://www.python.org/dev/peps/pep-0001/
I'd like to write one on `while expre as v: ...` using the context semantics of `with expr as v` (not `except E as e`).
Do you mean the context manager semantics of with statements? As in, calling the __enter__ and __exit__ method? Please make sure you are very familiar with PEP 572 before you do, and expect to have your PEP compared to it. Be especially prepared to be challenged with the question what is so special about while and if that they, and they alone, are permitted to use assignment expressions. (You don't have to answer that now provided it is answered in the PEP.) -- Steve
Do you mean the context manager semantics of with statements? As in, calling the __enter__ and __exit__ method?
No. Just the scope of the variables introduced, which is different in `with as` and `except as`.
Please make sure you are very familiar with PEP 572 before you do, and expect to have your PEP compared to it.
My intention would be to make the to proposals orthogonal, if possible, so both/any can be accepted or rejected in their own timeline. I'm certain that both can live together. -- Juancarlo *Añez*
On Sat, Jun 09, 2018 at 09:17:37AM -0400, Juancarlo Añez wrote:
Do you mean the context manager semantics of with statements? As in, calling the __enter__ and __exit__ method?
No. Just the scope of the variables introduced, which is different in `with as` and `except as`.
They aren't. They are the same scope: both `with` and `except` bind to a local variable. The only difference is that the `except` block implicitly unbinds the variable when the block ends. py> err = "something" py> try: ... None + 1 ... except TypeError as err: ... pass ... py> err Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'err' is not defined
Please make sure you are very familiar with PEP 572 before you do, and expect to have your PEP compared to it.
My intention would be to make the to proposals orthogonal, if possible, so both/any can be accepted or rejected in their own timeline.
I'm certain that both can live together.
Seems redundant... while (condition := expression) as flag: ... Accepting "while/if as name" would remove much (but not all) of the motivation for assignment expressions, while accepting assignment expressions would make a dedicated while/if as name syntax unnecessary. Like it or not, I expect that they will be seen as competing PEPs, not independent ones. -- Steve
The only difference is that the `except` block implicitly unbinds the variable when the block ends.
Mmmm. Good to know, because that means that the semantics are the same, except...
while (condition := expression) as flag: ...
Ah! Are the parenthesis necessary there? Accepting "while/if as name" would remove much (but not all) of the
motivation for assignment expressions, while accepting assignment expressions would make a dedicated while/if as name syntax unnecessary.
Most of the arguments in favor of ':=' have been through examples of generators in which the introduced name is used within, with the if/while case often forgotten. There can be cases in which combining both syntaxes is useful: x = None while compute(x := v for v in next_series_value(x)) as comp: ... x = comp
Like it or not, I expect that they will be seen as competing PEPs, not independent ones.
Finding a real-world example of something like the above synthetic example would be in favor of the orthogonality. -- Juancarlo *Añez*
On Sun, Jun 10, 2018 at 10:08 PM, Juancarlo Añez
There can be cases in which combining both syntaxes is useful:
x = None while compute(x := v for v in next_series_value(x)) as comp: ... x = comp
Why not just: while comp := compute(x := v for v in next_series_value(x)): Why have two syntaxes, one of which is a shackled version of the other? If we have :=, there's no point having as. ChrisA
On Sun, Jun 10, 2018 at 08:08:13AM -0400, Juancarlo Añez wrote:
while (condition := expression) as flag: ...
Ah! Are the parenthesis necessary there?
It's your PEP, you tell us.
Accepting "while/if as name" would remove much (but not all) of the motivation for assignment expressions, while accepting assignment expressions would make a dedicated while/if as name syntax unnecessary.
Most of the arguments in favor of ':=' have been through examples of generators in which the introduced name is used within, with the if/while case often forgotten.
Indeed. I think that the generator/comprehension use-cases for assignment expressions are not the most compelling. They're important, but at the point you need to use assignment inside a comprehension, there's a good argument that it *may* be time to refactor to a loop. I think the while/if examples are even more important.
There can be cases in which combining both syntaxes is useful:
x = None while compute(x := v for v in next_series_value(x)) as comp: ... x = comp
But if you have assignment expressions, you don't need "as". x = None while comp := compute(x := v for v in next_series_value(x)): ... x = comp
Finding a real-world example of something like the above synthetic example would be in favor of the orthogonality.
As the PEP author, that's your job. -- Steve
As the PEP author, that's your job.
I started writing the PEP, and I found an interesting example: if not (m := re.match(r'^(\d+)-(\d+)$', identifier): raise ValueError('f{identifier} is not a valid identifier') print(f'first part is {m.group(1)}') print(f'first part is {m.group(2)}') That's fairly easy to understand, and not something that can be resolved with `as` if it's part of the `if` and `while` statement, rather than a different syntax for the `:=` semantics. That one would have to be written as it is done now: m = re.match(r'^(\d+)-(\d+)$', identifier) if not m: raise ValueError('f{identifier} is not a valid identifier') print(f'first part is {m.group(1)}') print(f'first part is {m.group(2)}') -- Juancarlo *Añez*
On 11 June 2018 at 04:35, Juancarlo Añez
As the PEP author, that's your job.
I started writing the PEP, and I found an interesting example:
if not (m := re.match(r'^(\d+)-(\d+)$', identifier): raise ValueError('f{identifier} is not a valid identifier') print(f'first part is {m.group(1)}') print(f'first part is {m.group(2)}')
That's fairly easy to understand, and not something that can be resolved with `as` if it's part of the `if` and `while` statement, rather than a different syntax for the `:=` semantics.
Yep, the "What about cases where you only want to capture part of the conditional expression?" question is the rock on which every "only capture the entire conditional expression" proposal has foundered. PEP 572 arose from Chris deciding to take on the challenge of seriously asking the question "Well, what if we *did* allow capturing of arbitrary subexpressions with inline assignments?". Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (4)
-
Chris Angelico -
Juancarlo Añez -
Nick Coghlan -
Steven D'Aprano