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
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" an
On 2/19/2014 2:53 AM, Lennart Regebro wrote:
On Tue, Feb 18, 2014 at 5:10 PM, Mark Lawrence 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 co
On Tue, Feb 18, 2014 at 5:10 PM, Mark Lawrence 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? :)
I think this is possi
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 thi
On 19 Feb 2014 07:26, "Paul Moore" wrote:
>
> On 18 February 2014 21:17, Greg Ewing 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 p
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 18 February 2014 21:17, Greg Ewing 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 up over time into
a bit
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 sor
On Wed, Feb 19, 2014 at 3:10 AM, Mark Lawrence 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? :)
That would be a major
Brett Cannon 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 everything
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 N
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 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.
I
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 r
On 18 February 2014 15:53, Terry Reedy 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 the implem
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 y
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 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 good, consi
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 ob
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 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, ke
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, datetim
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 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 initial
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 account
On Tue, Feb 18, 2014 at 8:35 AM, Greg Ewing 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
__
On 18 February 2014 07:35, Greg Ewing 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
nvl, so I will too:
d
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 ha
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 *after
[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 els
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
[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 fall
On 2/17/2014 5:25 PM, Nick Coghlan wrote:
On 17 Feb 2014 22:25, "M.-A. Lemburg" 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
similarly,
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 18 Feb 2014 08:25, "Nick Coghlan" wrote:
>
>
> On 17 Feb 2014 22:25, "M.-A. Lemburg" wrote:
> >
> > On 17.02.2014 13:12, Nick Coghlan wrote:
> > > On 17 Feb 2014 21:15, "M.-A. Lemburg" wrote:
> > >>
> > >> None is special in Python and has always (and intentionally) sorted
> > >> before any o
On 17 Feb 2014 22:25, "M.-A. Lemburg" wrote:
>
> On 17.02.2014 13:12, Nick Coghlan wrote:
> > On 17 Feb 2014 21:15, "M.-A. Lemburg" 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
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 Pyt
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 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
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
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 the
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 assu
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.
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" 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
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/issue16734
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 Tue, Feb 18, 2014 at 1:30 AM, M.-A. Lemburg 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
>> be...
On 17.02.2014 14:29, Gustavo Carneiro wrote:
> On 17 February 2014 12:30, M.-A. Lemburg 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, N
On 17 February 2014 12:30, M.-A. Lemburg 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 as
> >
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 flo
On 17.02.2014 13:12, Nick Coghlan wrote:
> On 17 Feb 2014 21:15, "M.-A. Lemburg" 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 operation
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 Feb 2014 21:15, "M.-A. Lemburg" 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 understan
On 17.02.2014 12:49, Gustavo Carneiro wrote:
> On 17 February 2014 11:43, M.-A. Lemburg wrote:
>
>> On 17.02.2014 12:23, Gustavo Carneiro wrote:
>>> On 17 February 2014 11:14, M.-A. Lemburg wrote:
>>>
On 15.02.2014 07:03, Stephen J. Turnbull wrote:
> M.-A. Lemburg writes:
>
> >
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, N
On 17 February 2014 11:49, Gustavo Carneiro 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 to Python 3
On 17 February 2014 11:43, M.-A. Lemburg wrote:
> On 17.02.2014 12:23, Gustavo Carneiro wrote:
> > On 17 February 2014 11:14, M.-A. Lemburg 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 TypeE
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 recen
On 17.02.2014 12:23, Gustavo Carneiro wrote:
> On 17 February 2014 11:14, M.-A. Lemburg 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 op
On 17 February 2014 11:14, M.-A. Lemburg 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 underst
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.
>
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 va
On 15 February 2014 08:10, Terry Reedy 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 discussions is that we
c
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 > float('i
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 conc
On Sat, Feb 15, 2014 at 4:14 AM, Chris Barker 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 floating
point. It i
On Fri, Feb 14, 2014 at 1:29 AM, Nick Coghlan wrote:
> On 14 February 2014 18:04, Chris Withers 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 wa
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 t
On Fri, Feb 14, 2014 at 2:42 AM, Nick Coghlan wrote:
> That's the main reason I still occasionally wonder if
> "AlwaysMin" and "AlwaysMax" singletons might make sense, although that
> approach has problems of its own (specifically, it's hard to actually
> use without breaking the clean NULL -> N
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 14.02.2014 11:20, Antoine Pitrou wrote:
> On Fri, 14 Feb 2014 20:13:43 +1000
> Nick Coghlan wrote:
>> On 14 February 2014 20:02, Antoine Pitrou wrote:
>>> On Fri, 14 Feb 2014 10:46:50 +0100
>>> Lennart Regebro wrote:
>
> Sending this to python-dev as I'm wondering if this was consider
On Feb 14, 2014 1:13 PM, "Oleg Broytman" wrote:
>
> On Fri, Feb 14, 2014 at 09:54:35PM +1100, Chris Angelico
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 PyP
On Fri, Feb 14, 2014 at 09:54:35PM +1100, Chris Angelico
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.
--
Oleg Broytman
On Fri, Feb 14, 2014 at 9:42 PM, Nick Coghlan 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 do
ORDER BY ...
On 14 February 2014 20:30, Paul Moore wrote:
> On 14 February 2014 10:20, Antoine Pitrou 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 i
On Fri, Feb 14, 2014 at 9:20 PM, Antoine Pitrou 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 take on the matt
On 14 February 2014 10:20, Antoine Pitrou 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 default. But I agr
On Fri, 14 Feb 2014 20:13:43 +1000
Nick Coghlan wrote:
> On 14 February 2014 20:02, Antoine Pitrou wrote:
> > On Fri, 14 Feb 2014 10:46:50 +0100
> > Lennart Regebro wrote:
> >> >
> >> > Sending this to python-dev as I'm wondering if this was considered when
> >> > the
> >> > choice to have obje
On 14 February 2014 20:02, Antoine Pitrou wrote:
> On Fri, 14 Feb 2014 10:46:50 +0100
> Lennart Regebro 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 c
On Fri, 14 Feb 2014 10:46:50 +0100
Lennart Regebro 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 ordering for t
On Fri, Feb 14, 2014 at 9:04 AM, 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
>
On Fri, Feb 14, 2014 at 7:04 PM, Chris Withers 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) <
> (other._lower,
On 14 February 2014 18:04, Chris Withers 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 infinity floating point v
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 attribu
84 matches
Mail list logo
