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. You can argue all you
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 trap
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 the
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 sort.
Both '' and
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 come from a
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 strong
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 or cmp function.
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
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 the
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 =
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 to sort lists
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
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
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 intentionally
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
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 also
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 true
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 mixed types.
Terry Reedy [EMAIL PROTECTED] writes:
We're not going to add the feature back that None compares smaller
than everything. It's a slippery slope that ends with all operations
involving None returning None -- I've seen a proposal made in all
earnestness requesting that None+42 == None, None()
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 tuples
are
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 being
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
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 where
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 long as the algorithm leads
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 missing is a frozen
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
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
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 same
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
--
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 used as
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.
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 of value) does
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` something is
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 written in Python. It,
[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 various stupid
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 that I am
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 of the other
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.
NULL==something
[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
was comparable with
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 be
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 that
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 silently
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. It was close
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.
That's the best
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 things in the
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 behavior as
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 statement,
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, but
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, key = id)
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
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 factor k. The
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 about the
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:
return o1 = o2
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 about
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 objects of arbitrary types
try:
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, and to allow the same
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:
def total_order(o1, o2):
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 same kind. So for example
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 same kind. So for example
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 same kind. So for example
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 same kind. So for example
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
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
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]
Might
def comp(x1, x2):
try:
if x1x2:
return -1
else:
return 1
except TypeError:
if str(x1)str(x2):
return -1
else:
return 1
Please correct me if I'm wrong, but I think this is not transitive. If
strings and ints
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),
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 stdin, line 1, in
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
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 same methods to work
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
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 of
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()]
I
Martin v. Löwis [EMAIL PROTECTED] writes:
def comp(x1, x2):
try:
if x1x2:
return -1
else:
return 1
except TypeError:
if str(x1)str(x2):
return -1
else:
return 1
Please correct me if I'm wrong, but I think
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 True
Traceback
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, I
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 orthogonal)
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
deterministic result.
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 permutations
on
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?
--
http://mail.python.org/mailman/listinfo/python-list
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 stdin, line 1, in module
TypeError: unorderable types: str() int()
And, if so,
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 is it
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. All
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
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
a
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?
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
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
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) # check whether
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. But,
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?
Sure:
if len(L1) ==
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) # check whether
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?
Sure:
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 either L1
94 matches
Mail list logo
