Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!feeder.news-service.com!news2.euro.net!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Return-Path: <brian@sweetapp.com>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
X-Spam-Status: OK 0.001
X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'x-mailer:apple mail (2.936)': 0.03; 'escape': 0.04; '2.x': 0.05; 'arguments': 0.05; 'versions.': 0.07; 'python': 0.07; '3.x': 0.09; 'subject:method': 0.09; 'interfaces': 0.12; 'psf': 0.13; 'wrote:': 0.14; '*any*': 0.16; 'from:addr:brian': 0.16; 'keyword.': 0.16; 'language?': 0.16; 'preserved': 0.16; 'sink': 0.16; 'subject:sort': 0.16; 'argument': 0.16; 'describes': 0.19; 'cc:no real name:2**0': 0.20; 'cc:2**0': 0.20; 'cheers,': 0.20; 'interface': 0.20; 'header:In- Reply-To:1': 0.22; 'cc:addr:python-list': 0.22; '(on': 0.23; 'expectation': 0.23; 'suspect': 0.25; 'etc.)': 0.29; 'technical': 0.29; "won't": 0.30; 'cc:addr:python.org': 0.31; 'but...': 0.31; 'oop': 0.31; 'survive': 0.31; 'does': 0.31; '(including': 0.33; 'words,': 0.33; 'module': 0.33; 'skip:" 10': 0.34; 'there': 0.35; 'brian': 0.36; 'charset:us-ascii': 0.36; 'rest': 0.37; 'should': 0.37; 'apr': 0.38; 'thread': 0.38; 'unless': 0.38; 'received:209': 0.39; 'header:Mime-Version:1': 0.39; 'how': 0.39; 'header:Message- Id:1': 0.62; 'alive': 0.68; 'received:121': 0.77; 'grounds': 0.84; 'hole': 0.84; 'inclusion': 0.84; 'subject:removal': 0.84; 'to:addr:charter.net': 0.84; 'successful.': 0.91
X-pair-Authenticated: 121.44.78.172
From: Brian Quinlan <brian@sweetapp.com>
To: harrismh777 <harrismh777@charter.net>
In-Reply-To: <P7Blp.8987$sP1.1530@newsfe07.iad>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: Guido rethinking removal of cmp from sort method
Date: Sat, 2 Apr 2011 22:14:59 +1100
References: <4d7cbfcb$0$29971$c3e8da3$5496439d@news.astraweb.com>	<mailman.1175.1300888311.1189.python-list@python.org>	<JfVkp.5068$sS4.4758@newsfe11.iad>	<4d94326c$0$30003$c3e8da3$5496439d@news.astraweb.com>	<R1elp.6224$sP1.5155@newsfe07.iad>	<mailman.85.1301677576.2990.python-list@python.org>	<y_xlp.24978$tL6.16271@newsfe03.iad>	<mailman.119.1301720798.2990.python-list@python.org>	<8kylp.4903$yp3.4046@newsfe09.iad> <mailman.121.1301725067.2990.python-list@python.org> <P7Blp.8987$sP1.1530@newsfe07.iad>
X-Mailer: Apple Mail (2.936)
Cc: python-list@python.org
X-BeenThere: python-list@python.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-list>
List-Post: <mailto:python-list@python.org>
List-Help: <mailto:python-list-request@python.org?subject=help>
List-Subscribe: <http://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups: comp.lang.python
Message-ID: <mailman.125.1301743307.2990.python-list@python.org>
Lines: 29
NNTP-Posting-Host: 82.94.164.166
X-Trace: 1301743307 news.xs4all.nl 81485 [::ffff:82.94.164.166]:46328
X-Complaints-To: abuse@xs4all.nl
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python: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