On Tue, Feb 18, 2014 at 5:10 PM, Mark Lawrence breamore...@yahoo.co.uk wrote:
Sorry if this has already been suggested, but why not introduce a new
singleton to make the database people happier if not happy? To avoid
confusion call it dbnull? A reasonable compromise or complete cobblers? :)
On 2/19/2014 2:53 AM, Lennart Regebro wrote:
On Tue, Feb 18, 2014 at 5:10 PM, Mark Lawrence breamore...@yahoo.co.uk wrote:
Sorry if this has already been suggested, but why not introduce a new
singleton to make the database people happier if not happy? To avoid
confusion call it dbnull? A
On 20/02/14 08:23, Glenn Linderman wrote:
Of course it is not backwards compatible... but once all the database related
None usage is switched to Null usage it should work the same as before,
My problem with this is that there is no clear distinction
between database-related None usage and
Greg Ewing writes:
Data retrieved from a database is often passed to other code
that has nothing to do with databases, and data received from
other code is inserted into databases. Somewhere in between
someone is going to have to be careful to translate back and
forth between Nones and
On 18 February 2014 07:35, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
If you don't want to touch comparison in general,
how about an option to sort()?
results = sorted(invoices, key=attrgetter('duedate'), none='first')
Or alternatively, a default on None function - Oracle SQL calls this
On Tue, Feb 18, 2014 at 8:35 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
If you don't want to touch comparison in general,
how about an option to sort()?
results = sorted(invoices, key=attrgetter('duedate'), none='first')
I think this is a much better option.
//Lennart
Am 18.02.2014 08:35, schrieb Greg Ewing:
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
On 18.02.2014 05:25, Tim Peters wrote:
[M.-A. Lemburg]
Now, the choice to have None compare less than all other objects
may have been arbitrary, but IMO it was a good, consistent and
useful choice.
Possibly useful for some apps, sure. Not for my apps. For example,
when I initialize an
18.02.14 10:10, Paul Moore написав(ла):
Or alternatively, a default on None function - Oracle SQL calls this
nvl, so I will too:
def nvl(x, dflt):
return dflt if x is None else x
results = sorted(invoices, key=lambda x: nvl(x.duedate, datetime(MINYEAR,1,1))
Or, as was proposed above:
On 2014-02-18 13:48, Serhiy Storchaka wrote:
18.02.14 10:10, Paul Moore написав(ла):
Or alternatively, a default on None function - Oracle SQL calls this
nvl, so I will too:
def nvl(x, dflt):
return dflt if x is None else x
results = sorted(invoices, key=lambda x: nvl(x.duedate,
On 2014-02-18 14:11, MRAB wrote:
On 2014-02-18 13:48, Serhiy Storchaka wrote:
18.02.14 10:10, Paul Moore написав(ла):
Or alternatively, a default on None function - Oracle SQL calls this
nvl, so I will too:
def nvl(x, dflt):
return dflt if x is None else x
results = sorted(invoices,
On 2/18/2014 12:11 AM, Greg Ewing wrote:
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.
For a None, that is only the fallback rule if a does not handle the
comparison.
On 2/18/2014 2:35 AM, Greg Ewing wrote:
results = sorted(invoices, key=attrgetter('duedate'), none='first')
I think this is the best idea on the thread. As a pure enhancement, it
could be added in 3.5. The only tricky part of the implementation is
maintaining stability of the sort. The
I'll reply inline, but tl;dr: I'm with Tim on this.
On Tue, Feb 18, 2014 at 5:08 AM, M.-A. Lemburg m...@egenix.com wrote:
On 18.02.2014 05:25, Tim Peters wrote:
[M.-A. Lemburg]
Now, the choice to have None compare less than all other objects
may have been arbitrary, but IMO it was a
On 2/18/2014 12:32 AM, Greg Ewing wrote:
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 is if
On 18 February 2014 15:53, Terry Reedy tjre...@udel.edu wrote:
On 2/18/2014 2:35 AM, Greg Ewing wrote:
results = sorted(invoices, key=attrgetter('duedate'), none='first')
I think this is the best idea on the thread. As a pure enhancement, it could
be added in 3.5. The only tricky part of
On 18/02/2014 15:45, Terry Reedy wrote:
On 2/18/2014 12:11 AM, Greg Ewing wrote:
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.
For a None, that is only the fallback
On 02/18/2014 02:08 AM, M.-A. Lemburg wrote:
This is not garbage data, it's just missing information for
a particular field [...]
I think the basic problem is that None was over-used (or even mis-used?) to the point where 3.0 had to make a choice to
bring consistency back to the language.
18.02.14 19:20, Ethan Furman написав(ла):
It seems to me what we really need is either a Null singleton to
represent a data point with no known value but that can still be sorted,
or have every data type able to represent a no-value state (datetime,
I'm looking at you!).
A Never singleton?
On 2/18/2014 7:57 AM, Brett Cannon wrote:
Yes, I see your point, but please also consider that None is
used in database applications as natural mapping for SQL NULL
and in other data processing applications to mean no value.
Fine, but not everything uses a database. =)
Python
Brett Cannon br...@python.org writes:
Yes, I see your point, but please also consider that None is
used in database applications as natural mapping for SQL NULL
and in other data processing applications to mean no value.
Fine, but not everything uses a database. =)
Right, and even if
On Wed, Feb 19, 2014 at 3:10 AM, Mark Lawrence breamore...@yahoo.co.uk wrote:
Sorry if this has already been suggested, but why not introduce a new
singleton to make the database people happier if not happy? To avoid
confusion call it dbnull? A reasonable compromise or complete cobblers? :)
Georg Brandl wrote:
Seeing how you need a key function in any case for this sort to work,
it's only the or mindate added, which I can't recognize as ridiculous
amount of boilerplate.
Well, I don't much like having to construct a key
function in the first place for something as common
as
On 18 February 2014 21:17, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
What I'd *really* like to be able to write is:
sort(invoices, keyattr = 'duedate', none = 'first')
Which is of course a pretty trivial utility function to write. But I
understand your point - these trivial helpers add
M.-A. Lemburg wrote:
The alternative would be adding a new singleton to mean mostly
the same thing as None, but having the property of comparing
less than all other objects and then recommend its use in the
DB-API for Python 3 applications...
Which I think would be a *really bad* idea, because
On 19 Feb 2014 07:26, Paul Moore p.f.mo...@gmail.com wrote:
On 18 February 2014 21:17, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
What I'd *really* like to be able to write is:
sort(invoices, keyattr = 'duedate', none = 'first')
Which is of course a pretty trivial utility function
On 2/18/2014 1:27 PM, Greg Ewing wrote:
M.-A. Lemburg wrote:
The alternative would be adding a new singleton to mean mostly
the same thing as None, but having the property of comparing
less than all other objects and then recommend its use in the
DB-API for Python 3 applications...
Which I
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 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 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
[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
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
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
Hi All,
Sending this to python-dev as I'm wondering if this was considered when
the choice to have objects of different types raise a TypeError when
ordered...
So, the concrete I case I have is implementing stable ordering for the
python Range objects that psycopg2 uses. These have 3
On 14 February 2014 18:04, Chris Withers ch...@simplistix.co.uk wrote:
Am I missing something? How can I get this method down to a sane size?
The easiest way is usually to normalise the attributes to a sensible
numeric value depending on where you want None to sort (positive and
negative
On Fri, Feb 14, 2014 at 7:04 PM, Chris Withers ch...@simplistix.co.uk wrote:
To implement __lt__ in Python 2, I could do:
def __lt__(self, other):
if not isinstance(other, Range):
return True
return ((self._lower, self._upper, self._bounds)
On Fri, Feb 14, 2014 at 9:04 AM, Chris Withers ch...@simplistix.co.uk wrote:
Hi All,
Sending this to python-dev as I'm wondering if this was considered when the
choice to have objects of different types raise a TypeError when ordered...
So, the concrete I case I have is implementing stable
On Fri, 14 Feb 2014 10:46:50 +0100
Lennart Regebro rege...@gmail.com wrote:
Sending this to python-dev as I'm wondering if this was considered when the
choice to have objects of different types raise a TypeError when ordered...
So, the concrete I case I have is implementing stable
On 14 February 2014 20:02, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 14 Feb 2014 10:46:50 +0100
Lennart Regebro rege...@gmail.com wrote:
Sending this to python-dev as I'm wondering if this was considered when the
choice to have objects of different types raise a TypeError when
On Fri, 14 Feb 2014 20:13:43 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On 14 February 2014 20:02, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 14 Feb 2014 10:46:50 +0100
Lennart Regebro rege...@gmail.com wrote:
Sending this to python-dev as I'm wondering if this was considered
On 14 February 2014 10:20, Antoine Pitrou solip...@pitrou.net wrote:
Hmm, it seems you're right, but I'm quite sure some DBMSes have a
consistent way of ordering NULLs when using ORDER BY on a nullable
column.
ORDER BY xxx [NULLS FIRST|LAST] is the syntax in Oracle, with (IIRC)
NULLS LAST as
On Fri, Feb 14, 2014 at 9:20 PM, Antoine Pitrou solip...@pitrou.net wrote:
Hmm, it seems you're right, but I'm quite sure some DBMSes have a
consistent way of ordering NULLs when using ORDER BY on a nullable
column.
Yes, and I believe it's part of the SQL-92 spec. Certainly here's
PostgreSQL's
On 14 February 2014 20:30, Paul Moore p.f.mo...@gmail.com wrote:
On 14 February 2014 10:20, Antoine Pitrou solip...@pitrou.net wrote:
Hmm, it seems you're right, but I'm quite sure some DBMSes have a
consistent way of ordering NULLs when using ORDER BY on a nullable
column.
ORDER BY xxx
On Fri, Feb 14, 2014 at 9:42 PM, Nick Coghlan ncogh...@gmail.com wrote:
IIRC, MySQL and PostgreSQL sort them in the opposite order from each
other
Ouch! You're right:
http://dev.mysql.com/doc/refman/5.7/en/working-with-null.html
When doing an ORDER BY, NULL values are presented first if you
On Fri, Feb 14, 2014 at 09:54:35PM +1100, Chris Angelico ros...@gmail.com
wrote:
So definitely SQL's handling of NULL should not be any sort of guide
as regards Python's treatment of None.
Why not? Just make the order different for CPython and PyPy, Cython
and Jython. ;-)
Oleg.
--
On Feb 14, 2014 1:13 PM, Oleg Broytman p...@phdru.name wrote:
On Fri, Feb 14, 2014 at 09:54:35PM +1100, Chris Angelico ros...@gmail.com
wrote:
So definitely SQL's handling of NULL should not be any sort of guide
as regards Python's treatment of None.
Why not? Just make the order
On 14.02.2014 11:20, Antoine Pitrou wrote:
On Fri, 14 Feb 2014 20:13:43 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On 14 February 2014 20:02, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 14 Feb 2014 10:46:50 +0100
Lennart Regebro rege...@gmail.com wrote:
Sending this to python-dev as
What I think is the biggest nitpick here is that you can't make a NULL
object so that
NULL is None
evaluates as True. If you could, you could then easily make this NULL
object evaluate as less than everything except itself and None, and
use that consistently. But since this NULL is not None,
On 2014-02-14 08:04, Chris Withers wrote:
Hi All,
Sending this to python-dev as I'm wondering if this was considered when
the choice to have objects of different types raise a TypeError when
ordered...
So, the concrete I case I have is implementing stable ordering for the
python Range objects
On Fri, Feb 14, 2014 at 1:29 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 14 February 2014 18:04, Chris Withers ch...@simplistix.co.uk wrote:
Am I missing something? How can I get this method down to a sane size?
The easiest way is usually to normalise the attributes to a sensible
On Sat, Feb 15, 2014 at 4:14 AM, Chris Barker chris.bar...@noaa.gov wrote:
(though it could get a bit tricky -- what would AlwaysGreater float('inf)
evaluate to?
It'd be true. AlwaysGreater is greater than infinity. It is greater
than float(nan). It is greater than the entire concept of
On Fri, 14 Feb 2014, Chris Barker wrote:
This is actually a pretty common case -- the question here is: Is this
really None? or does None have a special meaning. It sounds like this is a
wrapper for a PostgreSQL range object, in which case None isn't really
right, there must be a +-infinity
The idea of top and bottom objects, by whatever name, has be proposed,
discussed, and rejected on python-ideas list (which is where this
discussion really belongs if continued).
On 2/14/2014 4:41 PM, Chris Angelico wrote:
(though it could get a bit tricky -- what would AlwaysGreater
On 15 February 2014 08:10, Terry Reedy tjre...@udel.edu wrote:
The idea of top and bottom objects, by whatever name, has be proposed,
discussed, and rejected on python-ideas list (which is where this discussion
really belongs if continued).
A fair point, but my recollection of those
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 example of sort is a good one. Sometimes you want missing
82 matches
Mail list logo
