On Thu, May 27, 2021 at 10:40 AM Matt del Valle <matthewgdv@gmail.com> wrote:
Bikesheddable, but I don't know why having these two be equivalent:
@decorator var @decorator var = None
..would be a problem. Having an implied default of None for var above makes sense to my brain. Do you have an example in mind where you think it would create a problem?
I don't have anything immediately in mind, no, but I think that given the semantics of those two statements are very different, it is at least worthwhile to allow the decorator to know which of them is actually happening (is `None` being assigned to the name or is it maybe just a type hint for that name?). Keep in mind that if no assignment is happening then there is no need to return anything from the decorator, since it will just be lost anyway.
And I'm pretty much 100% positive that even if I can't think of a use-case off the top of my head, there will eventually be a library author (if this proposal is accepted) who will have some cool idea that will require distinguishing these two scenarios. Like for example if this were used for a CLI-building library (think something like Typer) how the assignment to `None` could signify that it is an option with a default value of `None`, whereas the bare name would signify that it is a mandatory argument.
I agree that if we allow both then they should be distinguished somehow. They are different not just in value but in existence since on the next line down "var" will either be just fine or raise a NameError. If the decorator is expecting for some reason to reach into its parent scope and modify this variable, those are two very different situations.
Oh, and I think I've just discovered another thing that I'm not 100% sure I like. Even putting aside that I'm not a fan of decorators on the same line as the statement they are decorating (as I mentioned in an earlier response), you've got examples of variable decorators where no assignment is happening such as:
@decorator var
To me this breaks the symmetry between function decorators, which always decorate a function definition (an implicit form of assignment), and the proposed variable decorators.
They are also confusing in the sense that the decorator is de-facto turning an otherwise invalid python statement legal. If you remove the decorator from the above example you will presumably get a `NameError`.
I imagine this would then have to be special-cased somehow in the language spec so that an undefined name is not evaluated, but only when preceded by a decorator? I don't know, it seems messy to me.
Also, I just can't quite see the value in them if I'm honest, whereas the version that is applied to an assignment statement:
@decorator var: bool = True
And even a bare type-hint version:
@decorator var: bool
seem to me to be far more self-evidently useful.
I am confused why you are okay with @decorator var: bool but not @decorator var Yes, a bare name is currently an error while just a name and a type hint is valid, but the latter doesn't bind anything to the name, and using that identifier is still a NameError. So a decorator presumably can't return a value for either (or it could, but it would always be dropped). What could it do with a name and a type hint that is so much better than just a name? I am still very confused as to the scope of this counter proposal re variable decorating. I have only seen two such examples here @decorator variable # variable = decorator.__decoration_call__(None, "variable") @decorator variable = "spam" # variable = decorator.__decoration_call__(variable, "variable") But what is actually valid to follow a decorator in this proposal? Any simple expression, any expression? Is it limited to assignment espressions? Here are some interesting uses that were brought up in the other thread and I would like to know how they would work. @decorator spam = eggs = cheese = "tomatoes" @decorator spam, eggs, cheese = "tomatoes" @decorator spam, eggs = cheese = "tomatoes" @decorator spam = (eggs := "cheese) @decorator locals()[find_it() or "default"] = spam() Regards, ~Jeremiah