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

Michael J. Fromberger Michael.J.Fromberger at Clothing.Dartmouth.EDU
Wed Aug 18 16:11:47 CEST 2004


In article <mailman.1858.1092832530.5135.python-list at python.org>,
 Paul Morrow <pm_mon at yahoo.com> wrote:

> Dan Sommers wrote:
> > I don't understand how assigning semantic significance to a 
> > "recommended coding practice" is Pythonic.
> > 
> > In the face of ambiguity, refuse to guess.
> > 
> > Explicit is better than implicit.
> 
> Good conventions prevent ambiguity.
> 
>     class Foo:
>        def method1(self, a, b): pass       # clearly an instance method
>        def method2(cls, a, b): pass        # clearly a class method
>        def method3(a, b): pass             # clearly a static method

I think this is a terrible idea.  What you are proposing is essentially 
that Python should assign special meaning to the identifiers "self" and 
"cls" when they appear as the first variable in a method definition 
inside a class.  I am having a hard time thinking of anything LESS in 
the spirit of Python, short of writing in unstructured BASIC.

Good conventions do not prevent ambiguity, they merely help alleviate 
its effects.  And a "convention" that is enforced by the translator is 
no longer a convention, but a rule of the language. 

> When declarations conflict with conventions, it makes us wonder what the 
> author really intended.
> 
>        def staticmethod setX(self, x):
>            self.x = x

I find this at least as easy to understand as the current idiom:

    def setX(self, x):
      self.x = x
    setX = staticmethod(setX)

> You're right, this thread is about decorators, not about more 
> opportunities for dynamic typing. 

Actually, as I read it, this thread is about getting back to the 
original question PEP-318 was intended to answer, rather than all the 
other cruft that the "decorators" idea has become laden with.  

-M

-- 
Michael J. Fromberger             | Lecturer, Dept. of Computer Science
http://www.dartmouth.edu/~sting/  | Dartmouth College, Hanover, NH, USA



More information about the Python-list mailing list