Emily Bowman wrote:
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.
Currently, the following example is working without any error or warning on the current Guido's build. I'm aware that it is not the final version, but I didn't see anything for now guarding Final decorated values to be overwritten at runtime (either by an affectation or by a case clause). from typing import Final FIVE_VALUE: Final = 5 a = (7, 8) match a: case (FIVE_VALUE, 8): print("in five value clause") case _: print("in default clause") print(f"Value of FIVE_VALUE: {FIVE_VALUE}") But I concede overwriting names that are Final could at least throw some warnings.
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.
My point is a bit deeper. I consider these rules a bit clumsy. I've undestood why they have been designed that way, but they didn't look pythonic. Like if scaffolding was still there.
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.
I'm sorry to disagree. Apple has built its brand on the fact that you didn't need the doc to succesfully use their products. I don't think that all features of the langage have to be that obvious, but the first look by some random dev should help them catch the thing, and avoid such a pitfall. -- Emmanuel