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

#2447

On Fri, 01 Apr 2011 15:37:34 -0400, Terry Reedy wrote:

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

This is exactly the sort of cruft I am talking about. Languages can 
survive a small amount of cruft, but eventually they bloat to the point 
that the only thing keeping them going is inertia. They become dinosaurs, 
like COBOL or PL\I, or bloated monstrosities like .Net, Java or C++ that 
nobody *likes* but merely keep using because they have to.

No offense to anyone who actually likes .Net, C++ or Java *wink*

If we follow this "rule" (more of a guideline really) of no interface 
changes ever, eventually we will be up to Python 5.2 and IWhatever12. 
This imposes serious maintenance costs, documentation costs, learning 
costs for new users, and even decision costs when you write a function:

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

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


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

Exactly. The "no interface changes ever" rule assumes that the human 
resources dedicated to maintenance are unlimited, that the cost of 
keeping multiple interfaces around is zero, and that the cost of removing 
an interface is infinite.

None of those assumptions are even *remotely* true in the real world.

(If the cost of removal were assumed to be merely large, or even huge, 
then there could be circumstances where the benefit outweighed the cost, 
and the rule would be "*Almost* never change a published interface".)

To be sure, interface stability is a good thing. But it is not the only 
good thing, and it is not so good that it always outweighs every other 
consideration.



-- 
Steven

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

#2597

On Apr 2, 5:13 am, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:

> "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!

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

#2600

On Tue, Apr 5, 2011 at 7:10 AM, rantingrick <rantingrick@gmail.com> wrote:
> 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

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

#2608

On Apr 4, 4:41 pm, Chris Angelico <ros...@gmail.com> wrote:
> 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?

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

#2610

On Tue, Apr 5, 2011 at 8:16 AM, rantingrick <rantingrick@gmail.com> wrote:
>> 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?

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

ChrisA

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

#2617

On Tue, 05 Apr 2011 07:41:37 +1000, Chris Angelico wrote:

> On Tue, Apr 5, 2011 at 7:10 AM, rantingrick <rantingrick@gmail.com>
> wrote:
>> 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?

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


-- 
Steven

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

#2606

rantingrick wrote:
> 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..."

:)

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

#2614

On Mon, 04 Apr 2011 17:09:07 -0500, harrismh777 wrote:

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



-- 
Steven

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

#2619

Steven D'Aprano wrote:
> 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

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

#2627

On 4/4/2011 9:16 PM, harrismh777 wrote:

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

-- 
Terry Jan Reedy

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

#2375

On 4/1/2011 2:13 AM, harrismh777 wrote:

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

Python is object based but not object oriented in the Booch sense.

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

Right, and Python is not OOA&D based.

> Never change an advertised Class interface.

In Python, class interfaces are no more sacred than module or function 
interfaces. If one takes 'no interface change' literally, then Python 
would have to be frozen. Even bug fixes change a defacto interface. If 
you want frozon, stick with one particular release. There are lots 
available.

-- 
Terry Jan Reedy

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

#2385

Terry Reedy <tjreedy@udel.edu> writes:
>> Never change an advertised Class interface.
>
> In Python, class interfaces are no more sacred than module or function
> interfaces. If one takes 'no interface change' literally, then Python
> would have to be frozen. Even bug fixes change a defacto interface.

Oh come on, a interface is advertised if it's documented in the manual,
which cmp is.  There are some undocumented (what you call defacto)
interfaces that you sometimes have to be pragmatically a bit careful
about messing with because people rely on them, but it's almost always
more legitimate to break an undocumented interface than a documented
one.

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

#2434

Terry Reedy wrote:
>> 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).

>
> Python is object based but not object oriented in the Booch sense.
>
> . . . and Python is not OOA&D based.

     With due respects Terry, these statements you have made are 
categorically not true. Even a casual perusal of the Python supplied 
documentation and helps (documented class interfaces) make it very clear 
that OOP and OOA&D are at the very heart of the design of Python.
     To help clear this up a bit, and keeping in line with the cmp 
notion of this thread, I have posted (at the very end of this entry) a 
portion of the class definition for list(object) from several releases, 
each of which resides on at least one of my production servers:
     2.3
     2.4.1
     2.5.2
     2.6.2
     2.7.1
     3.2
I have snipped out the center section of the class definition but have 
left the heading and the sort() method for comparison. I am going to try 
to be making several points with these examples as follows:
     1)  cmp is integral to advertised class interface since (2005).
     2)  OOP and OOA&D are integral to Python definition, period.
     3)  semantics aside, removing cmp breaks the spirit of OOA&D
First, all of the primary books tout (even sport) Python as object 
oriented (not just object based). This is important to note; just a 
couple of examples:

     "[Python] is commonly defined as an object-oriented scripting 
language--a definition that blends support for OOP with an overall 
orientation toward scripting roles" (Lutz, Learning Python, 4th ed, 2009).

     "We use the term base class to refer to a class that is inherited; 
a base class may be the immediate ancestor, or may be further up the 
inheritance tree" (Summerfield, Programming in Python 3: A complete 
Introduction to the Python Language, 2nd ed, 2010).

     It cannot be denied that we are talking exclusively about OOP. End 
of story. Granted, Python certainly does not implement the Booch OOA&D 
like SmallTalk does, nor Eiffel, nor C++. Regardless, it is very clear 
that the OOA&D concepts from Booch are present consciously or 
unconsciously in most of what Python is doing.

     To really get a good feel for this all one has to do is use the 
help() method from the Python interpreter command prompt and then enter 
  list  at the help prompt.  I have attached at the end of this item the 
   class list(object)  definitions for several Python versions showing 
the defined  Methods  :--- specifically the sort().

     First it will be clearly seen that we are looking at an OOP OOA&D 
class definition with internal and external attributes and methods, 
defined as a class with function methods, including sort(). To say that 
Python is not based in OOA&D is to make an asinine statement. Very 
obviously OOA&D was at the lovely heart of the Python design. Obviously 
Booch didn't get credit for it..., but his methodology is very clearly 
present.
     Second it can be clearly seen that beginning in 2.3 there was 
needed a comparison function. In the Programming Python book 3rd ed the 
comparison worked with the class definition like this:

     L.sort( lambda x, y,: cmp(x['n'], y['n']) )

          (Lutz, Programming Python, 3rd ed, 2006)

In 2.4 cmpfunc= was replaced with (cmp= key= reverse=) which remains 
with the definition through 2.7.1 today. It is clear that the cmp= 
keyword is not in any way "cruft," nor is it in any way obscure. It was 
needed, wanted, useful, desired, and most importantly implemented and 
advertised. End of the sad sad story.

     The Python clients (yes, I'm one of those) must be able to make 
assumptions about the class definitions of an advertised object-oriented 
language. Otherwise, the excellent OOA&D work that obviously went into 
the   class list(object).sort()   is pointless.  If the clients using 
sort() cannot rely on the advertised class interface for their projects 
into the future then their use of the language is weakened, and maybe in 
the end not as useful.

      Python is obviously OOP with the concepts of OOA&D at the heart of 
the project's design. Denying this truth in order to justify breaking 
the spirit of OOA&D is not only not helpful, it adds insult to injury.

     But this is worse, because programmers are not the only ones who 
rely on the advertised interface. When the interface is in flux the only 
people who benefit short term are the language designers. The clients 
who might otherwise benefit long term may never see that day because 
they are forced to remain on a previous release far into the future. 
(@Steven ---this is not FUD... No Fear, Absolutely Certain, No Doubt) 
But the other folks who lose on this type of nobbled thinking are the 
ones who write the books, and the tutorials, and the ones who teach the 
students... and of course students.

     Take a look at these obviously OOP OOA&D designs showing the 
evolution and stability of L.sort(cmp= key= reverse=)... and try to see 
this "removal" from the eyes of the clients who are forced to clean up 
your mess:

------------------------       python2.3

class list in module __builtin__:

class list(object)
  |  list() -> new list
  |  list(sequence) -> new list initialized from sequence's items
  |
  |  Methods defined here:
  |
  |  sort(...)
  |      L.sort(cmpfunc=None) -- stable sort *IN PLACE*; cmpfunc(x, y) 
-> -1, 0, 1
  |

------------------------       python2.4.1

class list in module __builtin__:

class list(object)
  |  list() -> new list
  |  list(sequence) -> new list initialized from sequence's items
  |
  |  Methods defined here:
  |
  |
  |  sort(...)
  |      L.sort(cmp=None, key=None, reverse=False) -- stable sort *IN 
PLACE*;
  |      cmp(x, y) -> -1, 0, 1
  |

------------------------       python2.5.2

class list in module __builtin__:

class list(object)
  |  list() -> new list
  |  list(sequence) -> new list initialized from sequence's items
  |
  |  Methods defined here:
  |
  |
  |  sort(...)
  |      L.sort(cmp=None, key=None, reverse=False) -- stable sort *IN 
PLACE*;
  |      cmp(x, y) -> -1, 0, 1
  |

------------------------       python2.6.2

class list in module __builtin__:

class list(object)
  |  list() -> new list
  |  list(sequence) -> new list initialized from sequence's items
  |
  |  Methods defined here:
  |
  |  sort(...)
  |      L.sort(cmp=None, key=None, reverse=False) -- stable sort *IN 
PLACE*;
  |      cmp(x, y) -> -1, 0, 1
  |

------------------------       python2.7.1

class list in module __builtin__:

class list(object)
  |  list() -> new empty list
  |  list(iterable) -> new list initialized from iterable's items
  |
  |  Methods defined here:
  |
  |  sort(...)
  |      L.sort(cmp=None, key=None, reverse=False) -- stable sort *IN 
PLACE*;
  |      cmp(x, y) -> -1, 0, 1
  |

------------------------       python3.2

class list in module builtins:

class list(object)
  |  list() -> new empty list
  |  list(iterable) -> new list initialized from iterable's items
  |
  |  Methods defined here:
  |
  |  sort(...)
  |      L.sort(key=None, reverse=False) -- stable sort *IN PLACE*
  |

------------------------       python3.x.?

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

#2435

On Sat, Apr 2, 2011 at 3:54 PM, harrismh777 <harrismh777@charter.net> wrote:
> Terry Reedy wrote:
>>>
>>> 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).
>
>>
>> Python is object based but not object oriented in the Booch sense.
>>
>> . . . and Python is not OOA&D based.
>
>    With due respects Terry, these statements you have made are categorically
> not true. Even a casual perusal of the Python supplied documentation and
> helps (documented class interfaces) make it very clear that OOP and OOA&D
> are at the very heart of the design of Python.

Why this lengthy discussion on whether Python is object-oriented or
not? What difference does it make? The "implementation vs interface"
difference has nothing to do with that. If I write a library, and I
export a number of public functions, then updating the library in a
way that breaks programs is a bad thing.

But bad things sometimes have to happen. And that's why things are
versioned. Object oriented
programming/design/analysis/architecture/whatever has no effect on
that; if you link against a library, or call on an object, you need to
be able to depend on it. The interface of "sort([1,2,3,4])" is no
different from "[1,2,3,4].sort()" just because one is objects and the
other is functions.

Maybe we need a new directive:

from __past__ import cmpsort

Chris Angelico

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

#2437

Chris Angelico wrote:
> Why this lengthy discussion on whether Python is object-oriented or
> not? What difference does it make?

      Great question... glad you asked...!

> But bad things sometimes have to happen. And that's why things are
> versioned.

      You didn't read the post... cmp removal is a bad thing, and it 
does not need to,  and should not have to  happen.

Object oriented
> programming/design/analysis/architecture/whatever has no effect on
> that;

     Wrong... one of the reasons for OOP in the first place ( OOA&D ) is 
to ensure that BAD THINGS DO NOT HAPPEN.  Code reuse and stability are 
key... and OOA&D helps to make sure that works.

if you link against a library, or call on an object, you need to
> be able to depend on it. The interface of "sort([1,2,3,4])" is no
> different from "[1,2,3,4].sort()" just because one is objects and the
> other is functions.

     You need to read Grady Booch... and study a little OOP design 
either using SmallTalk, or C++, to get an appreciation maybe for what is 
at stake here. Yes, Python OOP is optional for the client perspective. 
But if chosen, OOP must WORK as expected by the OOP community if the 
language is touted as being able to support OOP, which also implies 
support for the spirit of OOA&D.

      You may not have enough knowledge to understand what I'm talking 
about.  Forgive me.


kind regards,
m harris

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

#2439

On Sat, Apr 2, 2011 at 4:17 PM, harrismh777 <harrismh777@charter.net> wrote:
> Chris Angelico wrote:
>>
>> Why this lengthy discussion on whether Python is object-oriented or
>> not? What difference does it make?
>
>     Great question... glad you asked...!
>
>> But bad things sometimes have to happen. And that's why things are
>> versioned.
>
>     You didn't read the post... cmp removal is a bad thing, and it does not
> need to,  and should not have to  happen.

I agree that removal of a feature like that is a bad thing. But the
whole point of this thread is the question of whether or not it should
have happened (or rather, whether or not it should be undone).

>    Wrong... one of the reasons for OOP in the first place ( OOA&D ) is to
> ensure that BAD THINGS DO NOT HAPPEN.  Code reuse and stability are key...
> and OOA&D helps to make sure that works.

So it's perfectly acceptable for bad things to happen in a
non-object-oriented library, but as soon as it works with objects, it
has to eschew badness? This does not make sense.

>    You need to read Grady Booch... and study a little OOP design either
> using SmallTalk, or C++, to get an appreciation maybe for what is at stake
> here.

I've been a C++ programmer for nearly twenty years. I think I know a
few things about OOP. Actually, I've done OOP in non-OO languages;
most notably, plain old C. The OS/2 Presentation Manager class
hierarchy (SOM) is primarily implemented in C, for instance. My point
is that "object orientation" is completely separate from
"implementation is separate from interface".

>     You may not have enough knowledge to understand what I'm talking about.
>  Forgive me.

Maybe I don't. Let me check my character sheet...

Skill, Ranks, Ability, Total modifier
Knowledge (Arcana): 19 + 4 = 23
Knowledge (History): 11 + 4 = 15
Knowledge (Nature): 2 + 4 = 6
Knowledge (The Planes): 0

Not sure where Knowledge (OOP) comes in there. Must ask my DM some day.

Seriously though: I've programmed various systems, where the division
of "interface" and "implementation" come in quite different places; my
favorite being networking, where the interface is the comms protocol,
and everything else is implementation. Objects don't come into it.

But this is getting seriously off-topic; none of this connects with
the cmp= parameter.

Chris Angelico

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

#2444

Chris Angelico wrote:
> I've been a C++ programmer for nearly twenty years. I think I know a
> few things about OOP. Actually, I've done OOP in non-OO languages;
> most notably, plain old C. The OS/2 Presentation Manager class
> hierarchy (SOM) is primarily implemented in C, for instance. My point
> is that "object orientation" is completely separate from
> "implementation is separate from interface".

    Thank you for helping me there with your stats...

>
> Not sure where Knowledge (OOP) comes in there. Must ask my DM some day.
>

    Ok, its an honest question.  The answer is the heart of this debate, 
actually. Please be patient and try to hear this...  the bickering on 
this thread about whether the cmp= removal is a bad thing has been 
focused on the *wrong issue*.  The issue is not whether there is a 
use-case. The issue is not whether there is a technical reason for 
justifying the existence of  L.sort(cmp= ).   The issues debated ad 
nauseum here by most folks are missing the real point (the main issue).

    The real issue facing the community in this cmp= debate is whether 
an established, documented, useful, widely *used* advertised class 
interface should be removed (don't miss this) for strictly philosophical 
reasons based on the expectations of the OOP client community in terms 
of trust and accountability (OOA&D) for the established promises of the 
advertised class interfaces of an *advertised* OOP scripting language--- 
er, Python.

    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?  (and) is 
there OOA&D expectation for this principle?

    The rest of the thread is arguing for a *technical* determination 
for inclusion of the cmp= keyword...  I am arguing (on the other hand) 
for a *philosophical* determination for inclusion of the cmp= keyword.


> But this is getting seriously off-topic; none of this connects with
> the cmp= parameter.

Well, we have to agree to disagree on that point... my view is that this 
is right-on-topic. Guido should restore the interface, period. And the 
main point is that this is regardless of technical underpinnings like 
"cruft," performance issues, &etc.

Now, there may be other issues...   CPython to PyPy, for instance, that 
may or may not affect this ... I don't know. That's not my problem. My 
problem is that the  class list(object).sort(cmp= key= reverse=) 
interface will be broken in 3.3+ unless somebody argues well for 
inclusion.  Some folks are arguing for inclusion based on technical 
merit... and that's fine...  I am arguing based on philosophical premise 
and OOA&D OOP expectations from the OOP Python client community.

Please forgive me, if I made you feel insulted,... that was not intended.

Kind regards,
m harris

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

#2450

I suspect that this debate is a sink hole that I won't be able to  
escape from alive but...

On 2 Apr 2011, at 19:29, harrismh777 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?  (and)  
> is there OOA&D expectation for this principle?

No, there should be no expectation that Python 2.x interfaces be  
preserved in Python 3.x unless they have demonstrated utility.  
Furthermore, there should be no expectation that a particular  
interface survive for more than a few major Python versions. PEP-004  
describes how deprecations are expected to proceed at module  
granularity.

>   The rest of the thread is arguing for a *technical* determination  
> for inclusion of the cmp= keyword...  I am arguing (on the other  
> hand) for a *philosophical* determination for inclusion of the cmp=  
> keyword.

Any argument along what you call "philosophical" grounds will not be  
successful. Technical (including aesthetic, convenience, etc.)  
arguments *may* be successful.

Cheers,
Brian

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

#2501

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

:)

kind regards,

m harris

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

#2503

On Sat, Apr 2, 2011 at 10:30 PM, harrismh777 <harrismh777@charter.net> 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...

I like how you inserted the word 'technically' in there to give this
totally unsubstantiated assertion apparent weight.

Geremy Condra

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

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

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

csiph-web