Guido rethinking removal of cmp from sort method

[harrismh777]

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

 

[harrismh777]

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

 

[harrismh777]

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

 

[Chris Angelico]

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


    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

 

[harrismh777]

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

 

[Steven D'Aprano]

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 D'Aprano]

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 D'Aprano]

]

I don't understand what you mean by "this test".

I mean testing whether a feature should be in Python based on whether it
can meet some undefined standard of popularity if implemented as a
third-party module or extension. [...]
Granted, but I think the implication is clear: that only those features
which could be successful if implemented and distributed by a third
party should be in Python.

Ah, gotcha.

I think you're reading too much into what I said -- I wasn't implying
that community support is the only acceptable reason for the existence of
features in Python.

Development of Python is not a democracy, it is a meritocracy. It is
designed by a small team of language developers, starting with Guido van
Rossum. Those who do the work decide what goes in, based on whatever
combination of factors they choose:

* some features are such obvious no-brainers that only a complete idiot
would leave them out ("what do you mean, there's no way to add two
numbers?");
* what other languages do;
* personal preference;
* tools that they personally find useful, or that they expect will be
useful to many;

etc. And *every one of these* is subject to the requirement of a rough
consensus, or a BDFL pronouncement. The rest of us can only hope to
persuade the Python developers: if you want somebody to scratch your itch
instead of their own, you need to convince them to do so.

My point was that good community support is a fairly good method of
persuasion. The broader community does not get a vote, but that does not
mean their voices are unheard.

 

[Brian Quinlan]

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

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

 

[Steven D'Aprano]

No it's not already removed, I just tried it (in Python 2.6, which is
called "Python" for short) and it still works. It's not "removed" from
Python until basically all Python users have migrated and "Python"
essentially always means "Python 3".

You know full well that I'm talking about Python 3, not Python 2 or
Python 1. In Python 2, sort still takes a cmp argument, so what's the
problem?

Until that happens, for Python 2
users, Python 3 is just a fork of Python with some stuff added and some
stuff broken, that might get its act together someday. I see in the
subject of this thread, "Guido rethinking removal of cmp from sort
method" which gives hope that one particular bit of breakage might get
fixed.

You call it a breakage, but many others disagree. The point of this
thread was supposed to be to encourage people like you to come up with
good, reasoned, reasonable arguments for adding cmp, not to engage in FUD
about Python 3 being a "fork" of Python, or that there is never under any
circumstances any good reason for removing features.

I expected a certain amount of bitterness to come through, but if I had
realised just what a bunch of whining I was going to unleash, I would
have kept quiet.


[...]

If "sorting" is in the stdlib like functools is, then the similarity
makes sense and the suggestion isn't so bad. But you're proposing a 3rd
party module, which is not the same thing at all.

In the face of opposition from senior developers who don't want cmp in
the language, and who will presumably oppose adding a "needless" module
to the standard library, you will need good solid evidence that this
functionality is wanted and needed, and not just a bunch of crappy
rationalizations like "I can't be bothered thinking up a key function",
which was actually suggested by someone in this thread. (Not in those
exact words, but that's the gist of it.) A good way to gather such
evidence is to make it a third party module first: if people want the
feature, they will install it, just like they install numpy or pyparsing
or any other wanted module that is not in the standard library.

And if not, in the absolute worst case, at least *you* can continue using
cmp in your own code.

I realise that this strategy will only imperfectly capture community
desire for cmp sorting, but do you have a better strategy?

You don't have to follow my suggestion. If you think you have a better
strategy for convincing the people doing the actual work to scratch
*your* itch instead of their own, then go right ahead and use it.

 

[Terry Reedy]

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

 

[harrismh777]

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

 

[harrismh777]

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

 

[harrismh777]

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

 

[geremy condra]

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

 

[geremy condra]

]

I don't have a horse in this race, but I do wonder how much of Python
could actually survive this test. My first (uneducated) guess is "not
very much"- we would almost certainly lose large pieces of the string
API and other builtins, and I have no doubt at all that a really
significant chunk of the standard library would vanish as well. In
fact, looking at the data I took from PyPI a while back, it's pretty
clear that Python's feature set would look very different overall if
we applied this test to everything.


I don't understand what you mean by "this test".

I mean testing whether a feature should be in Python based on whether it
can meet some undefined standard of popularity if implemented as a
third-party module or extension. [...]
Granted, but I think the implication is clear: that only those features
which could be successful if implemented and distributed by a third
party should be in Python.

Ah, gotcha.

I think you're reading too much into what I said -- I wasn't implying
that community support is the only acceptable reason for the existence of
features in Python.

Development of Python is not a democracy, it is a meritocracy. It is
designed by a small team of language developers, starting with Guido van
Rossum. Those who do the work decide what goes in, based on whatever
combination of factors they choose:

I think we're talking at cross purposes. The point I'm making is that
there are lots of issues where popularity as a third party module
isn't really a viable test for whether a feature is sufficiently
awesome to be in core python. As part of determining whether I thought
it was appropriate in this case I essentially just asked myself
whether any of the really good and necessary parts of Python would
fail to be readmitted under similar circumstances, and I think the
answer is that very few would come back in. To me, that indicates that
this isn't the right way to address this issue, although I admit that
I lack any solid proof to base that conclusion on.

Geremy Condra

 

[Brian Quinlan]

I think we're talking at cross purposes. The point I'm making is that
there are lots of issues where popularity as a third party module
isn't really a viable test for whether a feature is sufficiently
awesome to be in core python. As part of determining whether I thought
it was appropriate in this case I essentially just asked myself
whether any of the really good and necessary parts of Python would
fail to be readmitted under similar circumstances, and I think the
answer is that very few would come back in. To me, that indicates that
this isn't the right way to address this issue, although I admit that
I lack any solid proof to base that conclusion on.

This has been discussed a few times on python-dev. I think that most
developers acknowledge that small-but-high-utility modules would not
survive outside of the core because people would simple recreate them
rather than investing the time to find, learn and use them.

Cheers,
Brian

 

[Brian Quinlan]

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

 

[harrismh777]

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

 

[Steven D'Aprano]

This has been discussed a few times on python-dev. I think that most
developers acknowledge that small-but-high-utility modules would not
survive outside of the core because people would simple recreate them
rather than investing the time to find, learn and use them.

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

On the other hand, for a pure Python function or class, you could stick
it on ActiveState's Python cookbook and get some imperfect measure of
popularity and/or usefulness from the comments and votes there.