RetroSearch Browse

Wed Feb 25 21:56:25 EST 2004 · https://mail.python.org/pipermail/python-dev/2004-February/042735.html

> 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)

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?

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

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 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.

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.

 - Josiah

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-February/042735.html below:

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