[Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

[Tim Peters]

[Ryan Gonzalez <rymg19 at gmail.com>]
> I have to say I'm not overly thrilled with PEP 572...it's almost odd,
> because if you asked me back when I first joined this list when I was 13, I
> would've no doubt said *YES*. But, since then, I've gone across many
> projects and languages, and fundamentally *I have never felt hurt by the
> lack of assignment in an expression*, and I always regretted every time I
> tried it in C or Crystal. I understand this experience is pretty
> insignificant in comparison to many of the wizards here, but I thought I'd
> still share it as an opener for what I'm about to say.

The older you get, the more you'll regret not still being 13 ;-)


> With this being said, I'd encourage everyone to take a bit of a step back:
> what exactly are people looking for in PEP 572?
>
> I see two main goals:
>
> - Assignment in a conditional structure.
> - Assignment in a list comprehension.
>
> Most other use cases would significantly hurt readability and seem pretty
> rare.

I haven't been much impressed by suggested uses outside conditional
contexts either.


> Now let's break down the top one:
>
> - Assignment in an if condition.
> - Assignment in a while condition.
>
> So there are roughly three main goals here overall. Now, are there better
> ways to solve these?
> ...
> C++ has recently solved the if condition by allowing declarations inside the
> conditions:

But C++ has always had assignment expressions.  This:

> if (auto a = 123; a != 456) {

is solving a different (albeit related) problem:  that C/C++ require
declaring variables before use.  Python doesn't.  They could have done
the same via, .e.g,,

{
    auto a = 123;
    if (a != 456) {
         ...
    }
}

and still have had the scope of `a` limited to one block.
auto-initializers in conditionals just gave a bit of syntactic sugar
for what was already easily (although with more typing) done.


> Many languages have a 'let' expression (using Felix as my example):
>
> if let a = 1, b = 2 in a == b then

I don't read Felix, but I assume the _scope_ of `a` & `b` there ends
immediately before the "then".  If the names can't be used in the
_body_ of a Python `if` (or `while`) block, it's essentially useless
to allow binding names for use solely in the conditional test.

So it would help if you picked "real Python examples" from the many
other earlier messages in these threads.  Python expressions can't
span Python statement boundaries - only Python blocks can do that.  A
form of `let` that _would_ work would be block-structured:

    let m = regexp.match(pattern. line) in:
        if m:
            print(m.group(0))

That solves "a scope problem" the current version of the PEP gave up
on, but in all other respects seems a step back from the current:

    m = regexp.match(pattern, line)
    if m:
        print(m.group(0))


> Swift has taken a bit of a hybrid between the above two:
>
> if let a = 1, b = 2, a == b {

That seems plain incoherent ;-)


> Now, what's the common theme here? **Declarations should be separate from
> expressions.** We've got languages that range from baggage-filled to
> functional to a bit of all of the above, and none of them have added
> assignment *inside* an expression.

C++ and C have always had assignment expressions .  Ditto Java,
Javascript, Perl, Icon,  ... (many, many others).  I don't see a good
reason to grant that Felix and Swift are necessarily improvements over
the former (with the exception of Icon, which I'm merely fond of) very
widely used languages.


> The argument is roughly the same across all boards: you're putting major but
> easy-to-miss side effects in the midst of expressions that *seem* pure.
>
> All this is to say: I'd really encourage everyone here to think a bit more
> about *why* exactly you want this feature, and then think if there's really
> no better way. Any solution that separates declarations would be far more
> readable, (arguably) more Pythonic, and play more nicely with the new-ish
> typing features to boot

People have been trying for years.  If you come up with a realistic
(for Python) idea, that's great - share it!  But it's probably better
suited to python-ideas than python-dev.

>  ...