Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #2274 > unrolled thread

Re: Guido rethinking removal of cmp from sort method

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Guido rethinking removal of cmp from sort method harrismh777 <harrismh777@charter.net> - 2011-03-31 01:34 -0500
    Re: Guido rethinking removal of cmp from sort method Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-03-31 07:51 +0000
      Re: Guido rethinking removal of cmp from sort method harrismh777 <harrismh777@charter.net> - 2011-04-01 01:13 -0500
        Re: Guido rethinking removal of cmp from sort method Chris Angelico <rosuav@gmail.com> - 2011-04-01 17:30 +1100
          Re: Guido rethinking removal of cmp from sort method Paul Rubin <no.email@nospam.invalid> - 2011-04-01 00:45 -0700
            Re: Guido rethinking removal of cmp from sort method Terry Reedy <tjreedy@udel.edu> - 2011-04-01 12:59 -0400
            Re: Guido rethinking removal of cmp from sort method Terry Reedy <tjreedy@udel.edu> - 2011-04-01 14:57 -0400
              Re: Guido rethinking removal of cmp from sort method Paul Rubin <no.email@nospam.invalid> - 2011-04-01 12:22 -0700
                Re: Guido rethinking removal of cmp from sort method Terry Reedy <tjreedy@udel.edu> - 2011-04-01 22:21 -0400
                Re: Guido rethinking removal of cmp from sort method Antoon Pardon <Antoon.Pardon@rece.vub.ac.be> - 2011-04-04 11:34 +0200
                  Re: Guido rethinking removal of cmp from sort method Lie Ryan <lie.1296@gmail.com> - 2011-04-04 23:35 +1000
                    Re: Guido rethinking removal of cmp from sort method Terry Reedy <tjreedy@udel.edu> - 2011-04-04 13:26 -0400
                    Re: Guido rethinking removal of cmp from sort method Terry Reedy <tjreedy@udel.edu> - 2011-04-04 15:05 -0400
                Re: Guido rethinking removal of cmp from sort method Terry Reedy <tjreedy@udel.edu> - 2011-04-04 13:22 -0400
            Re: Guido rethinking removal of cmp from sort method Terry Reedy <tjreedy@udel.edu> - 2011-04-01 15:37 -0400
              Re: Guido rethinking removal of cmp from sort method Paul Rubin <no.email@nospam.invalid> - 2011-04-01 14:37 -0700
                Re: Guido rethinking removal of cmp from sort method Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-02 00:42 +0000
                  Re: Guido rethinking removal of cmp from sort method Paul Rubin <no.email@nospam.invalid> - 2011-04-01 19:31 -0700
                Re: Guido rethinking removal of cmp from sort method Benjamin Peterson <benjamin@python.org> - 2011-04-02 03:31 +0000
                  Re: Guido rethinking removal of cmp from sort method Paul Rubin <no.email@nospam.invalid> - 2011-04-01 20:43 -0700
              Re: Guido rethinking removal of cmp from sort method Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-02 10:13 +0000
                Re: Guido rethinking removal of cmp from sort method rantingrick <rantingrick@gmail.com> - 2011-04-04 14:10 -0700
                  Re: Guido rethinking removal of cmp from sort method Chris Angelico <rosuav@gmail.com> - 2011-04-05 07:41 +1000
                    Re: Guido rethinking removal of cmp from sort method rantingrick <rantingrick@gmail.com> - 2011-04-04 15:16 -0700
                      Re: Guido rethinking removal of cmp from sort method Chris Angelico <rosuav@gmail.com> - 2011-04-05 08:36 +1000
                    Re: Guido rethinking removal of cmp from sort method Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-05 00:47 +0000
                  Re: Guido rethinking removal of cmp from sort method harrismh777 <harrismh777@charter.net> - 2011-04-04 17:09 -0500
                    Re: Guido rethinking removal of cmp from sort method Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-04 23:25 +0000
                      Re: Guido rethinking removal of cmp from sort method harrismh777 <harrismh777@charter.net> - 2011-04-04 20:16 -0500
                        Re: Guido rethinking removal of cmp from sort method Terry Reedy <tjreedy@udel.edu> - 2011-04-05 00:54 -0400
        Re: Guido rethinking removal of cmp from sort method Terry Reedy <tjreedy@udel.edu> - 2011-04-01 13:06 -0400
          Re: Guido rethinking removal of cmp from sort method Paul Rubin <no.email@nospam.invalid> - 2011-04-01 12:28 -0700
          Re: Guido rethinking removal of cmp from sort method harrismh777 <harrismh777@charter.net> - 2011-04-01 23:54 -0500
            Re: Guido rethinking removal of cmp from sort method Chris Angelico <rosuav@gmail.com> - 2011-04-02 16:06 +1100
              Re: Guido rethinking removal of cmp from sort method harrismh777 <harrismh777@charter.net> - 2011-04-02 00:17 -0500
                Re: Guido rethinking removal of cmp from sort method Chris Angelico <rosuav@gmail.com> - 2011-04-02 17:17 +1100
                  Re: Guido rethinking removal of cmp from sort method harrismh777 <harrismh777@charter.net> - 2011-04-02 03:29 -0500
                    Re: Guido rethinking removal of cmp from sort method Brian Quinlan <brian@sweetapp.com> - 2011-04-02 22:14 +1100
                      Re: Guido rethinking removal of cmp from sort method harrismh777 <harrismh777@charter.net> - 2011-04-03 00:30 -0500
                        Re: Guido rethinking removal of cmp from sort method geremy condra <debatem1@gmail.com> - 2011-04-02 22:46 -0700
                          Re: Guido rethinking removal of cmp from sort method harrismh777 <harrismh777@charter.net> - 2011-04-03 02:17 -0500
                        Re: Guido rethinking removal of cmp from sort method Brian Quinlan <brian@sweetapp.com> - 2011-04-03 16:36 +1000
                    Re: Guido rethinking removal of cmp from sort method Terry Reedy <tjreedy@udel.edu> - 2011-04-02 22:14 -0400
                      Re: Guido rethinking removal of cmp from sort method harrismh777 <harrismh777@charter.net> - 2011-04-03 00:26 -0500
                        Re: Guido rethinking removal of cmp from sort method Terry Reedy <tjreedy@udel.edu> - 2011-04-04 01:38 -0400
            Re: Guido rethinking removal of cmp from sort method Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-02 09:39 +0000
              Re: Guido rethinking removal of cmp from sort method harrismh777 <harrismh777@charter.net> - 2011-04-03 00:09 -0500
    Re: Guido rethinking removal of cmp from sort method Terry Reedy <tjreedy@udel.edu> - 2011-03-31 11:26 -0400
      Re: Guido rethinking removal of cmp from sort method harrismh777 <harrismh777@charter.net> - 2011-04-01 01:44 -0500
        Re: Guido rethinking removal of cmp from sort method Terry Reedy <tjreedy@udel.edu> - 2011-04-01 15:13 -0400
          Re: Guido rethinking removal of cmp from sort method John Bokma <john@castleamber.com> - 2011-04-01 13:42 -0600
            Re: Guido rethinking removal of cmp from sort method Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-02 00:58 +0000
          Re: Guido rethinking removal of cmp from sort method harrismh777 <harrismh777@charter.net> - 2011-04-02 00:07 -0500

Page 1 of 3  [1] 2 3  Next page →

#2274 — Re: Guido rethinking removal of cmp from sort method

Antoon Pardon wrote:
> On Sun, Mar 13, 2011 at 12:59:55PM +0000, Steven D'Aprano wrote:
>> The removal of cmp from the sort method of lists is probably the most
>> disliked change in Python 3. On the python-dev mailing list at the
>> moment, Guido is considering whether or not it was a mistake.
>>
>> If anyone has any use-cases for sorting with a comparison function that
>> either can't be written using a key function, or that perform really
>> badly when done so, this would be a good time to speak up.
>
> How about a list of tuples where you want them sorted first item in ascending
> order en second item in descending order.
>
Greetings,

     Not sure here, but thought you folks might want to have another 
viewpoint from someone who is maybe not so close to the trees as to be 
able to comment effectively on the forest.

     Many of you (Guido included) have lost significant sight of a 
critical object oriented philosophical pillar (but not all of you, thank 
goodness). To cut right to the heart of it--- NEVER change an advertised 
interface. Change the implementation to your little hearts desire, but 
never alter an advertised interface (code is based on it, books are 
based on it, tutorials are based on it, college comp sci courses are 
based on it... etc). If cmp parm is utilized and is helpful or perceived 
as useful and existing code requires it then for crying out loud leave 
it alone. I think your overall worship of Guido as Python King has left 
many of you with nobbled thinking.

     On the other hand, this debate and constant bickering is a serious 
rehash of an ancient discussion without any new points--- irritating. 
Take a look at issue 1771  http://bugs.python.org/issue1771 
particularly msg #s 95975 and 95982....  but no, read the whole 
thing.... it is very clear that Guido wants to restructure the python 
language for consistency and elegance (and who can blame him?). He makes 
some very good arguments for the justification of removing the cmp 
keyword from list.sort() and builtin.sorted()/   but, that is not the 
point... he is breaking a fundamental law of object oriented 
programming... don't break and advertised interface (particularly if it 
is useful and people are actually making use of it!).
     This is insane folks.

     Python is one of the most elegant OO languages to gain popular 
appeal and wide-spread use. This sad broken move from 2.x to 3.x has the 
potential of ruining the language for everyone. Many of us dropped JAVA 
(compile once debug everywhere) because it is complicated, a pita to 
use, slow, and actually doesn't port too well on any platform... and 
here we go again with python. How do the developers of python ever 
expect folks to be able to make use of the language into the future when 
every time we turn around the interface is broken or being debated in 
flux?  Many of us want to use the new 3.2+ version, but no one is going 
to ship it pre-installed (probably for many years) because of this 
issue. There is no way to easily migrate, nor backport, and everyone is 
going to be forced to develop code (and have to maintain code) on two 
distinct branches (for many years to come). I suspect that people are 
just going to stick with back versions for a long time.
     We need to get a grip on this, people.

     Guido does not need a use case; he just needs to restore the 
interface that everyone expects. Put up a message to start to use key= 
instead, and plan deprecation for something like five years out... this 
just seems like such a no-brainer to me. But then, maybe its just that 
I'm too inexperienced to know any better.  <sigh>

     In the mean time... I'm playing around with 3.2 and really liking 
it... hoping that the world will actually be using it someday.

Kind regards,
m harris

[toc] | [next] | [standalone]

#2276

On Thu, 31 Mar 2011 01:34:17 -0500, harrismh777 wrote:

>      Many of you (Guido included) have lost significant sight of a
> critical object oriented philosophical pillar (but not all of you, thank
> goodness). To cut right to the heart of it--- NEVER change an advertised
> interface.


Thanks for your comments, M Harris, but I'm afraid you stumble right at 
the first step. The difference between implementation and interface is 
not specific to object-oriented code -- it is no more, or less, an 
"object oriented philosophical pillar" than it is a pillar of functional 
programming, procedural programming, or any other programming paradigm 
(except perhaps spaghetti coding).

Nor should you say "NEVER". To put your advice in other words:

"Once you have added a feature, no matter how badly thought out, broken, 
rarely used, or even actively hated by the entire programming community, 
you must continue supporting it forever, adding more and more cruft 
around it, just in case some obscure piece of software that hasn't been 
maintained for ten years relies on it."

Nobody has forgotten the principle of separating interface from 
implementation. This was not an accidental backwards incompatible 
change, it was a deliberate decision made in the full knowledge that it 
would be a painful move for some, but also in the expectation that *not* 
removing cruft becomes even more painful over time.

Cruft has real costs: maintenance costs, development costs, runtime 
costs, learning costs, and usability costs. Any language which does not 
prune cruft from time to time will ossify and is doing its users a real 
disservice. Just not too often.

Nobody is denying that the loss of list.sort(cmp=...) will hurt some 
people, or some use-cases. The disagreement is over the question of 
whether the pain from its loss outweighs the utility of its removal.

Python is about halfway through the expected migration period from 2.x to 
3.x, and so far it has not been worse or more difficult than expected. 
Support for Python 3 is about what was expected (probably better than 
expected), uptake of Python 3 by users is about what was expected, the 
number of nay-sayers, Negative Nellies and trolls claiming that Python 3 
will destroy the language is about what was expected, and the number of 
credible forks of the language promising to support Python 2 forever is 
exactly what was expected: zero.


[...]
> Many of us dropped JAVA
> (compile once debug everywhere) because it is complicated, a pita to
> use, slow, and actually doesn't port too well on any platform...

Perhaps that's because Java needs to drop some cruft.


> Many of us want to use the new 3.2+ version, but no one is going
> to ship it pre-installed (probably for many years) because of this
> issue.

Wrong. There is at least one Linux distro, Arch, which ships with Python3 
as the system Python. Arch is pretty bleeding edge, but where they go, 
others will follow.

Besides, "pre-installed" loses a lot of importance when installation is 
as easy as "sudo apt-get python3".


> There is no way to easily migrate, nor backport, and everyone is
> going to be forced to develop code (and have to maintain code) on two
> distinct branches (for many years to come).

Your FUD is outdated. There are now many major products which support 
Python 2 and 3, and some of them out of the same code base. Here is a 
small selection:

http://allanmcrae.com/2010/12/python-3-module-support/
http://mail.mems-exchange.org/durusmail/qp/441/
http://nedbatchelder.com/blog/200910/running_the_same_code_on_python_2x_and_3x.html

Note that last link is from 2009.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#2336

Steven D'Aprano wrote:
> The difference between implementation and interface is
> not specific to object-oriented code --

     When I speak of implementation vs interface I am speaking from a 
strictly object oriented philosophy, as pedigree, from Grady Booch, whom 
I consider to be the father of Object Oriented Analysis and Design 
(Booch, OO A&D with apps, 1994). He makes this remarkable statement:
     "The interface of a class is the one place where we assert all of 
the assumptions that a client may make about any instances [objects] of 
the class; the implementation encapsulates details about which no client 
may make assumptions" (Booch, p50, 1994).
     The Class interface holds a "special" firmness which fosters the 
client relationship of trust and assumption, without which OOA&D is 
pointless. The interface of a Class must not change once advertised, and 
once in production. This is specific to OOA&D.
     Encapsulation of the abstractions must reside within the 
implementation about which no one may make assumptions. This is also 
where all of the "cruft" (if any) resides. Cruft never resides at the 
interface, only in the encapsulation of the Class abstractions, and only 
if the Class was poorly designed.

To put my advice in MY other words, here are my two rules about Class 
interface based on Booch, but in terms that are mine, and which are way 
simpler to put into practice:

Rule 1:
     Never change an advertised Class interface.

     Corollary 1)a The Class interface never encapsulates cruft.

     Corollary 1)b The Class implementation usually encapsulates cruft.

     Corollary 1)c Only the Class implementation may be changed.


Rule 2:
     If an advertised Class interface must be changed to remove cruft, 
please re-read Rule #1, and review corollaries 1)a, 1)b, and 1)c.


----

     As an aside, but in response to your straw man argument regarding 
obscure "cruft," none of the bickering regarding this cmp issue is about 
obscure code. We are discussing one of the primary methods of one of the 
primary Class objects are the lovely heart of Python--- the list.sort(). 
This is NOT obscure. Guido arbitrarily altered the interface to one of 
the MOST important Class objects in all of the Python language. This is 
not good, and it does violate the spirit of OOA&D.

     If the interface changes had been left to type promotion on integer 
divide, and the print() method, then folks would probably not be in such 
an uproar over 3x. But Guido over reached the bounds of credulity by 
altering a Class method that *many* people find useful, desirable, 
efficacious and easy... they use it and the love it (right or wrong).
     The client(s) are making assumptions about the List Class interface 
and they have an OOA&D right to do so... and they are left with their 
rear-ends handing out in the breeze because their assumptions are false. 
Not good.

Kind regards,

m harris

[toc] | [prev] | [next] | [standalone]

#2337

On Fri, Apr 1, 2011 at 5:13 PM, harrismh777 <harrismh777@charter.net> wrote:
>    Corollary 1)a The Class interface never encapsulates cruft.

Provably false. Even a well-designed interface, if it is asked to deal
with a changing implementation and changing requirements, will
eventually either acquire cruft, or be found too rigid to be of use.
The only interface immune to this is the transparent interface
(effectively: "just package up the parameters in a single string and
pass it through"), which isn't really an interface at all, it just
exposes something else. In everything else, cruft is a reality that
must be dealt with.

Chris Angelico

[toc] | [prev] | [next] | [standalone]

#2340

Chris Angelico <rosuav@gmail.com> writes:
> Provably false. Even a well-designed interface, if it is asked to deal
> with a changing implementation and changing requirements, will
> eventually either acquire cruft, or be found too rigid to be of use.

What happens then is you define a new interface.  In Microsoft-speak if
the IWhatever interface needs an incompatible extension like new
parameters, they introduce IWhatever2 which supports the new parameters.
They change the implementation of IWhatever so it becomes a wrapper for
IWhatever2 setting the new parameters to default values, to keep
implementing the old behavior.

Removing cmp certainly isn't the most disruptive change of Python 3,
but it seems like the one with the least benefit.

[toc] | [prev] | [next] | [standalone]

#2372

On 4/1/2011 3:45 AM, Paul Rubin wrote:

> Removing cmp certainly isn't the most disruptive change of Python 3,

That was almost certainly the ascii to unicode switch for strings. It is 
still not quite complete in 3.2 but should be pretty well ironed out in 3.3.

> but it seems like the one with the least benefit.

Since the set of changes was finite, there *must* be (at least) one with 
the lowest benefit/cost ratio. The removal of list.sort(cmp) may well be 
that one. Certainly, reasonable people can disagree as to whether the 
ratio is above or below 1.0.

If cmp had not been removed, some other change would have been the worst 
in this respect, and possibly the subject of a thread like this.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#2381

On 4/1/2011 3:45 AM, Paul Rubin wrote:

> What happens then is you define a new interface.

Like key= versus cmp=

>  In Microsoft-speak if
> the IWhatever interface needs an incompatible extension like new
> parameters, they introduce IWhatever2 which supports the new parameters.
> They change the implementation of IWhatever so it becomes a wrapper for
> IWhatever2 setting the new parameters to default values, to keep
> implementing the old behavior.

If cmp had been left (or were reinstated) but its implementation changed 
internally to use cmp_to_key to make it a wrapper for key, you would be 
happy? 2to3 could probably gain a fixer to change

.sort(cmp=f) # to

import functools import cmp_to_key
.sort(key=functools.cmp_to_key(f))

I know some would not like this because interface change is not their 
real concern.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#2384

Terry Reedy <tjreedy@udel.edu> writes:
>> What happens then is you define a new interface.
> Like key= versus cmp=

Well, in an untyped language like Python, adding a feature to an
interface doesn't require defining a new interface unless you change
something incompatibly.  key= is very useful but it can be added without
breaking cmp= .

> 2to3 could probably gain a fixer to change
> .sort(cmp=f) # to
>
> import functools import cmp_to_key
> .sort(key=functools.cmp_to_key(f))
>
> I know some would not like this because interface change is not their
> real concern.

Looks like a good idea.  There is an efficiency hit from the above in
some situations, but at least it prevents code from breaking, so unless
there's some drawback I'm not currently spotting, it's better than
nothing and I'd endorse adding such a wrapper.  2to3 should show some
kind of diagnostic and maybe put a comment into the output code,
when it does that particular transformation, since most of the
time there's probably a better way to write the key function.

[toc] | [prev] | [next] | [standalone]

#2424

On 4/1/2011 3:22 PM, Paul Rubin wrote:

>> 2to3 could probably gain a fixer to change
>> .sort(cmp=f) # to
>>
>> import functools import cmp_to_key
>> .sort(key=functools.cmp_to_key(f))
>>
>> I know some would not like this because interface change is not their
>> real concern.
>
> Looks like a good idea.  There is an efficiency hit from the above in
> some situations, but at least it prevents code from breaking, so unless
> there's some drawback I'm not currently spotting, it's better than
> nothing and I'd endorse adding such a wrapper.  2to3 should show some
> kind of diagnostic and maybe put a comment into the output code,
> when it does that particular transformation, since most of the
> time there's probably a better way to write the key function.

rewriting cmp_to_key in C is underway

http://bugs.python.org/issue11707

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#2560

On Fri, Apr 01, 2011 at 10:21:33PM -0400, Terry Reedy wrote:
> 
> rewriting cmp_to_key in C is underway
> 
> http://bugs.python.org/issue11707
> 
Nice to know! Any chance this wil get into 2.7.x?

-- 
Antoon Pardon

[toc] | [prev] | [next] | [standalone]

#2564

On 04/04/11 19:34, Antoon Pardon wrote:
> On Fri, Apr 01, 2011 at 10:21:33PM -0400, Terry Reedy wrote:
>>
>> rewriting cmp_to_key in C is underway
>>
>> http://bugs.python.org/issue11707
>>
> 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.

[toc] | [prev] | [next] | [standalone]

#2581

On 4/4/2011 9:35 AM, Lie Ryan wrote:
> On 04/04/11 19:34, Antoon Pardon wrote:
>> On Fri, Apr 01, 2011 at 10:21:33PM -0400, Terry Reedy wrote:
>>>
>>> rewriting cmp_to_key in C is underway
>>>
>>> http://bugs.python.org/issue11707
>>>
>> 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.

.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.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#2586

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/


-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#2580

On 4/4/2011 5:34 AM, Antoon Pardon wrote:
> On Fri, Apr 01, 2011 at 10:21:33PM -0400, Terry Reedy wrote:
>>
>> rewriting cmp_to_key in C is underway
>>
>> http://bugs.python.org/issue11707
>>
> Nice to know! Any chance this wil get into 2.7.x?

I posted the question to the issue.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#2387

On 4/1/2011 3:45 AM, Paul Rubin wrote:

> What happens then is you define a new interface.  In Microsoft-speak if
> the IWhatever interface needs an incompatible extension like new
> parameters, they introduce IWhatever2 which supports the new parameters.
> They change the implementation of IWhatever so it becomes a wrapper for
> IWhatever2 setting the new parameters to default values, to keep
> implementing the old behavior.

Now you have two versions, and eventually many more, to maintain and 
document. That takes resources we currently do not have.

Some problems in addition to the benefits of this approach:
1. The users of IWhatever will not gain the benefits of IWhatever2.
2. Upgrading to IWhatever2 requires a change of name as well as off 
parameters.
3. If only some users are upgraded, the IWhatever and IWhatever2 users 
may become incompatible even though they were before, thus breaking code 
without changing the old interface.

Example: Python2 added str2 (= unicode) on top of str. This had all the 
problems listed above. Since CPython uses str internally, in particular 
for identifiers, CPython users were stuck with the limitations of str. 
Rebinding str to mean str2 has many benefits, especially in the future, 
in addition to current costs.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#2410

Terry Reedy <tjreedy@udel.edu> writes:
>> IWhatever2 setting the new parameters to default values
> Now you have two versions, and eventually many more, to maintain and
> document. 

In the case of cmp= there's not two interfaces needed.  Python2 does a
perfectly good job supporting cmp and key with one interface.  We do
have urllib and urllib2 as separate interfaces (with separate
implementations), and we keep some other legacy interfaces around too,
like the sha and md5 modules (both of which are now subsumed by
hashlib).

> That takes resources we currently do not have.

Well ok, but now you're making excuses for instability, which seems like
a problem given Python's self-marketing as a stable, production-class
system that competes with better-funded efforts like Java.

> Example: Python2 added str2 (= unicode) on top of str. This had all
> the problems listed above. Since CPython uses str internally, in
> particular for identifiers, CPython users were stuck with the
> limitations of str. Rebinding str to mean str2 has many benefits,
> especially in the future, in addition to current costs.

That really is a massive change, but a welcome one, because Python2
programs broke all the time due to missed conversions between str and
unicode.  It is the type of thing that a language transition (Python2 to
Python3) is supposed to bring, that goes beyond Interface2 to
Interface3.  There's been a lot of experience gained in the decades
since Python's creation and it's fine to do an overhaul after all these
years.  The issues are 1) don't break stuff unless there's a substantial
benefit; and 2) don't do these major incompatible releases too often.
There should not be any incompatible Python4 before 2020 or so.

I actually think Python3 actually didn't go far enough in fixing
Python2.  I'd have frankly preferred delaying it by a few years, to
allow PyPy to come to maturity and serve as the new main Python
implementation, and have that drive the language change decisions.
Instead we're going to have to give up a lot of possible improvements we
could have gotten from the new implementation.

[toc] | [prev] | [next] | [standalone]

#2420

On Fri, 01 Apr 2011 14:37:20 -0700, Paul Rubin wrote:

> I actually think Python3 actually didn't go far enough in fixing
> Python2.  I'd have frankly preferred delaying it by a few years, to
> allow PyPy to come to maturity and serve as the new main Python
> implementation, and have that drive the language change decisions.
> Instead we're going to have to give up a lot of possible improvements we
> could have gotten from the new implementation.

There's always Python 4000 :)


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#2427

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
> There's always Python 4000 :)

Is that on the boards yet?  

[toc] | [prev] | [next] | [standalone]

#2430

Paul Rubin <no.email <at> nospam.invalid> writes:
> 
> I actually think Python3 actually didn't go far enough in fixing
> Python2.  I'd have frankly preferred delaying it by a few years, to
> allow PyPy to come to maturity and serve as the new main Python
> implementation, and have that drive the language change decisions.
> Instead we're going to have to give up a lot of possible improvements we
> could have gotten from the new implementation.

Why would having PyPy as the reference implementation have made this design
decisions turn out better?

[toc] | [prev] | [next] | [standalone]

#2431

Benjamin Peterson <benjamin@python.org> writes:
> Why would having PyPy as the reference implementation have made this design
> decisions turn out better?

A fair amount of Python 2's design was influenced by what was convenient
or efficient to implement in CPython.  There's nothing wrong with that
and it's a perfectly normal and sensible strategy.  Anyone writing
Python code in a serious way has to maintain some awareness of how
CPython works, so CPython's influence finds its way into Python user
programs too.  With PyPy as the reference implementation, the designers
may find they can take the language in cool new directions that were
impossible with CPython, or alternatively, they might find that adding
minor retrictions (that would count as "breaking more stuff") would give
big advantages under PyPy that weren't significant in CPython.  What
kinds of stuff and is any of it a sure thing?  Unknown.  That's why the
idea was: first get more experience with PyPy, then figure out how it
should affect the language.  

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web