[Python-Dev] Re: new syntax for wrapping (PEP 318)

[Bob Ippolito]

On Feb 25, 2004, at 9:56 PM, Josiah Carlson wrote:

>> Just a data point from a user: I use classmethod fairly frequently, 
>> and
>> I would *love* to see some syntax to support it.  As has been pointed
>> out before, classmethod (and staticmethod) are a part of the interface
>> of a function, and shouldn't be tacked on to the end of the body.
>> Please let me put them where people (and hopefully pydoc and 
>> pychecker)
>> can easily see them.
>
> I personally don't see the point of using any syntax for wrapping a
> function like so:
>
> class a:
>     def funct(self):
>         pass
>     a = classmethod(a)

This just isn't valid Python code.. but anyways :)

> If we actually test this:
>
>>>> class a:
> ...     def a(self):
> ...             pass
> ...     def b(self):
> ...             pass
> ...     def c(self):
> ...             pass
> ...     a = classmethod(a)
> ...     b = staticmethod(b)
> ...
>>>> foo = a()
>>>> type(foo.a)
> <type 'instancemethod'>
>>>> type(foo.b)
> <type 'function'>
>>>> type(foo.c)
> <type 'instancemethod'>
>
> It is entirely possible that I'm missing something, but according to
> Python 2.3.2, foo.a and foo.c are the same kind of thing, who am I to
> disagree?

What does the type(object) have to do with anything?  I thought people 
have learned by now that it's not wise to use type for much of 
anything.  You should instead opt for (at least) isinstance(..), 
getattr(...) or preferably a more robust adaptation solution such as 
Zope X3's components, Twisted's components, or PyProtocols (a 
subproject of PEAK).

> For another data point, I've never had to use staticmethod or
> classmethod in my code, and have never needed to use function 
> decorators.

I never had to use Python either, but I think it's a great language 
that let's me work more effectively.  There's nothing I can do in 
Python that I couldn't have done in another language, well, except 
enjoy writing code :)

> In general, I am against the use of arbitrary syntax like the 
> following;
>
> class foo:
>     def a(self) [...]:
>         #body
>     def b(self) <...>: #as paul recently suggested
>         #body
>
> Mostly because it leads to newbies asking what the hell it means.  You
> only need to check the c.l.py newsgroup to discover 3-4 messages/week
> asking about the meaning of *args and **kwargs.  If either of the above
> were allowed, new (and seasoned users for a while) would ask, "what 
> does
> this thing mean, I've never seen anything like it before?"
>
> Honesly, a new (or used) keyword would make the most sense, perhaps 
> "as",
> which has been offered before.  At least then people could check the
> documentation index for "as" and get two listings, one for import
> statements, and one for decorator syntax.  I think something like the
> following would make the most sense (it includes the opportunity for
> multi-line decorators as Barry suggests).
>
> class foo:
>     def a(self) as [...]:
>         #body
>
>
> Even though I think the above is the best syntax I've seen so far, that
> doesn't mean that I like it.  Personally, I don't have any use for
> decorators currently, and could see new and old users of Python being
> stymied by examples of this in new code.  Being able to reverse the
> application order of the decorators, and still have it make sense to a
> not-insignificant number of people, means that it could be confusing.

I am fine with the "as" keyword.  I don't really know how 'newbies' 
think, and an extra 4 characters for clarity doesn't bother me at all.  
Not having this syntax requires A WHOLE !@#$*( lot of verbosity and 
repetition, or drastic measures such as alternative compilers (Quixote) 
or really awful terrible introspection hacks (PEAK does stack 
introspection).

I don't really care, as long as it makes usage much shorter than it is 
currently.  I need this syntax, and I will maintain my own patched 
version of Python or alternate compiler if I have to (which is less 
effort than writing code that has to use existing grammar), but I would 
VERY much rather not.

> I understand its application in PyObjC and in the use of staticmethod,
> but for the vast majority of users, I doubt that adding it would
> result in use.  Certainly it seems like a chicken and egg problem 
> (there
> are a few of those being discussed in c.l.py currently), but in all the
> code I've read "in the wild", I've never once seen anyone manually 
> apply
> decorators to functions.

The vast majority of Python programmers either learned Python before it 
had decorators, hasn't read the documentation for it, or just aren't 
writing the kind of code that needs it.  We have these great new style 
classes now, but it's hard to make any good use of them if it's not 
simple to create descriptors and tag things with metadata.

> I suggest a supporter of the PEP take a look through the standard
> library.  If there exists a non-trivial number of examples of its use,
> maybe my opinion would change.  On the other hand, if in the standard
> library, there exists some _very small number_ of examples of manual
> decorators, then perhaps this is application-specific.  I have a 
> feeling
> that including application-specific /syntax/ in Python is frowned upon.

This isn't at all fair, most (almost all?) of the standard library was 
written before Python had any decorators, by people who wanted 
backwards compatibility (for the most part).  Additionally, the current 
grammar makes decorators so !@#$ inconvenient that nobody wants to use 
them unless they have to.  Look no further than any PEAK or PyObjC 
project to see plenty of decorators.  Especially PEAK.

Off the top of my head, this new syntax would be extremely convenient 
for *at least* the following projects and software that uses them:
	ctypes
	Zope X3
	Twisted
	PEAK / PyProtocols
	PyObjC
	(these two are guesses, I can't say this from experience)
	SQLObject
	Quixote

PyObjC and ctypes need the syntax the most, because both projects 
attempt to make low-level libraries easier to extend and use by 
creating a domain specific languages within Python.  Currently, this is 
only a partial success because defining functions and methods is 
actually harder than in ObjC or C respectively due to this severe 
limitation in Python's grammar.  These projects could be extremely 
popular if they were nicer to use.

As far as numbers go, I guarantee you that once this syntax exists, 
people (at least anyone who uses descriptors and doesn't need backwards 
compatibility) will start using it in droves.  If not "vast majority 
users", at least framework/library writers... you know, the people 
writing the software that gets new users and business types excited 
about Python.

As a bonus, some big abusers of lambda such as PEAK (~333 uses), 
Twisted (~268 uses), and the standard library (~295 uses) may end up 
using this syntax instead, because it covers some of the use cases 
where what you want is really some kind of "anonymous code block".

-bob