[Python-Dev] How about integrating "as" semantics and postpone PEP 572 to Python 4.0

[Guido van Rossum]

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 <koyukukan at 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 at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180705/f0eb48dd/attachment-0001.html>