Guido rethinking removal of cmp from sort method

G

geremy condra

That's certainly true for pure Python code, but for a C extension, the
barrier to Do It Yourself will be much higher for most Python coders.

I don't think people will work around it in C. I think they'll
grudgingly accept a slow and kludgy python workaround, and more to the
point I think they would do that with a vast majority of features at
this scale. That's why I say this isn't a good test here- because you
could apply it to a great feature or a terrible feature and with
overwhelming probability have them fail in both cases.
On the other hand, for a pure Python function or class, you could stick
it on ActiveState's Python cookbook and get some imperfect measure of
popularity and/or usefulness from the comments and votes there.

Frankly, I have little trust in this as a measure of popularity. Even
PyPI isn't a great indicator, and the numbers you get off of
ActiveState are almost certain to be way, way noisier.

Geremy Condra
 
T

Terry Reedy

Very interesting. Your explanations (and other excellent contributions
here) have shown an intense variation of diversity of viewpoint within
at least the comp.lang. community with regard to the Python language.

If you really want to see variation of opinion, check the archives for
discussion of how Python does function call and return.

I take a pragmatic viewpoint toward viewpoints: they are tools, so pick
ones that work for the particular purpose. My purpose is too make the
language easier to learn, especially for those who have not had college
CS/programming courses.
 
L

Lie Ryan

Nice to know! Any chance this wil get into 2.7.x?

Python 2.7 still have list.sort(cmp=...)/sorted(cmp=...), so cmp_to_key
is not much use there. Just pass your comparison function to the cmp
argument.
 
T

Terry Reedy

Python 2.7 still have list.sort(cmp=...)/sorted(cmp=...), so cmp_to_key
is not much use there. Just pass your comparison function to the cmp
argument.

..cmp_to_key was added to ease moving to 3.x or maintaining code usable
on both. A faster version would encourage such use. But it is not a bug
fix exactly, and there is always worry that permanance enhancements may
have unforseen side effects. I will let Raymond make the call on this.
 
T

Terry Reedy

O
fix exactly, and there is always worry that permanance enhancements may
have unforseen side effects. I will let Raymond make the call on this.

/permanance/performance/, /unforseen/unforeseen/
 
R

rantingrick

"Should I use the list, list2, sortable_list, sortable_list2,
sortable_lost3, [note spelling, which we're stuck with forever],
heterogeneous_list, heterogeneous_list_without_stooge_sort, new_list,
fancy_list, fancy_list2, fancy_list_with_extra_oomph, newer_than_new_list
or list3?"

Each and every interface carries a cost. Even if it is small, that cost
must be weighed up against the benefits, rather than declaring that all
interfaces are sacred once published.

Yes and whilst that was a brilliant display of bombastic arrogance
your statements miss the point completely. And to respond i'll pull a
sentence from your own post...
None of those assumptions are even *remotely* true in the real world.

Moving on...
Removing a published interface imposes a one-time cost on those using
that interface, but it has an on-going benefit for all.

Oh really? And what about the large steaming pile of elephant dung in
the room your nose seems to be unable to smell? You just *assume*
that more "new hands" are hopping on board the old Python vessel to
hell than "old hands" are dangling on to the rudders for dear life.
What a naive assumption Mr. D'Aprano!

As we all know Python has experienced an explosion of usage over the
past years, however i would say with the confusions of the Python2 to
Python3 conversion, old tutorials, Ruby's competition, and just plain
mis information in the wild we have cast deep into the throes of a
internal Pythonic rejection-ism and now find ourselves teetering on
the brink of full blown world wide Pythonic recession-ism unless we
get this runaway ship under control very quickly.

Now whilst i agree with most of the changes in Python3 i wonder if
some of them could have waited until Python4. We seemed to have become
so pedantic as to render ourselves blind to the cries of others. And
when i say "others" i am not speaking general "others". No, i am
speaking of fellow tried and true Pythonistas who have many years of
investment in this language. Folks who have vast libraries of Python
code that have been rendered useless because a few elites have spent
too much time lamenting minutia.

Where is the call from on high to rid the web of old Python2.x tuts
and ring in the era of Python3.x compatibility? Where is the energy to
re-ignite the flames of collaborative community? Where is the
leadership this community desperately needs? Where is the excitement
for the future of Python in the old hats? Oh yes i forgot... they're
too busy porting 2.x code to give a flying fig!
 
C

Chris Angelico

olks who have vast libraries of Python
code that have been rendered useless because a few elites have spent
too much time lamenting minutia.

How is the code "rendered useless" when (a) Python 2.7 is still the
default Python in many places, and (b) in any place where it's not,
it's going to be about one command to install a python2?

ChrisA
 
H

harrismh777

rantingrick said:
Yes and whilst that was a brilliant display of bombastic arrogance
your statements miss the point completely.
And what about the large steaming pile of elephant dung in
the room your nose seems to be unable to smell?
As we all know Python has experienced an explosion of usage over the
past years, however i would say with the confusions of the Python2 to
Python3 conversion, old tutorials, Ruby's competition, and just plain
mis information in the wild we have cast deep into the throes of a
internal Pythonic rejection-ism and now find ourselves teetering on
the brink of full blown world wide Pythonic recession-ism unless we
get this runaway ship under control very quickly.

oooh, ouch.


Sadly, there may be some truth in there...

.... to play the advocate for a moment, as the client community we need
to get our heads around the motives of the development community. The
overall goal (it seems) is to make the Python language an 'ideal' that
is admittantly evolving over time. The frustrating thing for the rest of
us is that we now must develop code for two versions--- as well we must
not make assumptions about whether our code will port nicely to other
systems/platforms. While this is frustrating, it is not an
insurmountable mountain of elephant dung... although, I found the
metaphor funny. :)

Python(3) is a new language. It has many of the same characteristics
of Python2, but will be more consistent, cleaner, leaner, more robust...
and certainly loved more universally by more people the world over for
centuries to come.... ;-)

"Bring out yer dead...," "Bring out yer dead..."

:)
 
R

rantingrick

How is the code "rendered useless" when (a) Python 2.7 is still the
default Python in many places,

That's the point. We are going to see Python2.x around for a very long
time. A *very* long time Chris. Sadly if this conversion was planned a
wee bit better, we could have seen it happen rather quickly instead.
We could have reined in the multiplicity instead of propagating it!
and (b) in any place where it's not,
it's going to be about one command to install a python2?

Oh thanks Chris for revealing the simplicity of 2 to 3 code porting.
And might ask where you will begin to volunteer your expertise to the
gazillion lines of code that need porting? hmm?
 
C

Chris Angelico

Oh thanks Chris for revealing the simplicity of 2 to 3 code porting.
And might ask where you will begin to volunteer your expertise to the
gazillion lines of code that need porting? hmm?

That is specifically NOT porting. Sorry, I'm not a 2to3-on-call. I
just code for one platform.

ChrisA
 
S

Steven D'Aprano

Python(3) is a new language. It has many of the same characteristics
of Python2, but will be more consistent, cleaner, leaner, more robust...
and certainly loved more universally by more people the world over for
centuries to come.... ;-)

Only if you define "language" so narrowly that Python 2.1 and Python 2.2
are also different languages, or CPython and Jython or IronPython.

I prefer to consider Python 2.7 and Python 3.x as different dialects of
the same language. There are a very few handful of incompatibilities,
most of which can be automatically resolved by the 2to3 fixers. To
describe them as different "languages" leaves no term to describe the
differences between (say) Python and Cobra:

http://cobra-language.com/docs/python/

let alone something like Python vs Forth.
 
S

Steven D'Aprano

How is the code "rendered useless" when (a) Python 2.7 is still the
default Python in many places, and (b) in any place where it's not, it's
going to be about one command to install a python2?

Please don't feed the troll.

Check the archives. rantingrick isn't interested in good-faith debate.
He's trying to rally followers to lead on his crusade to save Python from
itself (which *entirely* consists of him declaring that there is a
problem, and everyone else dropping what they're doing to do the actual
work of fixing it).
 
H

harrismh777

Steven said:
I prefer to consider Python 2.7 and Python 3.x as different dialects of
the same language. There are a very few handful of incompatibilities,
most of which can be automatically resolved by the 2to3 fixers.

Yes, I am actually finding this to be consistent with my experience of
trying to come up to speed with 3.2. I have been relieved to find that
less has changed than the fear-mongering and bickering was leading me to
believe.

Another item that would be nice as an IDLE enhancement would be a menu
option that applies the fixers (either direction depending on version
2.7 <--> 3.2) right in the IDE. Entries that could not be fixed could be
flagged for manual update.

If there are good tools for app developers to use to make the transition
smoother then the development community won't get their ear chewed off
so ragged, I'm supposing.



kind regards,
m harris
 
T

Terry Reedy

Another item that would be nice as an IDLE enhancement would be a menu
option that applies the fixers (either direction depending on version
2.7 <--> 3.2) right in the IDE. Entries that could not be fixed could be
flagged for manual update.

I have had the same idea, so naturally I agree ;-).
I might even work on it eventually.
 
A

Aahz

Martin deleted the attribution for Carl Banks:

So what do you think about the cmp() builtin? Should have stayed,
or was it ok to remove it?

If it should have stayed: how should it's implementation have looked like?

If it was ok to remove it: how are people supposed to fill out the cmp=
argument in cases where they use the cmp() builtin in 2.x?

Actually, my take is that removing __cmp__ was a mistake. (I already
argued about it back in python-dev before it happened, and I see little
point rehashing it. My reason is strictly efficiency grounds: when
comparisons are expensive -- such as Decimal object -- __cmp__ is
faster.)
 
L

Lie Ryan

Actually, my take is that removing __cmp__ was a mistake. (I already
argued about it back in python-dev before it happened, and I see little
point rehashing it. My reason is strictly efficiency grounds: when
comparisons are expensive -- such as Decimal object -- __cmp__ is
faster.)

I don't get you... why would sorting a list using __cmp__ be faster when
comparisons are expensive?
 
A

Aahz

I don't get you... why would sorting a list using __cmp__ be faster when
comparisons are expensive?

Not sorting (because sorting only requires one comparison), but any
operation involving multiple comparisons. Consider this:

if a < b:
x()
elif a == b:
y()
else:
z()

For a >= b, you need to make two comparisons. Now consider this:

r = cmp(a, b)
if r < 0:
x()
elif r == 0:
y()
else:
z()
--
Aahz ([email protected]) <*> http://www.pythoncraft.com/

"At Resolver we've found it useful to short-circuit any doubt and just
refer to comments in code as 'lies'. :)"
--Michael Foord paraphrases Christian Muirhead on python-dev, 2009-03-22
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top