Status of PEP's?

Fernando Pérez fperez528 at yahoo.com
Mon Mar 4 14:26:15 EST 2002


James_Althoff at i2.com wrote:

> Not a problem!  Converts, in fact, get special treatment <wink>.  Seriously
> though, if nothing else, perhaps these PEP 276 discussions have helped to
> highlight Python's wonderful "everything is a first-class object"
> philosophy!

Let me try to organize my thoughts a bit on why I dislike this PEP so 
seriously. I have no problem with the "everything is a first-class object"
philosophy in Python. But I feel that precisely what this pep introduces is a 
bad usage (IMO) of these ideas.

When 'for i in 5' becomes valid, what we are saying is, the object '5' knows 
how to count. Apparently this is ok, but I see problems: '5' is an integer, 
but there are also negative numbers in the integers. So how do we interpret 
'for i in -3'? While one can argue that 0..4 is a 'natural' way to count for 
positive integers, the same argument becomes difficult to make for negative 
numbers. And by the way, as far as counting goes one could argue that 1..5 is 
even more natural, as it truly spans the set of the natural numbers of which 
5 is a member, as opposed to the less 'standard' set of the 'non-negative 
integers less than 5'. But that's a minor nit-pick.

The problem in my view is that when something is an object, its methods 
should do something which is reasonably natural and well defined for _all_ 
instances of a class. So when we ask the integers to have a counting method 
(via an iterator), I would want to have that counter behave sensibly for 
_any_ integer. And unfortunately, there's just no way to make such a 
definition IMHO.

So this ends up introducing lots of context-sensitivity and special-casing 
(things work _this_ way for non-negative integers, which is not too clean but 
commonly useufl, and do _that_ for negative ones because someone thought it 
would be a usefu default...) Down that road lies Perl, and it seems to break 
very harshly the 'explicit is better than explicit' principle of Python 
design which I feel has served the language so well thus far.

So in summary, it's not that I dislike integers being treated truly as 
objects, but rather that I want them to be clean objects. Objects whose 
methods behave in sensible ways for all instances of a class, not full of 
special defaults.

Just my 0.02,

f.



More information about the Python-list mailing list