Hacker News Reader

Comment by AlexandrB | Hacker News Reader

Don't those languages typically have immutable variables so you would not be able to rebind a constant by accident?

This is usually orthogonal to mutability.

In other languages that support match, whether functional or not, you are not changing the value of the variable, but you are shadowing/rebinding the identifier inside the scope of the match clause.

Python `match` statements do not introduce a new scope.

The second example does indeed change the value of `not_found`.

Oh dear, that is indeed very bad.

What's the rationale for not introducing a new scope?

The only clause I can find in the PEP is

> A capture pattern always succeeds. It binds the subject value to the name using the scoping rules for name binding established for named expressions in PEP 572. (Summary: the name becomes a local variable in the closest containing function scope unless there's an applicable nonlocal or global statement.)

This seems... incredibly bad.

It's consistent with how scoping works in loops and `with` clauses. Agreed that it's more problematic here, though.

"Introducing a new scope" is not a concept that exists in Python, you only have function scope and module scope.

There are some exceptions to this - for example, the iteration variable(s) in a list comprehension are only in scope within the comprehension.

Thanks, I didn't realize that. That makes their choice really baffling.

The explanation is that (in Python 3) list comprehensions are really just syntactic sugar for generator expressions. In Python, "scope" is really a synonym for "dictionary attached to some object", so generators can have local variables (since they have their own internal scope), but purely syntactic constructs cannot.

Worth noting that this was _fixed_ in Python 3.

In Python 2.7 you get this:

    >>> my_list = [x for x in 'hello']
    >>> x
    'o'

and class scope

Having only function, module, class, generator, etc. scope in Python before this PEP might have made sense, but they really should have added pattern matching scope to keep things sane here.

That works the same as the rest of the language, doesn't it?

(That is, for, if, while, etc. also don't introduce new scopes.)

So you can easily create a variable in a match case

That's a very problematic design decision, imo...

Doesn’t other languages have block scope and shadowing is not an issue, but in Python it will reassign instead of shadowing?

In my mind that is not well thought out.

Interested in block-level scoping in Python? Please post on the python-ideas mailing list. Thanks.

In Rust no

Reply on news.ycombinator.com