Decorators: an outsider's perspective

Paul Morrow pm_mon at yahoo.com
Sat Aug 14 23:56:37 CEST 2004


Leif K-Brooks wrote:

> Paul Morrow wrote:
> 
>> <says that classmethods should be done based on argument names>
>> Python was built (successfully) on the assumption that obvious 
>> interpretations of the code obviate the need for declarations.  Why 
>> wouldn't we continue with that mindset?
> 
> 
> One of the principles of Python is also "explicit is better than 
> implicit". Your idea, though interesting, doesn't really seem to fit in 
> with that.

I'm really not sure that those 'Zen' items were intended to be absolute 
guiding principles.   For example, we don't (explicitly) declare 
variables.  And I think that the way we indicate blocks of code (via 
indentation) has a somewhat implicit flavor to it as well (it might be 
arguably more explicit if we used curly braces or some such).

I think that a more appropriate principle here would be something like 
'clear is better than ambiguous'.  Ideally, any given Python statement 
should have only one interpretation, shared by the Python system, the 
statement author, and anyone else who might someday read the statement.
Unfortunately, because we have recommended practices that are widely 
used yet *not enforced by the Python system*, code that strays from the 
recommended style can confuse --- or even worse, mislead --- the reader.

For example, if an experienced Python developer was reading someone's 
code and saw the following method...

     class Foo:
	def setX(self, x):
		self.x = x

... I doubt that they would consider the possibility that setX might be 
something other than an instance method of class Foo.  Instead, I 
believe that they would most likely *assume* that the author followed 
the recommended coding conventions.

But setX could be a static method or a class method, if the class later 
declared it as such.  That's wonderfully flexible I know.  But I think 
that we'd all be better off if we didn't have that particular freedom.









More information about the Python-list mailing list