PEP 318: Can't we all just get along?

[Neil Zanella]

Ville Vainio <ville at spammers.com> wrote in message news:<du7oel8l5ba.fsf at lehtori.cc.tut.fi>...
> >>>>> "Kevin" == Kevin Smith <Kevin.Smith at sas.com> writes:
> 
>     Kevin> Bear with me, but I'd like to propose one more syntax that
>     Kevin> is simple, easy for newbies to understand, and nowhere near
>     Kevin> as powerful as the current PEP's syntax.  However, it
>     Kevin> doesn't add incoherent, arbitrary syntax either.
> 
>     Kevin> def classmethod foo(x, y, z):
>     Kevin>    pass

> I don't even use static/classmethods, but I can imagine several
> frameworks can use parametrized decorators to their advantage.

Well, allow me to contribute my thoughts on staticmethod and classmethod:
I am barely starting out with Python and my class objects are already
loaded with so many

foo = staticmethod(foo)

statements. In other words these are very useful: they should be part of
Python's syntax. Other than the above proposal, which I think is the most
obvious thing that could be done, I would also like to contribute yet another
syntax:

class Foo:
  # stuff
  classmethods:
    # classmethods here
  staticmethods:
    # staticmethods here

In the spirit of Python, this scheme would lead to even less typing
on average than would be required with Kevin's solution, although I
must admit that Kevin's solution was the very first thing that came
to mind when I was looking for classmethods/staticmethods.

staticmethods are very useful: you can pack related methods in a class
and use them as getters for class objects which need not be differentiated
among instances. It may even be, that due to python's class objects feature
the user never cares to instantiate certain types of classes anyways. For
instance, a class object with staticmethods can simply be used as a
singleton object: very convenient, if it were not for this ugly
staticmethod syntax. And you may ask, what are the advantages
of using staticmethod inside a class as opposed to using
plain methods? The answer to that question is polymorphism:
Imagine a hierarchy of singleton classes derived from a base
class with a common interface. The singleton class objects
can then be processed polymorphically. Class objects, unlike
class instances, are singletons by nature: what a convenient
means of using singletons pythons offers us!

class Person:
  def name():
    return "Sorry, I'm just an abstract class."
  name = staticmethod(name)
  def favoMovie():
    return "Monty Python's Flying Circus"
  favMovie = staticmethod(FavMovie)
  def favFood():
    return "SPAM!"
  favFood = staticmethod(favFood)

class JoeDoe(Person):
  def name():
    return "Joe Doe"
  name = staticmethod(name)

class JaneDoe(Person):
  def name():
    return "Jane Doe"
  name = staticmethod(name)
  def favFood():
    return "Eggs"
  favFood = staticmethod(FavFood)

The other alternative is to attach methods to instances of a common class
after they are created, which is also something that can be done in Python
but not in most other languages.

Note that the getters I have coded, in general may involve more complex
logic than shown here, so that we really do need methods and not palin
variables in such cases.

Overall, allow me to say that OO stuff seems to be much more flexible in an
interpreted environment such as Python than it is in compiled languages.

Feedback welcome,

Regards,

Neil