[Python-ideas] Multiple arguments for decorators

[Nick Coghlan]

On 1 December 2015 at 22:01, Andrew Barnert <abarnert at yahoo.com> wrote:
> On Dec 1, 2015, at 01:56, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> A class based approach like the one suggested here came up in the
>> previous discussion that gave us the current syntax:
>
> I don't know the exact timing here, but I'm willing to bet that at the time that discussion happened:
>
> 1. Python didn't have class decorators yet, and the very notion was seen as obscure and unnecessary.

Class decorators and getter/setter/deleter were both added in 2.6/3.0

Property API additions: http://bugs.python.org/issue1416
Class decorators: https://www.python.org/dev/peps/pep-3129/

> 2. Inner and nested classes were an unfamiliar feature that almost no other major language supported, rather than being fundamental tools in Java. (Which means nobody had yet had to face the "which self" question, for example.)

Java had had inner classes for over a decade by the time 2.6 & 3.0
were released.

> 3. Modern functional/OO hybrids like F# and Scala didn't exist (and OCaml was barely known outside specific academic circles), so the only familiar notion of dynamic class creation was the SmallTalk style, rather than functions that return classes (like namedtuple--although its implementation is more Tcl-ish than anything, the interface is still all about using types as first-class values).

Python itself had had dynamic class creation since the beginning,
though, and new-style classes in 2.2 doubled down on that.

Digging around a bit more, I found one reference to Guido pointing out
his dislike for the nested class based approach was in the context of
Steven Bethard's old "make" statement PEP:
https://www.python.org/dev/peps/pep-0359/

Which also lead me to rediscovering why this particular idea of using
a class with to class decorator to define a property sounded familiar:
https://mail.python.org/pipermail/python-dev/2005-October/057350.html
:)

> So, I'm not sure the objections hold as well today as they did back then. But I'll admit that they're certainly not empty; I'll have to sleep on them, then play with it and see how it really looks.

I think folks are more familiar with the use of class decorators in
general (since they've been around for several years now), but I also
think there's still a general expectation that any defined methods
should behave like normal instance methods.

> But if no variation on either of these feels right enough, I think the current design is the best we're going to do. And it really isn't that bad in the first place. It's not like it's hard to tell what the setter is attached to. And repeating the property name up to two times in the secondary decorators is hardly terrible.

Yep :)

It's an interesting language design conundrum (hence why a range of
folks have been tinkering with various forms of the question for
years), but in *practical* terms it doesn't matter a great deal.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia