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
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/5UX2JGDHPGXD4NKKCVHZ55ZSELN63WQD/
Code of Conduct: http://python.org/psf/codeofconduct/
