On Thu, Apr 12, 2018 at 9:03 AM, Ethan Furman <et...@stoneleaf.us> wrote:
> On 04/11/2018 02:55 PM, Chris Angelico wrote:
>> On Thu, Apr 12, 2018 at 4:38 AM, Ethan Furman wrote:
>> Context managers and except blocks don't do the same thing though, so
>> it's a false parallel.
> They assign things to names using `as`.  Close enough.  ;)

Okay, but because they don't assign the thing just before the word
'as', it's a dangerous parallel. Worse, a 'with' statement OFTEN
assigns the thing just before the word 'as', making the parenthesized
form frequently, but not always, the same as the unparenthesized.

>> The other two are
>> *dangerous* false parallels, because "with foo as bar:" is
>> semantically different from "with (foo as bar):";
> If `with` is the first token on the line, then the context manager syntax
> should be enforced -- you get one or the other, not both.

That's what I had in the previous version: that 'as' bindings are
straight-up not permitted in 'with' and 'except' headers. I wasn't
able to implement that in the grammar, so I can't demo it for you, but
the fact that this was a special case was *itself* a turn-off to some.
Are special cases special enough to break the rules? Do we want
something that is a subtle bug magnet?

>>> - puts the calculation first, which is what we are used to seeing in
>>> if/while statements; and
>> Not sure what you mean here; if and while statements don't have
>> anything BUT the calculation.
> Which is why we're using to seeing it first.  ;)

Heh. You could just as easily say you're used to seeing it next to the colon :)

>> A 'for' loop puts the targets before the evaluated expression.
> Hmm, good point -- but it still uses a key word, `in`, to delineate between
> the two.

It does, yes. Fortunately we can't have a competing proposal for name
bindings to be spelled "NAME in EXPR", because that's already a thing

>>> - matches already existing expression-level assignments (context
>>> managers,
>>> try/except blocks)
>> They're not expression-level assignments though, or else I'm
>> misunderstanding something here?
> No, just me being sloppy with vocabulary.

Gotcha, no problem.

For myself, I've been back and forth a bit about whether "as" or ":="
is the better option. Both of them have problems. Both of them create
edge cases that could cause problems. Since the problems caused by
":=" are well known from other languages (and are less serious than
they would be if "=" were the operator), I'm pushing that form.
However, the 'as' syntax is a close contender (unlike most of the
other contenders), so if someone comes up with a strong argument in
its favour, I could switch.

Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to