[Python-Dev] Re: new syntax for wrapping (PEP 318)
bob at redivi.com
Wed Feb 25 22:51:24 EST 2004
On Feb 25, 2004, at 9:56 PM, Josiah Carlson wrote:
>> Just a data point from a user: I use classmethod fairly frequently,
>> 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
>> 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):
> 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 'instancemethod'>
> <type 'function'>
> <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
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
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
> class foo:
> def a(self) [...]:
> def b(self) <...>: #as paul recently suggested
> 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
> this thing mean, I've never seen anything like it before?"
> Honesly, a new (or used) keyword would make the most sense, perhaps
> 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 [...]:
> 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
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
> 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
> 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
> 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:
PEAK / PyProtocols
(these two are guesses, I can't say this from experience)
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
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".
More information about the Python-Dev