[Python-Dev] Re: PEP 326 now online
jcarlson at uci.edu
Fri Jan 23 14:42:21 EST 2004
> [has this message hit the list? I haven't received it]
[the message hit the list on the afternoon of January 9]
> > You are free to disagree that two objects, which clearly state that they
> > are either the largest or smallest objects, are not clear. I don't know
> > how to address your concern.
> Both of them.
Both of what? Are both the objects not clear? Again, you are free to
believe that objects that self-document are not clear. Would a better
name or location suffice? I'm open for suggestions.
> > It is not whether "if we don't have it we can do it easy", it is about
> > "if we have it, we can do it easier". The Queue module, just recently
> Understood, but not agreed.
Having the objects can make certain kinds of algorithms easier and
clearer to implement. Not having them is what we've had for years.
The only question is where is a location we can put them without
polluting a random namespace with objects that don't fit. Math is out
(Min and Max aren't floating point numbers, which you can read more
about in the PEP), cmp.Min/Max are awkward, min.Min and max.Max seem
strange, operator.Min/Max seems like a reasonable location, but no one
has any feedback on that one yet. Again, I'm open for suggestions.
> > Arguably, there aren't any usage cases where None is necessary. But yet
> > we have None.
> Please, let's not ignore how these usage cases differ in wideness.
Imagine for a moment that None didn't exist. You could create a
singleton instance of an object that represents the same idea as None
and make its boolean false. It would take <10 lines, and do /everything/
that None does.
Take a look at the first few examples in the 'Max Examples' section of
the PEP: http://www.python.org/peps/pep-0326.html#max-examples
Notice the reduction in code from using only numbers, to using None, to
using Max? Notice how each implementation got clearer? That is what
the PEP is about, making code clearer.
> > so cannot comment. I'm also don't know if defining a __rcmp__ method
> > would be sufficient.
> How would two objects with rcmp react?
A better question would be, "How would the comparison between two
objects behave if the object on the left has __cmp__, and the object on
the right has __rcmp__?" Checking the docs, I notice that __rcmp__ is
no longer supported, and hasn't been for a few releases, so never mind.
An even better question would be, "How would two objects with __cmp__
react?" Checking a few examples, it is whoever is on the left side of
the comparison operator.
> > > - It's possible to implement that object with a couple of lines, as
> > > you've shown;
> > I don't see how the length of the implementation has anything to do with
> > how useful it is.
> Let me explain. If you have code that is useful very ocasionally and is
> implemented with three or four lines of code, the standard library is
> not the place for it.
The entire itertools module is filled with examples where just a few
lines of code can save time and effort in re-coding something that
should be there in the first place. The PEP argues the case that a
minimum and maximum value should be placed somewhere accessable.
As stated in the PEP:
"Independent implementations of the Min/Max concept by users desiring
such functionality are not likely to be compatible, and certainly will
produce inconsistent orderings. The following examples seek to show how
inconsistent they can be." (read the PEP for the examples)
> > I (and others) have provided examples of where they would be useful.
> > If you care to see more, we can discuss this further off-list.
> The best place to put useful examples is in the PEP itself. If you have
> further examples of this, please include there. So far I haven't seen
> any examples which are worth such implementation, as I've presented.
The only thing you've "presented" so far is that you think that the
objects are fundamentally useless. On the other hand, no less than 10
people here on python-dev and c.l.py (I didn't even announce it there)
have voiced that the objects themselves are useful if given a proper
name and location.
> > of the proposal, a Maximum and a Minimum. The existance of which has
> > already been agreed upon as being useful. Whether they are in the
> I'd like to be presented with some case where None is not enough,
> preferably with some other argument besides "that's one or two lines
> shorter", since having dozens of "shorter features" contradicts the
> Python oposition to the Perl model.
Both list comprehensions (Python 2.0) and generator expressions (Python
2.4) have been introduced to reduce code length. Heck, generators
themselves reduce the length of code required to create an iterator
object. I remember creating iterators before generators existed in the
base language, talk about a pain in the ass.
> > > - Your Dijkstra example is a case of abusement of tuple's sorting
> > > behavior. If you want readable code as you suggest, try implementing
> > > a custom object with a comparison operator, instead of writting
> > > "foo = (a,b,c,d)", and "(a,b,c,d) = foo", and "foo[x][y]" all over
> > > the place.
> > I don't see how using the features of a data structure already in the
> > standard language is "abuse". Perhaps I should have created my own
> Sorry. I'll try to explain that with softer words to avoid polluting our
> You're trying to introduce a new structure in the language just to turn
> these usage cases into slightly more readable code (in your opinion)
> but at the same time you don't want to use the features already in the
> language which would turn your own example into more readable code and
> would kill the need for the new presented structures.
The minimum and maximum objects are not structures. They are singleton
instances with specific behavior when compared against other objects.
No more, no less.
Hiding the special cases inside a class, doesn't remove the special
cases, it just moves them somewhere else. I could have certainly just
given the class, which would have contained __cmp__ functions that
looked something like this:
def __cmp__(self, other):
return cmp(self.distance, other.distance)
def __cmp__(self, other):
if self.distance is None:
if other.distance is None:
elif other.distance is None:
return cmp(self.distance, other.distance)
Hey, it makes a good case for the PEP; maybe I'll stick it in there if I
have time this afternoon. Thank you for the sugestion.
> > custom class that held all the relevant information, included a __cmp__
> > method, added attribute access and set rutines ...OR... maybe it was
> > reasonable that I used a tuple and saved people the pain of looking
> > through twice as much source, just to see a class, that has nothing to
> > do with the PEP.
> Using examples which are better written in a more clear way inside a PEP
> which is purposing a structure for better readability of code is not a
> good way to convince people.
Are you saying that I should place comments describing what the
algorithm is doing inside the examples? Perhaps.
Thank you for the ideas and suggestions,
More information about the Python-Dev