On Mon, 24 Nov 2008 10:42:41 +, Duncan Grisby wrote:
> Again, this is just an example. As I say, in the real application, the
> data has come from a dynamically-typed database. There's no easy way to
> coerce all the items to the same type, because the application doesn't
> know up-front what
On Mon, 24 Nov 2008 17:33:50 +, Tim Rowe wrote:
> 2008/11/24 Aahz <[EMAIL PROTECTED]>:
>
>> (I'll agree that from some perspectives the new behavior of None is a
>> wart but I think that in the end I agree with people who say that
>> preventing None from being sorted except intentionally will
In article <[EMAIL PROTECTED]>,
Duncan Grisby <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, Aahz <[EMAIL PROTECTED]> wrote:
>>In article <[EMAIL PROTECTED]>,
>>Duncan Grisby <[EMAIL PROTECTED]> wrote:
>>>
>>>For my application, Python 3's comparison behaviour is a backwards
>>>step.
> Sorry for the delay in replying.
Thanks, and I'm in turn sorry myself, too. Here is my experiment:
I only looked at the first test case, where a bigfile.txt has
occasionally None lines. To run this test, I created a file with
33079296 and 704512 lines, by repeatedly cat'ing /etc/passwd.
I the
In article <[EMAIL PROTECTED]>, Aahz <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Duncan Grisby <[EMAIL PROTECTED]> wrote:
[...]
>>That's exactly my point. Currently, the application just builds a list
>>of values retrieved from the database and asks Python to sort it. No
>>key o
2008/11/24 Aahz <[EMAIL PROTECTED]>:
> (I'll agree that from some perspectives the new behavior of None is a
> wart but I think that in the end I agree with people who say that
> preventing None from being sorted except intentionally will trap more
> bugs earlier.)
So will Python be introducing s
In article <[EMAIL PROTECTED]>,
Duncan Grisby <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Terry Reedy <[EMAIL PROTECTED]> wrote:
>>
>>Replace the sublists with a coded string, such as '\0'+line.
>
>Again, this is just an example. As I say, in the real application, the
>data has c
In article <[EMAIL PROTECTED]>,
Terry Reedy <[EMAIL PROTECTED]> wrote:
[...]
>> l = []
>> for line in open("bigfile.txt"):
>> x = random.randint(0,100)
>> if x < 4: l.append(None)
>> else: l.append(line)
>
>So use '' or '\0' instead of None for null lines. Or replace None for
>the s
Duncan Grisby wrote:
Sorry for the delay in replying. Yes, that's not far off. Most of the
time the lists contain strings, though. A better approximation might
be to read lines from a file and randomly replace them with Nones:
l = []
for line in open("bigfile.txt"):
x = random.randint(0,10
In article <[EMAIL PROTECTED]>,
Martin v. Löwis <[EMAIL PROTECTED]> wrote:
>> The sorting is in a performance-critical part of the system, so the
>> overhead of evaluating a key function is not insignificant.
>
>Can you easily produce an example? It doesn't have to be real data,
>but should have t
Terry Reedy wrote:
M.-A. Lemburg wrote:
I think the special case for None should be readded to Python 3.0.
Quick summary of thread that MAL started on Python-3000-dev list:
Once upon a time, 0 < None was true.
When rich comparisons were added, None < 0 (and *most* other things)
become tru
> The sorting is in a performance-critical part of the system, so the
> overhead of evaluating a key function is not insignificant.
Can you easily produce an example? It doesn't have to be real data,
but should have the structure (typewise) of the real data. I would
like to perform some measuremen
M.-A. Lemburg wrote:
I think the special case for None should be readded to Python 3.0.
Quick summary of thread that MAL started on Python-3000-dev list:
Once upon a time, 0 < None was true.
When rich comparisons were added, None < 0 (and *most* other things)
become true as an intentionall
Duncan Grisby wrote:
Yes, very hard.
There is a difference between 'very hard' (to get 'right') and 'to slow'
(for a particular application). I accept the latter.
There are only ever simple types in the lists --
strings, integers, Nones, very occasionally floats, and lists of those
things
M.-A. Lemburg wrote:
On 2008-11-11 02:10, Steven D'Aprano wrote:
On Mon, 10 Nov 2008 12:51:51 +, Duncan Grisby wrote:
I have an object database written in Python. It, like Python, is
dynamically typed. It heavily relies on being able to sort lists where
some of the members are None. To som
On Nov 11, 8:02 am, "M.-A. Lemburg" <[EMAIL PROTECTED]> wrote:
> On 2008-11-11 02:10, Steven D'Aprano wrote:
>
> > On Mon, 10 Nov 2008 12:51:51 +, Duncan Grisby wrote:
>
> >> I have an object database written in Python. It, like Python, is
> >> dynamically typed. It heavily relies on being able
On 2008-11-11 02:10, Steven D'Aprano wrote:
> On Mon, 10 Nov 2008 12:51:51 +, Duncan Grisby wrote:
>
>> I have an object database written in Python. It, like Python, is
>> dynamically typed. It heavily relies on being able to sort lists where
>> some of the members are None. To some extent, it
In article <[EMAIL PROTECTED]>,
Terry Reedy <[EMAIL PROTECTED]> wrote:
>> I have an object database written in Python. It, like Python, is
>> dynamically typed. It heavily relies on being able to sort lists where
>> some of the members are None. To some extent, it also sorts lists of
>> other mix
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>On Sat, 08 Nov 2008 22:53:14 -0800, Kay Schluehr wrote:
>
>>> How often do you care about equality ignoring order for lists
>>> containing arbitrary, heterogeneous types?
>>
>> A few times. Why do you care, Steven?
>
>I'm a very caring kind of guy.
Tha
On Nov 10, 9:31 pm, Rhamphoryncus <[EMAIL PROTECTED]> wrote:
> On Nov 10, 6:25 pm, Steven D'Aprano
>
>
>
> <[EMAIL PROTECTED]> wrote:
> > On Mon, 10 Nov 2008 11:43:59 -0800, Rhamphoryncus wrote:
> > > You might as well comment out the sort and call it good. That's what
> > > you really had in 2.x.
On Nov 10, 6:25 pm, Steven D'Aprano
<[EMAIL PROTECTED]> wrote:
> On Mon, 10 Nov 2008 11:43:59 -0800, Rhamphoryncus wrote:
> > You might as well comment out the sort and call it good. That's what
> > you really had in 2.x. It was close enough most of the time to *look*
> > right, yet in truth it s
On Mon, 10 Nov 2008 11:43:59 -0800, Rhamphoryncus wrote:
> You might as well comment out the sort and call it good. That's what
> you really had in 2.x. It was close enough most of the time to *look*
> right, yet in truth it silently failed. 3.0 makes it an explicit
> failure.
I don't doubt th
On Mon, 10 Nov 2008 12:51:51 +, Duncan Grisby wrote:
> I have an object database written in Python. It, like Python, is
> dynamically typed. It heavily relies on being able to sort lists where
> some of the members are None. To some extent, it also sorts lists of
> other mixed types. It will b
[EMAIL PROTECTED] wrote:
> On Nov 10, 1:21 pm, Steve Holden <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] wrote:
>>> On Nov 10, 8:57 am, Steve Holden <[EMAIL PROTECTED]> wrote:
Robin Becker wrote:
>>> ...snip...
> In old style python there was a sort of standard behaviour whereby None
>>
On Nov 10, 12:39 pm, George Sakkis <[EMAIL PROTECTED]> wrote:
George Sakkis wrote:
> On Nov 10, 2:21 pm, [EMAIL PROTECTED] wrote:
>
>> So you could say that 3.0 is forcing us to acknowledge database
>>
>> > reality ;-)
>>
>> (Again) huh?
>> Reality in databases is that NULL *is* comparable.
>> "NUL
On Nov 10, 1:21 pm, Steve Holden <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > On Nov 10, 8:57 am, Steve Holden <[EMAIL PROTECTED]> wrote:
> >> Robin Becker wrote:
> > ...snip...
> >>> In old style python there was a sort of standard behaviour whereby None
> >>> was comparable with most
On Nov 8, 10:20 am, walterbyrd <[EMAIL PROTECTED]> wrote:
> I have read that in Python 3.0, the following will raise an exception:
>
> >>> [2, 1, 'A'].sort()
>
> Will that raise an exception? And, if so, why are they doing this? How
> is this helpful? Is this new "enhancement" Pythonic?
I realize
[EMAIL PROTECTED] wrote:
> On Nov 10, 8:57 am, Steve Holden <[EMAIL PROTECTED]> wrote:
>> Robin Becker wrote:
> ...snip...
>>> In old style python there was a sort of standard behaviour whereby None
>>> was comparable with most of the other primitive types. That at least
>>> allowed us to performs
On Nov 10, 8:16 am, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Duncan Grisby wrote:
> > In article <[EMAIL PROTECTED]>,
> > Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> >> Have you written any Python code where you really wanted the old,
> >> unpredictable behavior?
>
> > I have an object database wr
On Nov 10, 2:21 pm, [EMAIL PROTECTED] wrote:
> So you could say that 3.0 is forcing us to acknowledge database
>
> > reality ;-)
>
> (Again) huh?
> Reality in databases is that NULL *is* comparable.
> "NULL==something" returns False, it doesn't raise an error.
Given that in SQL "NULL `op` somethi
Robin Becker <[EMAIL PROTECTED]> writes:
> Steve Holden wrote:
> .intain).
>>
>> Of course, using SQL against a traditional RDBMS will not return rows
>> with NULL values for salary in a query such as
>>
>> SELECT name, address WHERE salary < 1
>>
>> precisely *because* NULL (absence
On Nov 10, 8:57 am, Steve Holden <[EMAIL PROTECTED]> wrote:
> Robin Becker wrote:
...snip...
>> In old style python there was a sort of standard behaviour whereby None
>> was comparable with most of the other primitive types. That at least
>> allowed us to performs various stupid tricks with data.
On Mon, 10 Nov 2008 16:32:47 +, Robin Becker wrote:
> on the other hand I find it odd that
>
> cmp(None,None) fails in Python 3 when None==None returns True.
That's because there is no order defined for `NoneType` but equality is.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python
Robin Becker wrote:
Steve Holden wrote:
.intain).
Of course, using SQL against a traditional RDBMS will not return rows
with NULL values for salary in a query such as
SELECT name, address WHERE salary < 1
precisely *because* NULL (absence of value) does not compare with any
valu
Steve Holden wrote:
.intain).
Of course, using SQL against a traditional RDBMS will not return rows
with NULL values for salary in a query such as
SELECT name, address WHERE salary < 1
precisely *because* NULL (absence of value) does not compare with any
value. So you could say t
On Nov 10, 4:10 am, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Roy Smith wrote:
> > Your
> > choice of containers is not based on any theoretical arguments of what each
> > type was intended to represent, but the cold hard reality of what
> > operations they support.
>
> Right. What seems missi
Robin Becker wrote:
> Martin v. Löwis wrote:
>>> Sure:
>>>
>>> if len(L1) == len(L2):
>>> return sorted(L1) == sorted(L2) # check whether two lists contain
>>> the same elements
>>> else:
>>> return False
>>>
>>> It doesn't really matter here what the result of the sorts actually is
>>> as
Martin v. Löwis wrote:
Sure:
if len(L1) == len(L2):
return sorted(L1) == sorted(L2) # check whether two lists contain
the same elements
else:
return False
It doesn't really matter here what the result of the sorts actually is
as long as the algorithm leads to the same result for all pe
Duncan Grisby wrote:
In article <[EMAIL PROTECTED]>,
Terry Reedy <[EMAIL PROTECTED]> wrote:
Have you written any Python code where you really wanted the old,
unpredictable behavior?
I have an object database written in Python. It, like Python, is
dynamically typed. It heavily relies on bein
In article <[EMAIL PROTECTED]>,
Roy Smith <[EMAIL PROTECTED]> wrote:
>
>The point is that you're forced to use lists to compute the sub-sequences.
>This makes sense, because lists fit the "indefinite length sequence" idea.
>Then, you're forced to use tuples as the dictionary keys, because tupl
In article <[EMAIL PROTECTED]>,
Terry Reedy <[EMAIL PROTECTED]> wrote:
>Have you written any Python code where you really wanted the old,
>unpredictable behavior?
I have an object database written in Python. It, like Python, is
dynamically typed. It heavily relies on being able to sort lists w
On Sun, 09 Nov 2008 10:45:31 -0500, Roy Smith wrote:
> As another example, consider a list of items being juggled:
>
> [RubberChicken(), ChainSaw(), Canteloupe()]
>
> I could go through contortions to find some common subclass for these
> items, but the whole *point* is that they're not of the s
Roy Smith wrote:
> Your
> choice of containers is not based on any theoretical arguments of what each
> type was intended to represent, but the cold hard reality of what
> operations they support.
Right. What seems missing is a "frozen list" type - the list needs to be
frozen in order to be use
In article <[EMAIL PROTECTED]>,
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> The "homogeneous vs. heterogeneous" discussion is not that much about
> type, but more about semantics of the individual values. If you
> represent (firstname, lastname, age), you use tuples - three different
> (and or
> Hmmm, I seem to have engaged in a bit of topic drift, for which I
> apologize. I was commenting specifically on the issue of lists holding
> heterogeneous types, not on heterogeneous types being sortable.
Still, I don't think this is a valid counter-example: I claim that the
data in the list
In article <[EMAIL PROTECTED]>,
Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
> One added value in Python 3.0 would be that they are sortable in a
> `list`. But seriously, your token example should work fine with
> Python 3.0 because the wish to sort tokens is a bit exotic IMHO.
Hmmm,
On 9 Nov., 17:49, Terry Reedy <[EMAIL PROTECTED]> wrote:
> I was asking the OP ;-)
Thank you for the discussion.
--
http://mail.python.org/mailman/listinfo/python-list
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
>> Even in 2.x it doesn't work (I think I posted this earlier but I'm not
>> sure anymore) as this example shows:
>>
>> 2 < 3j and 3j < True, but True < 2
>
> What specific value of x have you been trying? For x=4,5,6, I get
>
> py> 2 < 3j and 3j
> Even in 2.x it doesn't work (I think I posted this earlier but I'm not
> sure anymore) as this example shows:
>
> 2 < 3j and 3j < True, but True < 2
What specific value of x have you been trying? For x=4,5,6, I get
py> 2 < 3j and 3j < True
Traceback (most recent call last):
File "", line
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
>> def comp(x1, x2):
>>try:
>>if x1>return -1
>>else:
>>return 1
>>except TypeError:
>>if str(x1)>return -1
>>else:
>>return 1
>>
>
> Please correct me if I'm wron
Hallvard B Furuseth wrote:
> Terry Reedy writes:
>> If you want to duplicate 2.x behavior, which does *not* work for all
>> types...
>>
>> def py2key(item): return (str(type(item)), item)
>
> Nope.
> sorted((-1, 2, True, False)) == [-1, False, True, 2]
> sorted((-1, 2, True, False)
> In any case, would it be possible to add a cmp= function which did more
> or less what the current default cmp does now?
As somebody pointed out, it's possible to create a key= function that
provides arbitrary ordering: just return an object custom type whose
__lt__ never fails:
class AlwaysOrd
> def comp(x1, x2):
>try:
>if x1return -1
>else:
>return 1
>except TypeError:
>if str(x1)return -1
>else:
>return 1
>
Please correct me if I'm wrong, but I think this is not transitive. If
strings and ints are
> Sure:
>
> if len(L1) == len(L2):
> return sorted(L1) == sorted(L2) # check whether two lists contain
> the same elements
> else:
> return False
>
> It doesn't really matter here what the result of the sorts actually is
> as long as the algorithm leads to the same result for all permuta
>> Yes, key= lets you sort anything anyway you want.
>> >>> l=[1, '2', 3j]
>> >>> sorted(l, key = str)
>> [1, '2', 3j]
>
> The problem here is that str() is degenerate, i.e. a != b does not imply
> str(a) != str(b).
So why is this a problem? The sort algorithm is stable, so it gives a
determin
In article <[EMAIL PROTECTED]>,
Roy Smith <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
>>attribution missing:
>>>
>>> Also, I thought that part of the python philosophy was to allow any
>>> sort of object in a list, and to allow the s
Roy Smith <[EMAIL PROTECTED]> writes:
> I spend too much time in C++ pleading with the compiler to allow me to do
> what I want. I come to Python to get away from all that type bondage.
>
> As another example, consider a list of items being juggled:
>
> [RubberChicken(), ChainSaw(), Canteloupe()
Terry Reedy writes:
> If you want to duplicate 2.x behavior, which does *not* work for all
> types...
>
> def py2key(item): return (str(type(item)), item)
Nope.
sorted((-1, 2, True, False)) == [-1, False, True, 2]
sorted((-1, 2, True, False), key=py2key) == [False, True, -1, 2]
Mig
Steven D'Aprano writes:
> How often do you care about equality ignoring order for lists containing
> arbitrary, heterogeneous types?
Arbitrary, I never have. Different types of my choice, a few times.
I was only interested in there being some _sort_ order (and the same in
different runs of the p
Kay Schluehr wrote:
On 9 Nov., 05:04, Terry Reedy <[EMAIL PROTECTED]> wrote:
Have you written any Python code where you really wanted the old,
unpredictable behavior?
Sure:
I was asking the OP ;-)
if len(L1) == len(L2):
return sorted(L1) == sorted(L2) # check whether two lists conta
On Sun, 09 Nov 2008 10:45:31 -0500, Roy Smith wrote:
> In article <[EMAIL PROTECTED]>,
> "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
>> Roy Smith schrieb:
>>> In article <[EMAIL PROTECTED]>,
>>> "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
>>>
>> When I wrote "uniform" I meant objects of the
On Sun, 09 Nov 2008 10:45:31 -0500, Roy Smith wrote:
> In article <[EMAIL PROTECTED]>,
> "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
>> Roy Smith schrieb:
>>> In article <[EMAIL PROTECTED]>,
>>> "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
>>>
>> When I wrote "uniform" I meant objects of the
On Sun, 09 Nov 2008 10:45:31 -0500, Roy Smith wrote:
> In article <[EMAIL PROTECTED]>,
> "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
>> Roy Smith schrieb:
>>> In article <[EMAIL PROTECTED]>,
>>> "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
>>>
>> When I wrote "uniform" I meant objects of the
On Sun, 09 Nov 2008 10:45:31 -0500, Roy Smith wrote:
> In article <[EMAIL PROTECTED]>,
> "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
>> Roy Smith schrieb:
>>> In article <[EMAIL PROTECTED]>,
>>> "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
>>>
>> When I wrote "uniform" I meant objects of the
In article <[EMAIL PROTECTED]>,
Duncan Booth <[EMAIL PROTECTED]> wrote:
> Roy Smith wrote:
>
> > In 3.0, can you still order types? In 2.x, you can do:
> >
> t1 = type(1)
> t2 = type(1j)
> t1 < t2
> > False
> >
> > If this still works in 3.0, then you can easily do something like
In article <[EMAIL PROTECTED]>,
"Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
> Roy Smith schrieb:
> > In article <[EMAIL PROTECTED]>,
> > "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
> >
> >>> Also, I thought that part of the python philosophy was to allow any
> >>> sort of object in a list,
Duncan Booth wrote:
> Roy Smith wrote:
>
>> In 3.0, can you still order types? In 2.x, you can do:
>>
> t1 = type(1)
> t2 = type(1j)
> t1 < t2
>> False
>>
>> If this still works in 3.0, then you can easily do something like:
>>
>> def total_order(o1, o2):
>>"Compare any two object
Roy Smith schrieb:
In article <[EMAIL PROTECTED]>,
"Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
Also, I thought that part of the python philosophy was to allow any
sort of object in a list, and to allow the same methods to work with
whatever was in list.
Not really. When the usual argument ab
Roy Smith wrote:
> In 3.0, can you still order types? In 2.x, you can do:
>
t1 = type(1)
t2 = type(1j)
t1 < t2
> False
>
> If this still works in 3.0, then you can easily do something like:
>
> def total_order(o1, o2):
>"Compare any two objects of arbitrary types"
>try:
>
In article <[EMAIL PROTECTED]>,
"Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
> >
> > Also, I thought that part of the python philosophy was to allow any
> > sort of object in a list, and to allow the same methods to work with
> > whatever was in list.
>
> Not really. When the usual argument ab
Also, I thought that part of the python philosophy was to allow any
sort of object in a list, and to allow the same methods to work with
whatever was in list.
Not really. When the usual argument about the existence (and
justification) of lists & tuples comes along, one common distinction is
t
In article <[EMAIL PROTECTED]>,
Terry Reedy <[EMAIL PROTECTED]> wrote:
> Yes, key= lets you sort anything anyway you want.
> >>> l=[1, '2', 3j]
> >>> sorted(l, key = str)
> [1, '2', 3j]
The problem here is that str() is degenerate, i.e. a != b does not imply
str(a) != str(b).
> >>> sorted(l
Steven D'Aprano wrote:
>> Not sure how to transform it into a search key that is efficient and
>> reliable.
>
> Yes, that's a general problem. It's not always easy to convert a sort
> comparison function into a key-based sort. I know that 99% of the time
> key is the right way to do custom sorts
On 9 Nov., 09:26, Rhamphoryncus <[EMAIL PROTECTED]> wrote:
> On Nov 8, 10:14 pm, Kay Schluehr <[EMAIL PROTECTED]> wrote:
>
> > I guess building a multiset is a little more expensive than just O(n).
> > It is rather like building a dict from a list which is O(k*n) with a
> > constant but small facto
Kay Schluehr wrote:
> On 9 Nov., 07:06, Steven D'Aprano <[EMAIL PROTECTED]
> cybersource.com.au> wrote:
>> How often do you care about equality ignoring order for lists containing
>> arbitrary, heterogeneous types?
>
> A few times. Why do you care, Steven?
"I miss this feature" is an unqualified
On Nov 8, 10:14 pm, Kay Schluehr <[EMAIL PROTECTED]> wrote:
> I guess building a multiset is a little more expensive than just O(n).
> It is rather like building a dict from a list which is O(k*n) with a
> constant but small factor k. The comparison is of the same order. To
> enable the same behavi
Kay Schluehr <[EMAIL PROTECTED]> writes:
> On 9 Nov., 07:06, Steven D'Aprano <[EMAIL PROTECTED]
[...]
>> In any case, the above doesn't work now, since either L1 or L2 might
>> contain complex numbers.
>> The sorted() trick only works because you're
>> making an assumption about the kinds of thing
On Sat, 08 Nov 2008 22:53:14 -0800, Kay Schluehr wrote:
>> How often do you care about equality ignoring order for lists
>> containing arbitrary, heterogeneous types?
>
> A few times. Why do you care, Steven?
I'm a very caring kind of guy.
>> In any case, the above doesn't work now, since eith
On 9 Nov., 07:06, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Sat, 08 Nov 2008 20:36:59 -0800, Kay Schluehr wrote:
> > On 9 Nov., 05:04, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> >> Have you written any Python code where you really wanted the old,
> >> unpredictable behavior
On Sat, 08 Nov 2008 20:36:59 -0800, Kay Schluehr wrote:
> On 9 Nov., 05:04, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
>> Have you written any Python code where you really wanted the old,
>> unpredictable behavior?
>
> Sure:
>
> if len(L1) == len(L2):
> return sorted(L1) == sorted(L2) # chec
On 9 Nov., 05:49, Alex_Gaynor <[EMAIL PROTECTED]> wrote:
> On Nov 8, 11:36 pm, Kay Schluehr <[EMAIL PROTECTED]> wrote:
>
>
>
> > On 9 Nov., 05:04, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> > > Have you written any Python code where you really wanted the old,
> > > unpredictable behavior?
>
> > Sur
On Sat, 08 Nov 2008 19:06:14 -0800, walterbyrd wrote:
> On Nov 8, 7:44 pm, Steven D'Aprano <[EMAIL PROTECTED]
> cybersource.com.au> wrote:
>
>> Define your own ordering if you need to sort incomparable types.
>
> If you starting new, I suppose you can always work around this new
> enhancement. B
On Nov 8, 11:36 pm, Kay Schluehr <[EMAIL PROTECTED]> wrote:
> On 9 Nov., 05:04, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> > Have you written any Python code where you really wanted the old,
> > unpredictable behavior?
>
> Sure:
>
> if len(L1) == len(L2):
> return sorted(L1) == sorted(L2) # ch
On 9 Nov., 05:04, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Have you written any Python code where you really wanted the old,
> unpredictable behavior?
Sure:
if len(L1) == len(L2):
return sorted(L1) == sorted(L2) # check whether two lists contain
the same elements
else:
return False
It
walterbyrd wrote:
Guido and the developers changed the behavior of order comparisons, and
hence of sorts, because they agreed, on the basis of person-decades of
experience, with no dissent that I know of, that the new behavior would
be better.
Have you written any Python code where you reall
Steven D'Aprano wrote:
On Sat, 08 Nov 2008 19:02:28 +, Arnaud Delobelle wrote:
And, if so, why are they doing this?
How is it helpful to be able to sort things which have no natural order?
Assuming you need to sort arbitrary types, then you have to choose an
order, even if it is arbitra
On 08Nov2008 19:17, walterbyrd <[EMAIL PROTECTED]> wrote:
| On Nov 8, 12:02 pm, Arnaud Delobelle <[EMAIL PROTECTED]> wrote:
| > It goes well with duck typing. It lets you know when you things happen
| > that you don't mean to happen.
|
| But doesn't that also make the language less flexible?
No.
On Nov 8, 12:02 pm, Arnaud Delobelle <[EMAIL PROTECTED]> wrote:
> It goes well with duck typing. It lets you know when you things happen
> that you don't mean to happen.
But doesn't that also make the language less flexible?
For example, if I used C, I would never have to worry about assigning
On Nov 8, 7:44 pm, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> Define your own ordering if you need to sort incomparable types.
If you starting new, I suppose you can always work around this new
enhancement. But, couldn't this cause a lot of backward compatibility
issues?
Al
On Sat, 08 Nov 2008 19:02:28 +, Arnaud Delobelle wrote:
>> And, if so, why are they doing this?
>
> How is it helpful to be able to sort things which have no natural order?
Assuming you need to sort arbitrary types, then you have to choose an
order, even if it is arbitrary, so long as it's
walterbyrd <[EMAIL PROTECTED]> writes:
> I have read that in Python 3.0, the following will raise an exception:
>
[2, 1, 'A'].sort()
>
> Will that raise an exception?
Yes. In fact, plenty of objects of different types aren't comparable
anymore.
> And, if so, why are they doing this?
How i
walterbyrd wrote:
> I have read that in Python 3.0, the following will raise an exception:
>
[2, 1, 'A'].sort()
>
> Will that raise an exception?
Yes.
>>> [2, 1, "a"].sort()
Traceback (most recent call last):
File "", line 1, in
TypeError: unorderable types: str() < int()
> And, if s
92 matches
Mail list logo
