Thanks you for writing up a proposal. There have been many proposals made, including 'EXPR as NAME', similar to yours. It even has a small section in the PEP: https://www.python.org/dev/peps/pep-0572/#alternative-spellings. It's really hard to choose between alternatives, but all things considered I have decided in favor of `NAME := EXPR` instead. Your efforts are appreciated but you would just be wasting your time if you wrote a PEP. If you're interested in helping out, would you be interested in working on the implementation of PEP 572?
On Thu, Jul 5, 2018 at 12:21 PM Rin Arakaki <koyuku...@gmail.com> wrote: > Hi, > > I bring a strong proposal that is prematurely rejected but indeed the most > likely to be accepted to our community. > That is to select `as` spelling not `:=` and modify `with` and `except` > statements. Here is this. > > * Below is copy-pasted from my gist: > https://gist.github.com/rnarkk/cdabceaedbdb498d99802a76cc08b549 > > > # `as` assignment expression > > ```python > # This > STATEMENT(EXPR_0 as NAME_0, EXPR_1 as NAME_2, ..., EXPR_n as NAME_n) > > # can always be replaced by > NAME_0 = EXPR_0 > NAME_1 = EXPR_1 > ... > NAME_n = EXPR_n > STATEMENT(NAME_0, NAME_1, ..., NAME_n) > > # except `import` statement since it's special from the beginning which means > no `EXPR` cannot be the left hand of `as` in its statement but simply `NAME`: > `import NAME_0 as NAME_1` > > # This interpretation above is valid no matter how `EXPR_i` uses `NAME_j` (i > > j). > > # When you write > EXPR as NAME_0, NAME_1 > > # it's interpreted as > (EXPR as NAME_0), NAME_1 > > # TODO Should unpacking is allowed by this? > EXPR as (NAME_0, NAME_1) > > # `EXPR as NAME` itself can be `EXPR` and it returns just `EXPR` in `EXPR as > NAME` which means you can write > ((EXPR as NAME_0) as NAME_1) ... as NAME_n > > # or simply like this even at the top level since it's determininable. > EXPR as NAME_0 as NAME_1 ... as NAME_n > > NAME_0 = EXPR as NAME_1 ... as NAME_n > > # Also you can write > f(x=EXPR as NAME) > > # since this is valid and `EXPR as NAME` can be `EXPR`. > f(x=EXPR) > > # And also this is passible. > if (EXPR as NAME).method(): ... > > # The `EXPR` in `EXPR as NAME` is matched as long as possible which means > if 0 < 1 as x: ... > > # is interpreted as > if (0 < 1) as x: ... > > # not > if 0 < (1 as x): ... > > # but also `EXPR` is separated by `,` which means > EXPR_0, EXPR_1 as NAME > > # is interpreted as > EXPR_0, (EXPR_1 as NAME) > > # rather than > (EXPR_0, EXPR_1) as NAME > > # even when used `as` assignment expression in list comprehension, > # you can apply the same rules above first by putting it to `for` loop form. > > # There is no equivalence to type annotation and augmented assignment. > ``` > > > # `with` statement > > - `with` statement will no longer responsible for passing returned value from > `__enter__` to the right hand of `as` in its statement and merely call > `__enter__` when enter the statement and `__exit__` when exit from it an > - Context manager can be renamed simply to context since it will no longer be > manager but context itself. Context object has status of the context and > encapsulates it. > > # `except` statement > > - `except` statement will no longer responsible for passing instance of the > right hand of `as` in its statement. > - Exceptions must be instanciated and also it must be confirmed otherwise > `except` statement could rewrite the class globally. > > > Thanks, > Rin Arakaki > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
