[has this message hit the list? I haven't received it] > > - All given examples in the PEP are easily rewritable with existent > > logic (and I disagree that the new method would be easier to > > understand); > > 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. > > - I can't think about any real usage cases for such object which > > couldn't be easily done without it; > > 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. > 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. > > - The "One True Large Object" isn't "True Large" at all, since depending > > on the comparison order, another object might belive itself to be > > larger than this object. If this was to be implemented as a supported > > feature, Python should special case it internally to support the > > "True" in the given name. > > I don't know how difficult modifying the comparison function to test > whether or not one object in the comparison is the universal max or min, It's not hard at all. It's just a matter of being worth. > so cannot comment. I'm also don't know if defining a __rcmp__ method > would be sufficient. How would two objects with rcmp react? > > - 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. > 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. > > - Any string is already a maximum object for any int/long comparison > > (IOW, do "cmp.high = 'My One True Large Object'" and you're done). > > That also ignores the idea of an absolute minimum. There are two parts Neither of these points are isolated. They just sum to each other to make my own opinion. > 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. > > - 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 discussion. 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. > 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. -- Gustavo Niemeyer http://niemeyer.net
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4