Re: [Python-Dev] total ordering.

2006-05-18 Thread Jason Orendorff
Vladimir, Your examples seem to indicate that you've misunderstood the change that's proposed for Python 3000. Especially this: On 5/17/06, Vladimir 'Yu' Stepanov <[EMAIL PROTECTED]> wrote: > # BEGIN: Emulation python3000 > if type(a) is not type(b) and ( >

Re: [Python-Dev] total ordering.

2006-05-17 Thread Vladimir 'Yu' Stepanov
Jason Orendorff wrote: On 5/11/06, Vladimir 'Yu' Stepanov <[EMAIL PROTECTED]> wrote: If for Python-3000 similar it will be shown concerning types str(), int(), complex() and so on, and the type of exceptions will strongly vary, it will make problematic redefinition of behavior of function of sor

Re: [Python-Dev] total ordering.

2006-05-16 Thread Jason Orendorff
On 5/11/06, Vladimir 'Yu' Stepanov <[EMAIL PROTECTED]> wrote: > If for Python-3000 similar it will be shown concerning types > str(), int(), complex() and so on, and the type of exceptions > will strongly vary, it will make problematic redefinition of > behavior of function of sorting. I don't see

Re: [Python-Dev] total ordering.

2006-05-16 Thread Vladimir 'Yu' Stepanov
Guido van Rossum wrote: > On 5/11/06, Vladimir 'Yu' Stepanov <[EMAIL PROTECTED]> wrote: >> If for Python-3000 similar it will be shown concerning types >> str(), int(), complex() and so on, and the type of exceptions >> will strongly vary, it will make problematic redefinition of >> behavior of fun

Re: [Python-Dev] total ordering.

2006-05-11 Thread Delaney, Timothy (Tim)
Edward Loper wrote: > It might be useful in some cases to have a keyword argument to > sort/sorted that says to ignore exceptions arising from comparing > elements, and leaves the ordering of non-comparable values undefined. Why? Far better to use a key (or cmp if you really want) that imposes a

Re: [Python-Dev] total ordering.

2006-05-11 Thread Edward Loper
Guido van Rossum wrote: > On 5/11/06, Vladimir 'Yu' Stepanov <[EMAIL PROTECTED]> wrote: >> If for Python-3000 similar it will be shown concerning types >> str(), int(), complex() and so on, and the type of exceptions >> will strongly vary, it will make problematic redefinition of >> behavior of fun

Re: [Python-Dev] total ordering.

2006-05-11 Thread Guido van Rossum
On 5/11/06, Vladimir 'Yu' Stepanov <[EMAIL PROTECTED]> wrote: > If for Python-3000 similar it will be shown concerning types > str(), int(), complex() and so on, and the type of exceptions > will strongly vary, it will make problematic redefinition of > behavior of function of sorting. Not really.

Re: [Python-Dev] total ordering.

2006-05-11 Thread Vladimir 'Yu' Stepanov
Guido van Rossum wrote: > On 5/6/06, Vladimir Yu. Stepanov <[EMAIL PROTECTED]> wrote: > [proposing a total ordering between types] > > It Ain't Gonna Happen. (From now on, I'll write this as IAGH.) > > In Python 3000, we'll actually *remove* ordering between arbitrary > types as a feature; only typ

Re: [Python-Dev] total ordering.

2006-05-07 Thread Guido van Rossum
On 5/6/06, Vladimir Yu. Stepanov <[EMAIL PROTECTED]> wrote: [proposing a total ordering between types] It Ain't Gonna Happen. (From now on, I'll write this as IAGH.) In Python 3000, we'll actually *remove* ordering between arbitrary types as a feature; only types that explicitly care to be ordere

Re: [Python-Dev] total ordering.

2006-05-07 Thread Vladimir Yu. Stepanov
On Sat, May 06, 2006 at 03:12:11AM -0700, Josiah Carlson wrote: > > "Vladimir 'Yu' Stepanov" <[EMAIL PROTECTED]> wrote: > > Josiah Carlson wrote: > > > This problem has nothing to do with dictionaries and hashing, it has to > > > do with the fact that there may not be a total ordering on the eleme