On 15.02.2014 07:03, Stephen J. Turnbull wrote:
M.-A. Lemburg writes:
IMO, it was a mistake to have None return a TypeError in
comparisons, since it makes many typical data operations
fail, e.g.
I don't understand this statement. The theory is that they *should*
fail.
The
On 17 February 2014 11:14, M.-A. Lemburg m...@egenix.com wrote:
On 15.02.2014 07:03, Stephen J. Turnbull wrote:
M.-A. Lemburg writes:
IMO, it was a mistake to have None return a TypeError in
comparisons, since it makes many typical data operations
fail, e.g.
I don't
On 17.02.2014 12:23, Gustavo Carneiro wrote:
On 17 February 2014 11:14, M.-A. Lemburg m...@egenix.com wrote:
On 15.02.2014 07:03, Stephen J. Turnbull wrote:
M.-A. Lemburg writes:
IMO, it was a mistake to have None return a TypeError in
comparisons, since it makes many typical data
17.02.14 13:14, M.-A. Lemburg написав(ла):
Here's a particularly nasty case:
l = [(1, None), (2, None)]
l.sort()
l
[(1, None), (2, None)]
l = [(1, None), (2, None), (3, 4)]
l.sort()
l
[(1, None), (2, None), (3, 4)]
l = [(1, None), (2, None), (3, 4), (2, 3)]
l.sort()
Traceback (most
On 17 February 2014 11:43, M.-A. Lemburg m...@egenix.com wrote:
On 17.02.2014 12:23, Gustavo Carneiro wrote:
On 17 February 2014 11:14, M.-A. Lemburg m...@egenix.com wrote:
On 15.02.2014 07:03, Stephen J. Turnbull wrote:
M.-A. Lemburg writes:
IMO, it was a mistake to have None
On 17 February 2014 11:49, Gustavo Carneiro gjcarne...@gmail.com wrote:
FWIW, I don't think we need to invent a new name for it, just add
an appropriate tp_richcompare slot to the PyNoneType or readd the
special case to Object/object.c. This would also aid in porting
existing Python 2 code
On 17.02.2014 12:47, Serhiy Storchaka wrote:
17.02.14 13:14, M.-A. Lemburg написав(ла):
Here's a particularly nasty case:
l = [(1, None), (2, None)]
l.sort()
l
[(1, None), (2, None)]
l = [(1, None), (2, None), (3, 4)]
l.sort()
l
[(1, None), (2, None), (3, 4)]
l = [(1, None), (2,
On 17.02.2014 12:49, Gustavo Carneiro wrote:
On 17 February 2014 11:43, M.-A. Lemburg m...@egenix.com wrote:
On 17.02.2014 12:23, Gustavo Carneiro wrote:
On 17 February 2014 11:14, M.-A. Lemburg m...@egenix.com wrote:
On 15.02.2014 07:03, Stephen J. Turnbull wrote:
M.-A. Lemburg writes:
On 17 Feb 2014 21:15, M.-A. Lemburg m...@egenix.com wrote:
On 15.02.2014 07:03, Stephen J. Turnbull wrote:
M.-A. Lemburg writes:
IMO, it was a mistake to have None return a TypeError in
comparisons, since it makes many typical data operations
fail, e.g.
I don't understand
17.02.14 13:56, M.-A. Lemburg написав(ла):
Yes, but that's not the point. Unlike strings or other mixed types that
you cannot compare, None is used as placeholder in data processing as
special value to mean no value available.
Isn't float('nan') such placeholder?
You intentionally use such
On 17.02.2014 13:12, Nick Coghlan wrote:
On 17 Feb 2014 21:15, M.-A. Lemburg m...@egenix.com wrote:
On 15.02.2014 07:03, Stephen J. Turnbull wrote:
M.-A. Lemburg writes:
IMO, it was a mistake to have None return a TypeError in
comparisons, since it makes many typical data operations
On 17.02.2014 13:19, Serhiy Storchaka wrote:
17.02.14 13:56, M.-A. Lemburg написав(ла):
Yes, but that's not the point. Unlike strings or other mixed types that
you cannot compare, None is used as placeholder in data processing as
special value to mean no value available.
Isn't float('nan')
On 17 February 2014 12:30, M.-A. Lemburg m...@egenix.com wrote:
On 17.02.2014 13:19, Serhiy Storchaka wrote:
17.02.14 13:56, M.-A. Lemburg написав(ла):
Yes, but that's not the point. Unlike strings or other mixed types that
you cannot compare, None is used as placeholder in data processing
On 17.02.2014 14:29, Gustavo Carneiro wrote:
On 17 February 2014 12:30, M.-A. Lemburg m...@egenix.com wrote:
On 17.02.2014 13:19, Serhiy Storchaka wrote:
17.02.14 13:56, M.-A. Lemburg написав(ла):
Yes, but that's not the point. Unlike strings or other mixed types that
you cannot compare,
On Tue, Feb 18, 2014 at 1:30 AM, M.-A. Lemburg m...@egenix.com wrote:
Also think of the implications of changing None at this point. It would
allow us to write programs that work Python = 3.5 and Python = 2.7, but
fail mysteriously in all other versions in between. What a mess that would
On Mon, Feb 17, 2014 at 12:43:25PM +0100, M.-A. Lemburg wrote:
This doesn't only apply to numeric comparisons. In Python 2 you
can compare None with any kind of object and it always sorts first,
No you can't. See http://bugs.python.org/issue1673405 .
According to Tim Peters, the None is less
On 17.02.2014 15:38, Jon Ribbens wrote:
On Mon, Feb 17, 2014 at 12:43:25PM +0100, M.-A. Lemburg wrote:
This doesn't only apply to numeric comparisons. In Python 2 you
can compare None with any kind of object and it always sorts first,
No you can't. See http://bugs.python.org/issue1673405 .
On 2/17/2014 7:25 AM, M.-A. Lemburg wrote:
On 17.02.2014 13:12, Nick Coghlan wrote:
On 17 Feb 2014 21:15, M.-A. Lemburg m...@egenix.com wrote:
On 15.02.2014 07:03, Stephen J. Turnbull wrote:
M.-A. Lemburg writes:
IMO, it was a mistake to have None return a TypeError in
comparisons,
On 02/16/2014 03:45 PM, Paul Moore wrote:
http://bugs.python.org/issue20621 is significant enough to be
resulting in a 3.3.5 release - can you make sure the 3.4 fix goes in?
I'm not sure how to find the revision number that contains the fix to
follow the process you outline above, so I'm just
Thanks, I see. Greg already filed a tracking issue, so it's covered anyway.
On 17 February 2014 15:33, Larry Hastings la...@hastings.org wrote:
On 02/16/2014 03:45 PM, Paul Moore wrote:
http://bugs.python.org/issue20621 is significant enough to be
resulting in a 3.3.5 release - can you make
On 02/16/2014 04:03 PM, Victor Stinner wrote:
Hi,
The PEP 436 is still a draft and not mentionned in Python 3.4
changelog. The PEP proposes to add a DSL, not to modify all modules
implemented in C. I think that it should be marked as Final and
mentionned in the changelog.
On 2/17/2014 10:22 AM, M.-A. Lemburg wrote:
On 17.02.2014 15:38, Jon Ribbens wrote:
On Mon, Feb 17, 2014 at 12:43:25PM +0100, M.-A. Lemburg wrote:
This doesn't only apply to numeric comparisons. In Python 2 you
can compare None with any kind of object and it always sorts first,
No you can't.
17.02.14 14:11, M.-A. Lemburg написав(ла):
Of course, it's easy to add a new type for this, but a lot of Python 2
code relies on None behaving this way, esp. code that reads data from
databases, since None is the Python mapping for SQL NULL.
At the same time a lot of Python 2 relies on the
17.02.14 20:18, Serhiy Storchaka написав(ла):
17.02.14 14:11, M.-A. Lemburg написав(ла):
Of course, it's easy to add a new type for this, but a lot of Python 2
code relies on None behaving this way, esp. code that reads data from
databases, since None is the Python mapping for SQL NULL.
At
On 2/17/2014 12:59 PM, Terry Reedy wrote:
On 2/17/2014 10:22 AM, M.-A. Lemburg wrote:
On 17.02.2014 15:38, Jon Ribbens wrote:
On Mon, Feb 17, 2014 at 12:43:25PM +0100, M.-A. Lemburg wrote:
This doesn't only apply to numeric comparisons. In Python 2 you
can compare None with any kind of object
On 2/17/2014 1:18 PM, Serhiy Storchaka wrote:
17.02.14 14:11, M.-A. Lemburg написав(ла):
Of course, it's easy to add a new type for this, but a lot of Python 2
code relies on None behaving this way, esp. code that reads data from
databases, since None is the Python mapping for SQL NULL.
At
The behavior of None in comparisons is intentional in Python 3. You
can agitate to change it, but it will probably die when Guido gets
wind of it ;-)
The catch-all mixed-type comparison rules in Pythons 1 and 2 were only
intended to be arbitrary but consistent. Of course each specific
release
On 17.02.2014 21:12, Tim Peters wrote:
[...]
Guido wanted to drop all the arbitrary but consistent mixed-type
comparison crud for Python 3. Nothing special about None in that. As
already noted, the various `datetime` types were the first to
experiment with implementing full blown
On 18 Feb 2014 03:37, Larry Hastings la...@hastings.org wrote:
On 02/16/2014 04:03 PM, Victor Stinner wrote:
Hi,
The PEP 436 is still a draft and not mentionned in Python 3.4
changelog. The PEP proposes to add a DSL, not to modify all modules
implemented in C. I think that it should be
On 18 Feb 2014 08:25, Nick Coghlan ncogh...@gmail.com wrote:
On 17 Feb 2014 22:25, M.-A. Lemburg m...@egenix.com wrote:
On 17.02.2014 13:12, Nick Coghlan wrote:
On 17 Feb 2014 21:15, M.-A. Lemburg m...@egenix.com wrote:
None is special in Python and has always (and intentionally)
On Feb 18, 2014, at 08:25 AM, Nick Coghlan wrote:
Thanks, that's enough to persuade me that it is a good idea to restore that
behaviour (and make it an official part of the language spec) as part of
the eliminate remaining barriers to migration from Python 2 effort in 3.5.
At the very least,
On 2/17/2014 5:25 PM, Nick Coghlan wrote:
On 17 Feb 2014 22:25, M.-A. Lemburg m...@egenix.com
mailto:m...@egenix.com wrote:
default_3way_compare(PyObject *v, PyObject *w)
...
/* None is smaller than anything */
Unless it is not, as with datetimes, perhaps other classes written
On 02/17/2014 03:20 PM, Victor Stinner wrote:
2014-02-17 0:25 GMT+01:00 Larry Hastings la...@hastings.org:
You might think that anything you check in to the default branch in Python
trunk will go into 3.4.0 rc2, and after that ships, checkins would go into
3.4.0 final. Ho ho ho! That's not
[M.-A. Lemburg]
...
None worked as compares less than all other objects simply due
to the fact that None is a singleton and doesn't implement the
comparison slots (which for all objects not implementing rich
comparisons, meant that the fallback code triggered in Python 2).
And the fallback
On 2/17/2014 6:20 PM, Victor Stinner wrote:
2014-02-17 0:25 GMT+01:00 Larry Hastings la...@hastings.org:
You might think that anything you check in to the default branch in Python
trunk will go into 3.4.0 rc2, and after that ships, checkins would go into
3.4.0 final. Ho ho ho! That's not
Tim Peters wrote:
Guido wanted to drop all the arbitrary but consistent mixed-type
comparison crud for Python 3.
Nobody is asking for a return to the arbitrary-but-
[in]consistent mess of Python 2, only to bring
back *one* special case, i.e. None comparing less
than everything else.
I think
[Tim]
Guido wanted to drop all the arbitrary but consistent mixed-type
comparison crud for Python 3.
[Greg Ewing]
Nobody is asking for a return to the arbitrary-but-
[in]consistent mess of Python 2, only to bring
back *one* special case, i.e. None comparing less
than everything else.
Of
On Mon, Feb 17, 2014 at 6:36 PM, victor.stinner
python-check...@python.org wrote:
http://hg.python.org/cpython/rev/79ccf36b0fd0
changeset: 89239:79ccf36b0fd0
user:Victor Stinner victor.stin...@gmail.com
date:Tue Feb 18 01:35:40 2014 +0100
summary:
Close #20656: Fix
Terry Reedy wrote:
To make None a true bottom object, the rich comparison
methods would have to special-case None as either argument before
looking at the __rc__ special methods of either.
I don't think it would be necessary to go that far.
It would be sufficient to put the special case
Tim Peters wrote:
[Greg Ewing]
often
one wants to sort a collection of objects having
keys that can take on null values.
Perhaps that's often true of your code, but it's never been true of mine.
It's fairly common in accounting circles. I have a
collection of invoices, each of which can
40 matches
Mail list logo
