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
M.-A. Lemburg wrote:
IMO, it was a mistake to have None return a TypeError in
comparisons, since it makes many typical data operations
fail, e.g.
Python2:
l = [1,2,None,4,5,None,6]
l.sort()
l
[None, None, 1, 2, 4, 5, 6]
Python3:
l = [1,2,None,4,5,None,6]
l.sort()
Traceback (most
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,
ACTIVITY SUMMARY (2014-02-07 - 2014-02-14)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4524 (+23)
closed 27875 (+62)
total 32399 (+85)
Open issues
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 14 February 2014 22:01, Peter Otten __pete...@web.de wrote:
M.-A. Lemburg wrote:
IMO, it was a mistake to have None return a TypeError in
comparisons, since it makes many typical data operations
fail, e.g.
Python2:
l = [1,2,None,4,5,None,6]
l.sort()
l
[None, None, 1, 2, 4, 5, 6]
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
Hi,
Here, its Nitin Agarwal, an open source software developer and enthusiast.
Currently, I am pursuing Computer Science and Engineering at International
Institute of Information Technology, INDIA. I had an experience working
with
the open source organisations and development of open source
26 matches
Mail list logo
