On Wed, May 26, 2021 at 01:33:07PM +0200, Stéfane Fermigier wrote:
I think that's a minor win in that you don't have to repeat the variable name.
Repetition is not the main issue, in my own experience. The main issue is the risk of making a typo in the variable's name when passing it as a string (it happens to me all the time, specially when copy-pasting code and forgetting to change the variable's name in every place).
Right, that's the problem with having to repeat the name. The issue is minor when you only have to do it once or twice, especially if the name is only informative rather than functional: Spam = namedtuple('Spam', *fieldnames) Eggs = namedtuple('Egs', *otherfields) # Oops The second line, with it's typo, doesn't really matter. The class name is just informative, it's not functional. But in your framework examples, it does matter: personal_name = permissions('personnal_name', ...) # Oops family_name = permissions('family_name', ...) address = permissions('family_name', ...) # copy-paste error # and many more examples The repetition is an opportunity to slip in functional bugs, not just trivial typos.
Last point that I like in the decorator syntax: it's
I can compose N different decorators and keep the intent obvious:
@acl(READ, WRITE) @constraint(10 < _ < 100) @not_null @indexed @depends_on(whatever) @inject @... first_name: str
Hmm, that's a good point. On the other hand, it would be terribly confusing if the same syntax: @decorate had radically different meaning depending on whether it was followed by a class/function or a bare name. -- Steve