On Fri, Apr 1, 2011 at 5:41 PM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > On Fri, 01 Apr 2011 14:31:09 -0700, geremy condra wrote: > >> On Wed, Mar 30, 2011 at 7:13 PM, Steven D'Aprano >> <steve+comp.lang.pyt...@pearwood.info> wrote: >> >> <snip> >> >>> Or, an alternative approach would be for one of the cmp-supporters to >>> take the code for Python's sort routine, and implement your own >>> sort-with- cmp (in C, of course, a pure Python solution will likely be >>> unusable) and offer it as a download. For anyone who knows how to do C >>> extensions, this shouldn't be hard: just grab the code in Python 2.7 >>> and make it a stand- alone function that can be imported. >>> >>> If you get lots of community interest in this, that is a good sign that >>> the solution is useful and practical, and then you can push to have it >>> included in the standard library or even as a built-in. >>> >>> And if not, well, at least you will be able to continue using cmp in >>> your own code. >> >> I don't have a horse in this race, but I do wonder how much of Python >> could actually survive this test. My first (uneducated) guess is "not >> very much"- we would almost certainly lose large pieces of the string >> API and other builtins, and I have no doubt at all that a really >> significant chunk of the standard library would vanish as well. In fact, >> looking at the data I took from PyPI a while back, it's pretty clear >> that Python's feature set would look very different overall if we >> applied this test to everything. > > > I don't understand what you mean by "this test".
I mean testing whether a feature should be in Python based on whether it can meet some undefined standard of popularity if implemented as a third-party module or extension. > I'm certainly not suggesting that we strip every built-in of all methods > and make everything a third-party C extension. That would be insane. Granted, but I think the implication is clear: that only those features which could be successful if implemented and distributed by a third party should be in Python. My argument is that there are many features currently in Python that I doubt would pass that test, but which should probably be in anyway. The conclusion I draw from that is that this isn't a particularly good way to determine whether something should be in standard Python. > Nor do I mean that every feature in the standard library should be forced > to prove itself or be removed. The features removed from Python 3 were > deliberately few and conservative, and it was a one-off change (at least > until Python 4000 in the indefinite future). If something is in Python 3 > *now*, you can assume that it won't be removed any time soon. I may have been unclear, so let me reiterate: I'm not under the impression that you're advocating this as a course of action. I'm just pointing out that the standard for inclusion you're advocating is probably not a particularly good one, especially in this case, and engaging in a bit of a thought experiment about what would happen if other parts of Python were similarly scrutinized. > What I'm saying is this: cmp is already removed from sorting, and we > can't change the past. Regardless of whether this was a mistake or not, > the fact is that it is gone, and therefore re-adding it is a new feature > request. Those who want cmp functionality in Python 3 have three broad > choices: I might quibble over whether re-adding is the same as a new feature request, but as I said- I don't care about cmp. > (1) suck it up and give up the fight; the battle is lost, move on; > > (2) keep arguing until they either wear down the Python developers or get > kill-filed; never give up, never surrender; > > (3) port the feature that they want into a third-party module, so that > they can actually use it in code, and then when they have evidence that > the community needs and/or wants this feature, then try to have it re- > added to the language. > > I'm suggesting that #3 is a more practical, useful approach than writing > another hundred thousand words complaining about what a terrible mistake > it was. Having to do: > > from sorting import csort > > as a prerequisite for using a comparison function is not an onerous > requirement for developers. If fans of functional programming can live > with "from functools import reduce", fans of cmp can live with that. And that's fine, as I said I don't have a horse in this race. My point is just that I don't think the standard you're using is a good one- ISTM that if it *had* been applied evenly we would have wound up with a much less complete (and much less awesome) Python than we have today. That indicates that there are a reasonable number of real-world cases where it hasn't and shouldn't apply. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
