From: Steven D'Aprano on
On Sun, 27 Jun 2010 00:59:35 +0200, Laurent Verweijen wrote:

> Something I really dislike, is that the "__cmp__"-method is gone. I
> really hate to write 6 different functions, whereas I'm used to writing
> a oneliners which covers each of the 6 cases. I haven't switched to
> pyton 3 yet, but when I do, I will give my classes a single compare
> method and omit the syntactic sugar.

Thanks to Raymond Hettinger, Python 2.7 and 3.2 now contain decorators to
simplify the writing of rich comparisons. See this recipe for details:

If you want more than that, there's Michael Foord's recipe:

From: Nobody on
On Sat, 26 Jun 2010 21:08:48 +0200, Martin v. Loewis wrote:

>> I think that's not true. If enough people want to support Python 2 it
>> might be possible to advance Python 2.
> That won't be sufficient: enough people wanting support won't have any
> effect. People also need to want it enough to actually fork from

This will happen.

> They would then have to convince Linux packagers to include
> it in the distribution even though it's not available from,

So will this.

> and convince Windows users to download it from some other place than

I don't know about this one. Windows uses Unicode natively, so Python3
isn't so problematic there.

> I think people will find that this isn't really worth the
> trouble.

I disagree.

The Unix API uses byte strings, with no associated encoding; always has,
always will. For people who use Python as an alternative to bash or Perl,
maintaining a fork of Python 2 is going to be less trouble than using
Python 3.

From: Steven D'Aprano on
On Sun, 27 Jun 2010 01:06:12 +0000, Steven D'Aprano wrote:

> On Sat, 26 Jun 2010 17:02:32 -0700, Paul Rubin wrote:
> To all the Python 3.x haters

Hmmm, I just realised that it might seem that this was aimed at Paul
directly. I'm sorry, I wasn't intending to imply that he's a Python 3
hater, or that anyone who mentions even the tiniest little disagreement
or difficulty with Python 3 is a hater. That wasn't my intention, and I'm
sorry if I gave it to anyone.

Of course there will be difficulties during the transition period, which
is why Python 2.7 will get a longer-than-normal release cycle. If people
don't publicly say what those difficulties are, they won't be fixed.
Sometimes the fix is just "hang in there, you'll learn the new ways of
doing things", and sometimes they will require new code in Python itself.

From: Aahz on
In article <mailman.2172.1277594845.32709.python-list(a)>,
Terry Reedy <tjreedy(a)> wrote:
>On 6/26/2010 2:55 PM, Peter Kleiweg wrote:
>> Some basic text string functions seem to be working on byte
>> string functions as well, but sometimes they don't, and there's
>> no rhyme in why it does or doesn't.
>> >>> 'abcd'[0] == 'abcd'[:1]
>> True
>> >>> b'abcd'[0] == b'abcd'[:1]
>> False
>> Why????
>The bytes behavior is the normal behavior for sequences. Indexing
>produces an element of the sequence (in this case an int) while slicing
>produce a subseqeunce of the sequence, which is different from an
>element of the sequence. Try the same with tuples, lists, and ranges.
>Strings are anomalous in that indexing produces a subsequence instead of
>an element (char in this case, which Guido chose for Python not to have).

Quoting myself from some time back:

"...string iteration isn't about treating strings as sequences of strings,
it's about treating strings as sequences of characters. The fact that
characters are also strings is the reason we have problems, but characters
are strings for other good reasons." --Aahz
Aahz (aahz(a) <*>

"If you don't know what your program is supposed to do, you'd better not
start writing it." --Dijkstra
From: Lawrence D'Oliveiro on
In message <mailman.2141.1277567901.32709.python-list(a)>, Stefan
Reich wrote:

> My complaint is about changing the syntax of "print".

I never use print, so I don't appreciate the problem. It seems to be useful
only for noddy I/O.