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

[Paul Morrow]

Michael J. Fromberger wrote:

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

'self' already has a special meaning to experienced Python developers, 
by virtue of its role in the recommended coding practices.  And if you 
ask experienced Python developers who understand the difference between 
class, static, and instance methods, to guess what kind of method this is...

     def foo(cls, a, b): pass

...I bet the majority would correctly guess "class".  So these words 
already do have special significance to *us* when used in the first 
parameter position.  Why not make them significant to the Python system too?


> Good conventions do not prevent ambiguity, they merely help alleviate 
> its effects.  

Maybe the problem is with the word 'ambiguity'.  How about adherence to 
good coding conventions can keep things from being interpreted in 
multiple ways.


> And a "convention" that is enforced by the translator is 
> no longer a convention, but a rule of the language. 

Right.  So a convention becomes a rule.  Sounds like a natural evolution.



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

Me too, but they both have problems.  The staticmethod declaration is in 
conflict with the use of 'self' as the first parameter.  And they both 
require more code than necessary.  Just as it would be unecessary to say...

     def private __foo(self): pass

Declarations aren't needed when an obvious interpretation of the code 
conveys the desired meaning.