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 softwa
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
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
>> [N
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
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 wit
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,
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]
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
27 matches
Mail list logo
