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 3 of 3 — ← Prev page 1 2 [3]

#2509

geremy condra wrote:
>> Something to consider is that OOP philosophy is technically one of the most
>> >  aesthetic concepts in all of computer science--- with pure functional
>> >  programming (haskel, erlang) as a close second...
> I like how you inserted the word 'technically' in there to give this
> totally unsubstantiated assertion apparent weight.

You picked up on that, did you?    :-))


I just solved this little difficulty in my own system  ~/bin/

        python -> /home/mydir/local/python2.7/bin/python2

        anaconda -> /home/mydir/local/python3.2/bin/python3

;)


kind regards,
m harris

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

#2506

On 3 Apr 2011, at 15:30, harrismh777 wrote:

> Brian Quinlan wrote:
>> I suspect that this debate is a sink hole that I won't be able to  
>> escape
>> from alive but...
>
> ... live long and prosper my friend.
>
> Something to consider is that OOP philosophy is technically one of  
> the most aesthetic concepts in all of computer science--- with pure  
> functional programming (haskel, erlang) as a close second...

You can keep arguing that but you are tilting at windmills.

Cheers,
Brian

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

#2484

On 4/2/2011 4:29 AM, harrismh777 wrote:

I am responding to both this and a previous post of yours.

Python is not a thing, but an abstraction of multiple parts. It is a 
name, a trademark of the Python Software Foundation. It is a Platonic 
ideal in the mind of Guido and others. It is a series* of versions 
intended to approach that ideal. That goal requires pruning as well as 
additions.

* with three subseries: 0.9 to 2.1, 2.2 to 2.7, 3.0 to 3.x

I call it object-based because in the plain English meaning of the 
words, that is what it is and has been from the start. It is a language 
for manipulating information objects that have identity, value, and 
(type, type or class, and class, respectively, in the three subseries). 
Python is object-based as opposed to memory-block-based, like C and 
other language. Understanding the difference is important for 
understanding or using Python.

[I do not care if before or, more likely, after Guido started Python, 
some other people defined Object-Based Language in a way that excludes 
Python. That does not give them ownership of 'object' and 'based'.]

I do not call Python object-oriented for two reasons.
(And I am not responsible for what anyone else says.)

1. Python started as purely type-based with no classes (in this respect, 
like C).  So if OOP means classes with inheritance, OOP does not apply 
to all of Python. It only became completely class-based in 3.0 when the 
obsolete Class and Instance *types* were omitted. They are still present 
in 2.7.

[The interfaces of these types were and are, of course, published. It is 
ironic that a removal that you philosophically oppose makes your desired 
designation of Python as object-oriented more plausible ;-).]

2. Calling it object-oriented somehow induces some people to fantasize 
that Python 'should' conform to a particular, non-Pythonic idea of OOP 
and that developers 'should' or 'have a responsibility' to conform to 
said person's ideas.

> In other words, does the PSF have a responsibility to maintain the
> L.sort(cmp= key= reverse=) interface for strictly *philosophical*
> principle based on established norms for *any* OOP language?

No.

I say this based on the philosophical principle that obligations are 
reciprocal. Each x.y version (and indeed, each x.y.z release) is a gift 
from the developers to the world, available to anyone who wants it. 
Gifts do not confer obligations on the giver, even if one thinks there 
might be some on the recipient.

In any case, cmp= is still present and has not been removed from any 
version in which it ever appeared. It was not retained in 3.0 because 
Guido thought that omitting it would move 3.0 closer to ideal Python. 
Python 3 was *always* intended to be something of a break from 2.x.

I believe I was one of the first to use the term, during the discussion 
(8 years ago or so) of changing the meaning of int/int (which is to say, 
the meaning of int.__div__(a,b)). I suggested that the first version in 
which the old meaning was dropped should be called 3.0 to *signify that 
there would be some breakage of 2.x code*.

-- 
Terry Jan Reedy

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

#2500

Terry Reedy wrote:
>
>> In other words, does the PSF have a responsibility to maintain the
>> L.sort(cmp= key= reverse=) interface for strictly *philosophical*
>> principle based on established norms for *any* OOP language?
>
> No.
>
> I say this based on the philosophical principle that obligations are
> reciprocal.
>
> In any case, cmp= is still present and has not been removed from any
> version in which it ever appeared. It was not retained in 3.0 because
> Guido thought that omitting it would move 3.0 closer to ideal Python.
> Python 3 was *always* intended to be something of a break from 2.x.
>

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. 
Always learning is lifelong...

Except for the long tradition for an eternal object reference to SPAM 
SPAM SPAM and Monte Python's Flying Circus, perhaps this new pythonesque 
language might be called Anaconda? ... going with the python serpent 
image on the covers of some python books. It does seem that there is a 
sort-of-drive, as it were, towards some ideal concept that is maintained 
in an orderly state of flux while being practically useful and without 
too much disruption... for which I laud the entire team.

Well, winding down the debate side of this thing from my standpoint, if 
Guido does not restore the interface along the lines of my 
*philosophical* ideal, then I cannot see why he would consider restoring 
it at all. Clearly, his own arguments for removing the cmp= are solid, 
well thought out, and make sense from the standpoint technically for 
moving towards Anaconda. The new Python will be lean, clean, and more 
pythonesque than ever before. All is good.

Thanks for the great discussion. For those of you still clam-mering for 
inclusion of the cmp= keyword,   you have my most sincere wishes, 
encouragement, and remorse.   :)


kind regards,

m harris

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

#2548

On 4/3/2011 1:26 AM, harrismh777 wrote:

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

-- 
Terry Jan Reedy

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

#2445

On Fri, 01 Apr 2011 23:54:53 -0500, harrismh777 wrote:

> It cannot be denied that we are talking exclusively about OOP. End of
> story.

Yes it can be denied. You are categorically *wrong*. Python is a multi-
paradigm language that happens to use objects exclusively as its 
fundamental data type, but even a cursory look at the language proves 
that it is not exclusively OOP.

Python supports:

* procedural style programming (like Pascal or Ada or C);
* imperative programming (like shell scripts);
* functional idioms like lambda, map(), reduce(), list comprehensions 
(like Haskell or Lisp);
* alternatives to classes (procedural based programming again).

Important built-ins like len() are not object-oriented; vital commands 
like import are statement-based rather than OO.

All data structures and primitives in Python are objects, but the 
language is not exclusively object-oriented.


-- 
Steven

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

#2499

Steven D'Aprano wrote:
>> >  It cannot be denied that we are talking exclusively about OOP. End of
>> >  story.
> Yes it can be denied.
>
> All data structures and primitives in Python are objects, but the
> language is not exclusively object-oriented.
>

Yeah, I know, Steven. The discussion, from which my quote was pulled 
from context, was in response to whether Python should be viewed as 
object-based or object-oriented. Terry says object-based, my view is 
object-oriented.  (the reasons for both have already been stated)

I can use C++ for procedural programming (and I often do, to take 
advantage of the //comments and iostreams cin and cout). But even though 
I use C++ for procedural programming, I still know at heart that its an 
object-oriented language---and a good thing too, or else there wouldn't 
be an iostreams class to take advantage of.  :)

I view Python the same way--- it is object-oriented and has some 
obligation to the OOA&D paradigm even though it can be used procedurally 
and|or functionally. Of course my functional experimentation and 
research resides almost exclusively with haskel and erlang, I have 
dabbled with Python's lambda and have enjoyed playing a bit with the 
functional aspects of Python... albeit, I still consider Python an 
object oriented language at heart.

I am gaining an understanding for the rich diversity of viewpoints 
within this community regarding the evolution of this fantastic 
language. I had no idea the viewpoints were *so* diverse.

kind regards,
m harris

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

#2287

On 3/31/2011 2:34 AM, harrismh777 wrote:

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

Each x.y version (starting with 2.3) is feature stable: just bug fixes, 
no additions (except as occasionally required to fix a bug), no 
removals. 2.x had few feature changes or removals, as it was planned and 
announced that all the big ones were being delayed to 3.x. 2.7 will be 
polished for years, depending on how long anyone is willing to work on 
it. I have been a bit surprised and disappointed that no 2.x fan has yet 
come forward (that I know of) to specifically help fix 2.7 bugs.

> 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

Python 3 was announced and as a mildly code breaking version at least 5 
years before it came out. Old-style classes were clearly doomed when the 
new object. The int division change was also decided on about that time.

I agree that it would have been better if the developer group had been 
large enough to make the transition more orderly, but ...
as it is, it was not until 2.7 was out that we took a really good look 
at library interfaces and found that 'public interface' was not as well 
defined as it should be for some modules. That is much clearer for many 
in 3.2.

> In the mean time... I'm playing around with 3.2 and really liking it...

Good.

> hoping that the world will actually be using it someday.

I already am and fully expect it to be the dominant version in not too 
many years. Some linux distributions have already made it the default. 
Others have and will hold back.

-- 
Terry Jan Reedy

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

#2338

Terry Reedy wrote:
> Python 3 was announced and as a mildly code breaking version at least 5
> years before it came out.

     I appreciate the spirit of your arguments overall, and I do not 
necessarily disagree with much of what you are saying. I would like to 
challenge you to see this from a little different perspective, if I may.

     There are two distinct ways for looking at this "mild code 
breakage," and it might be good to think about how we approach changes 
in the future based on an understanding of both perspectives, and 
consideration for the clients.

     In the possible perspective of the Python language developers  3x 
changes are mild (in fact, overall, probably even insignificant 
percentage-wise). Ok, we removed the cmp comparison keyword from 
list.sort(), made the print() method consistent with the rest of the 
language, and correctly promoted integer divide 1/2 to float so that the 
answer is something greater than zero! Fine. Looks like just a couple 
little changes, no big deal, stop your whining.

     The perspective of the Class client is something quite different. 
They do not look at the overall percentage of Python language definition 
that has changed (tiny percentage, right) they look at the overall 
percentage of their own projects that have just "broken" and need to be 
rewritten to accommodate the disruption in the advertised Class 
interface. And to the client--  these tiny changes are magna-bodacious! 
(nobbled thinking)  You guys have changed integer divide---!  the PRINT 
print() functionality is diff e r e n t ---! and for crying out loud.... 
you changed   S O R T ( )   !!!

     I wonder if folks like google need to do in-place sorts over lists 
very often ...?

     I wonder how mnay Python scripts call the list.sort() method with 
the cmp keyword specified... ?  (could it be thousands, or millions?)
     All the hoorah you guys are getting, as well all of this incessant 
bickering over cmp,  is some of the answer to these questions.

     When you get ready to change an advertised Class interface in the 
future, please consider my interface rules (I gave them to Steven) and 
please take into account your client base---the ones who are making 
valid assumptions about your Class interfaces.  Its easy, and its most 
considerate.


king regards,
m harris

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

#2382

On 4/1/2011 2:44 AM, harrismh777 wrote:
> Terry Reedy wrote:
>> Python 3 was announced and as a mildly code breaking version at least 5
>> years before it came out.
>
> I appreciate the spirit of your arguments overall, and I do not
> necessarily disagree with much of what you are saying. I would like to
> challenge you to see this from a little different perspective, if I may.

I have, but I consider your perspective, as I understand it, unrealistic

> There are two distinct ways for looking at this "mild code breakage,"
> and it might be good to think about how we approach changes in the
> future based on an understanding of both perspectives, and consideration
> for the clients.

Guido especially and the other developers, generally, try to balance 
benefit and cost. What some may not know is that we consider benefits 
over several years, and benefits to future users as well as current 
users. We hope and expect the former to outnumber the latter in not too 
many years.

The decision, about the time of 2.2, to put off most non-bugfix 
code-breaking changes until 3.0, rather than spread them over the 
remainder of 2.x, was in large part based on the expressed wishes of at 
least some users. (I myself would have preferred sooner and more spread 
out.)

> In the possible perspective of the Python language developers 3x changes
> are mild

Compared to the changes to both the language and implementation Guido 
once considered, they are! But the Perl 6 fiasco and an article by Joel 
Spolsky advocating evolutionary, not revolutionary, software change 
prompted him toward mininal change that would meet objectives. Many 
proposed changes were rejected.

> The perspective of the Class client is something quite different.

There is no 'Class' in Python. Module and function clients have the same 
perspective. Python classes are just instances of class 'type'. Modules, 
instances of class 'module', are sometimes regarded as singleton 
classes. Functions are instances of various classes. Methods are 
functions until bound as instances of bound-method classes. Functions 
are sometimes an alternative to classes, one favored by those of a more 
functional rather than strictly OOP bent.

In any case, you seem to include the interface of class attributes (such 
as the list.sort function) as part of the class interface. Since 
anything can be a class attribute, freezing 'class interfaces' freezes 
everything.

> When you get ready to change an advertised Class interface in the
> future, please consider my interface rules

Taken strictly, they pretty much prohibit anything but implementation 
changes. If we allow the addition of numbered versions of modules, 
classes, and functions, with nothing ever deleted, then we would have 
massive bloat, with attendant maintenance and documentation problems. 
Some modules might be up to v20 by now. Certainly, the switch from ascii 
to unicode as the default text encoding (and I am not sure your rules 
would allow that) changed the interface of nearly every module and a 
large fraction of classes.

Let me reiterate that PSF and Python are not Microsoft and Office. 
Resources are primarily voluntary and limited, but code and even 
binaries are available indefinitely, so no one is forced by *us* to 
switch any particular Python program to any other version of the language.

If you think your rules are workable, try developing a fork that obeys 
them.... but wait, maybe there already is one: 2.7, which will only get 
bugfixes and invisible implementation changes for several years. Of 
course, implementation changes must be screened carefully because in the 
real world, as opposed to the imagined Booch world, it is all to0 easy 
to accidentally introduce an interface change for some corner case.

Also, an implementation change that exchanges space for time will be 
seen an an interface change by somebody. Do you include space-time 
behavior in *your* definition of interface (that should not be changed)?

Indeed, some object to the removal of cmp precisely on this basis, not 
on the fairly trivial code rewrite it entails. This was the case with 
the Google example that prompted this thread. The Googler may well have 
written fresh code, as code breakage was *not* the issue. If the 
list.sort change had been purely an implementation change, if cmp 
remained but its had been changed to use cmp_to_key internally, there 
would have been many of the same objections expressed on this thread anyway.

So why is there a problem with cmp? Because there are people who want 
most of the changes that break your rules, but not this particular one.

-- 
Terry Jan Reedy

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

#2390

Terry Reedy <tjreedy@udel.edu> writes:

> But the Perl 6 fiasco

Perl 6 a complete failure? Wow, must be coming from a clueless Python
zealot. If Perl 6 is a fiasco, so is Python 3. Both are not considered
production ready, and both can be downloaded and used today:

http://rakudo.org/

Next release is planned for later this month.

Did Perl 6 take a long time? Sure. But confusing it with Python 2 ->
Python 3 is just plainly stupid. It's a complete rewrite of Perl, and
it's much easier to think of it as a complete new language instead of
similar to Perl 4 -> 5 and comparable to Python 2 -> 3.

But if you had any idea what you were talking about, you already knew
that.

-- 
John Bokma                                                               j3b

Blog: http://johnbokma.com/    Facebook: http://www.facebook.com/j.j.j.bokma
    Freelance Perl & Python Development: http://castleamber.com/

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

#2421

On Fri, 01 Apr 2011 13:42:11 -0600, John Bokma wrote:

> Terry Reedy <tjreedy@udel.edu> writes:
> 
>> But the Perl 6 fiasco
> 
> Perl 6 a complete failure? 

"Fiasco" does not mean "complete failure". It is a debacle, an 
embarrassing, serious failure, (and also an Italian wine bottle with a 
rounded bottom), but not necessarily complete. It does not imply that a 
fiasco cannot, with great effort and/or time, be eventually recovered 
from. Netscape Navigator 6 was a fiasco, which directly lead to the 
dominance of Internet Explorer in the browser market, but today the heir 
of Netscape, Mozilla's Firefox browser, has regained a majority of the 
browser market in Europe and is catching up on IE world-wide. Those who 
are old enough will remember that Microsoft Word 3.0 was a fiasco, but 
there's no doubt that Word has well recovered to virtually own the entire 
word processing market.


> Wow, must be coming from a clueless Python zealot.

Thanks for sharing.


> If Perl 6 is a fiasco, so is Python 3. Both are not considered
> production ready, and both can be downloaded and used today:

This is FUD about Python 3. Python 3 is absolutely production ready. The 
only reason to avoid Python 3 is if your software relies on a specific 
third-party library that does not yet support Python 3.

On the other hand, the PerlFAQ still describes Perl 6 as not ready:

http://faq.perl.org/perlfaq1.html#What_are_Perl_4_Perl
http://faq.perl.org/perlfaq1.html#What_is_Perl_6_

"Perl 6 is the next major version of Perl, although it's not intended to 
replace Perl 5. It's still in development in both its syntax and design. 
The work started in 2002 and is still ongoing. ..."

"Perl 6 is not scheduled for release yet ..."

Nine years after Perl 6 was started, neither the syntax nor design are 
settled.

The initial PEP for Python 3000 development was in 2006; the first final 
release of Python 3 was in 2008, but I don't count that because Python 
3.0 was fatally flawed and is no longer supported. The first production 
ready release of Python 3.1 was 2009: three years from talking to a 
production-ready version.


> Did Perl 6 take a long time? Sure. But confusing it with Python 2 ->
> Python 3 is just plainly stupid. It's a complete rewrite of Perl, and
> it's much easier to think of it as a complete new language instead of
> similar to Perl 4 -> 5 and comparable to Python 2 -> 3.

What you have described is not a reason for rejecting the claim that Perl 
6 was a fiasco, but the reason for *why* it was a fiasco.



-- 
Steven

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

#2436

Terry Reedy wrote:
>
> So why is there a problem with cmp? Because there are people who want
> most of the changes that break your rules, but not this particular one.

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

Often folks whine about this or that, and they have absolutely no reason 
(or konwledge) upon which to base their whining, and often the rants are 
based in petty jealousy or abstract foolishness.

Please, don't let those morons keep you from seeing my point of view, 
nor from trying to understand where some of your reasonable clients are 
basing their opposition. I'm a scholar, a software design engineer (IBM 
for twenty-five years), and a joyful hacker with enough playful smarts 
to at least be entertaining. Bottom line, I care.

kind regards,

m harris

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web