On Sat, Jul 18, 2020 at 3:29 AM <emmanuel.coirier@caissedesdepots.fr> wrote:
> adept at ignoring them, we will again have difficulties when debugging
> as we won't easily see them.
> Besides which, the problem is solved:
>
> namespace.var is a lookup
> var is a store

These rules can't be deduced from a few examples, or from experience from other languages. You have to explicitly learn them. Since newcomers won't propably learn them first (if at all), they won't understand how it works, and they will propably introduce bugs hard to debug. They'll think it's a kind of "swith case" new construct, and will use it that way, completly ignoring the "capturing" property that shows in some cases and not in others.

    match entree[-1]:
        case Sides.SPAM:
            # newcomers will understand that entree[-1] == Sides.SPAM and write the code they need

    SPAM = "spam"
    match entree[-1]:
        case SPAM:
            # newcomers will understand that entree[-1] == "spam" and write the code they need
            # ignoring that now, in the following code, SPAM == anything but "spam"
            # introducing a bug anywhere in the following code where SPAM is expected to hold the
            # initial value

If a constant's actually constant, as in

SPAM: Final = "spam"

then it'll throw an error. Likewise, the first time it does something totally unexpected like insert something into what they thought held a match pattern, it'll break their initial assumptions and hopefully get them to read the documentation, to form a more accurate mental model.

As long as

> namespace.var is a lookup
> var is a store

is big, bold, and front & center in the docs, I think everyone will catch on very quickly and wrap their vars in a class, even if they never use it for more than a glorified switch-case. Designing an entire feature around what someone who's never encountered it before thinks it might do doesn't seem useful, since anyone could bring any number of assumptions.

-Em