[Python-Dev] Would like to contribute to Core Python Comunity on the Project Idea
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 software. You can have a look at my github profile.[1] My first priority programming languages include GNU C/C++ and Python. I have been using these languages for the Coding, Programming challenges, Application development and contributing to open source software. Apart from this, I am also aware of version control systems git/github, SVN, bazaar and other web technologies like Javascript, Jinja templates, HTML, CSS too. I am ambititous person eager to learn other technologies when in need while working. You can have a look at my Wikipedia profile.[2] My interests include Programming Languages, open source software development, networking concepts and system administration tasks. While looking at the Project Ideas proposed by the mentors and developers of the Python Community, I found the Email Projects working to work for support of RFC 6532 in the email package and support of RFC 6531 in the smtplib and/or smtpd. I am willing to work on this project ideas as a prospective student in the upcoming Google Summer of Code 2014. I would like to discuss with the mentors more about the project in detail and would like to start off contributing to the project early enough so as to make a strong proposal for Gsoc 2014. *Nitin Agarwal* [1] https://github.com/NitinAgarwal [2] https://en.wikipedia.org/wiki/User:Nitinagarwal3006 [3] IRC handle : nitinagarwal3006 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
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 values to be collected at the beginning of a list, sometimes at the end. Sometimes you want them treated as top elements, sometimes as bottom. And sometimes it is a real error for missing values to be present. Not to mention that sometimes the programmer simply hasn't thought about the appropriate policy. I don't think Python should silently impose a policy in that case, especially given that the programmer may have experience with any of the above treatments in other contexts. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
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 completely missed the use case of being able to sensibly map SQL NULL handling in ORDER BY clauses to the sorting of Python 3 containers. Having a concrete use case with widespread implications makes a big difference :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Function to handle None in sort operation, was Re: python 3 niggle: None < 1 raises TypeError
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] >> >> Python3: > l = [1,2,None,4,5,None,6] > l.sort() >> Traceback (most recent call last): >> File "", line 1, in >> TypeError: unorderable types: NoneType() < int() > > While it is trivial to fix > sorted([1,2,None,4,5,None,6], > ... key=lambda x: (x is None, x)) > [1, 2, 4, 5, 6, None, None] > > maybe the key should be given a name like functools.none_first/none_last in > order to offer a standard approach? Yeah, I was thinking something similar. I posted an RFE if anyone wants to run with the idea for Python 3.5: http://bugs.python.org/issue20630 (it's also the kind of thing that is quite amenable to inclusion in libraries like six and future for Python 2/3 compatible code bases - in Python 2, it can just be a pass through, while in Python 3 it can actually alter the sort operation to allow None values). At a broaded scale, this thread made me realise it may be worth defining a __key__ protocol so custom comparisons are easier to implement correctly: http://bugs.python.org/issue20632 That would need a PEP, but currently, there are lots of things you need to deal with around hashability, comparison with other types, etc when attempting to define a custom ordering. A new __key__ protocol could provide sensible default behaviour for all of those, such that you only needed to define the other methods if you wanted to override the defaults for some reason. (As noted in the issue, this is also amenable to being implemented as a third party module prior to proposing it as a language feature) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
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('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 is greater than everything imaginable... except for a nice
MLT - a mutton, lettuce, and tomato sandwich... oh.
Where things get tricky is when you compare two AlwaysGreater objects.
Or even compare one against itself. It has to be greater.
equal, and less than itself. Or not, depending on exactly how the
methods are defined and coded. Which, as I remember, is part of why the
idea of a *generic* class was rejected. Real cases are better served by
custom classes that meet the custom need.
--
Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
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 concept there -- how does postgress handle
it? (is this a generic range, or a datetime range? I'm not up on it).
If this means what I think it does, None is really a hack, both because of
al lteh specia case code required for sorting, comparing, etc, but also
because it's missing information -- the two ends of the range should really
have different meanings.
Postgres range types are a separate kind of type which can be created
using CREATE TYPE:
http://www.postgresql.org/docs/current/interactive/sql-createtype.html
Several handy range types are built in, although not as many as one might
expect.
Postgres ranges can be made infinite by specifying NULL as a bound.
There isn't a separate special value for this. This has somewhat strange
effects when the base type of the range has its own "infinity" value:
=> select upper_inf (daterange (current_date, 'infinity'));
upper_inf
---
f
(1 row)
=> select isfinite ('infinity'::date);
isfinite
--
f
(1 row)
=> select upper_inf (daterange (current_date, null));
upper_inf
---
t
(1 row)
In other words, a range with non-NULL bounds is finite according to the
range functions even if the bound is the infinity value of the base type.
Isaac Morland CSCF Web Guru
DC 2619, x36650 WWW Software Specialist___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
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 is greater than everything imaginable... except for a nice
MLT - a mutton, lettuce, and tomato sandwich... oh.
Where things get tricky is when you compare two AlwaysGreater objects.
Or even compare one against itself. It has to be greater.
Great.
ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
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 want "None" to sort (positive and
> negative infinity floating point values often work well in the case of
> numeric data, but a custom AlwaysLess or AlwaysGreater type works for
> arbitrary data).
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 concept there -- how does postgress
handle it? (is this a generic range, or a datetime range? I'm not up on it).
If this means what I think it does, None is really a hack, both because of
al lteh specia case code required for sorting, comparing, etc, but also
because it's missing information -- the two ends of the range should really
have different meanings.
I've dealt with this for Python datetime via a pari fo custom InfDateTime
objects one for plu infiinity, one for minus. Then we can use these in
ranges and the reest of teh code can jsut do simple comparisons, sorting
etc.
Of course, floating point numbers have inf and -inf, which is really useful.
I hadn't though of Nick's generic AlwaysLess or AlwaysGreater type -- if
that means what I think it does -- i,e, it would compare appropriately to
ANY other object, that would actually be a nice addition to
the standard library. I had been thinking that the standard
library datetime could use these, but why not just use generic ones?
(though it could get a bit tricky -- what would AlwaysGreater >
float('inf") evaluate to?
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
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 that psycopg2 uses. These have 3 attributes that can either be None or, for sake of argument, a numeric value. 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, other._upper, other._bounds)) Because None < 1 raises a TypeError, in Python 3 I have to do: def __lt__(self, other): if not isinstance(other, Range): return NotImplemented for attr in '_lower', '_upper', '_bounds': self_value = getattr(self, attr) other_value = getattr(other, attr) if self_value == other_value: pass elif self_value is None: return True elif other_value is None: return False else: return self_value < other_value return False Am I missing something? How can I get this method down to a sane size? How about this: def make_key(item): return [(x is not None, x or 0) for i in [item._lower, item._upper, item._bounds]] def __lt__(self, other): if not isinstance(other, Range): return NotImplemented return make_key(self) < make_key(other) It'll make None less than any number. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
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 -> None mapping and in many cases > +/- infinity already work fine). only for floating point -- it would be nice to have them for other types: integers, datetimes, any others that make sense ( In know I've wanted +-inf and NaN for integers forever, though what I really want is hardware support) But do you do that with a generic type or a special one for each type? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
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 with patches: 2052 Issues opened (66) == #16314: Support xz compression in distutils http://bugs.python.org/issue16314 reopened by Arfrever #20320: select.select(timeout) and select.kqueue.control(timeout) must http://bugs.python.org/issue20320 reopened by haypo #20543: ** operator does not overflow to inf http://bugs.python.org/issue20543 opened by Keith.Randall #20544: Use specific asserts in operator tests http://bugs.python.org/issue20544 opened by serhiy.storchaka #20545: Use specific asserts in unicode tests http://bugs.python.org/issue20545 opened by serhiy.storchaka #20547: Use specific asserts in bigmem tests http://bugs.python.org/issue20547 opened by serhiy.storchaka #20548: Use specific asserts in warnings and exceptions tests http://bugs.python.org/issue20548 opened by serhiy.storchaka #20550: Use specific asserts in collections tests http://bugs.python.org/issue20550 opened by serhiy.storchaka #20551: Use specific asserts in decimal tests http://bugs.python.org/issue20551 opened by serhiy.storchaka #20552: Use specific asserts in bytes tests http://bugs.python.org/issue20552 opened by serhiy.storchaka #20554: Use specific asserts in argparse and optparse tests http://bugs.python.org/issue20554 opened by serhiy.storchaka #20556: Use specific asserts in threading tests http://bugs.python.org/issue20556 opened by serhiy.storchaka #20557: Use specific asserts in io tests http://bugs.python.org/issue20557 opened by serhiy.storchaka #20558: ECONNRESET value in logging.config is valid with Linux [distro http://bugs.python.org/issue20558 opened by yaneurabeya #20559: urllib/http fail to sanitize a non-ascii url http://bugs.python.org/issue20559 opened by Dubslow #20560: tkFileFilter.c: ostypeCount not initialized? http://bugs.python.org/issue20560 opened by terry.reedy #20562: sqlite3 returns result set with doubled first entry http://bugs.python.org/issue20562 opened by jwezel #20564: test_threadsignals.py "failed" on OpenBSD because too slow (> http://bugs.python.org/issue20564 opened by rpointel #20565: Update Tcl/Tk version for buildbots http://bugs.python.org/issue20565 opened by serhiy.storchaka #20567: test_idle causes test_ttk_guionly 'can't invoke "event" comman http://bugs.python.org/issue20567 opened by ned.deily #20568: Pass --default-install to ensurepip in the Windows installers http://bugs.python.org/issue20568 opened by ncoghlan #20569: IDLE : Add clipboard history feature http://bugs.python.org/issue20569 opened by sahutd #20570: Bundle pip 1.5.3 in Python 3.4rc2 http://bugs.python.org/issue20570 opened by ncoghlan #20572: subprocess.Popen.wait() undocumented "endtime" parameter http://bugs.python.org/issue20572 opened by giampaolo.rodola #20573: "built-in repr()" function link on the repr module documentati http://bugs.python.org/issue20573 opened by rutsky #20574: Implement incremental decoder for cp65001 http://bugs.python.org/issue20574 opened by haypo #20575: Type handling policy for the statistics module http://bugs.python.org/issue20575 opened by oscarbenjamin #20577: IDLE: Remove FormatParagraph's width setting from config dialo http://bugs.python.org/issue20577 opened by taleinat #20578: BufferedIOBase.readinto1 is missing http://bugs.python.org/issue20578 opened by nikratio #20579: OS X IDLE keyboard accelerators fail or misbehave wi http://bugs.python.org/issue20579 opened by ned.deily #20580: IDLE should support platform-specific default config defaults http://bugs.python.org/issue20580 opened by ned.deily #20581: Incorrect behaviour of super() in a metaclass-created subclass http://bugs.python.org/issue20581 opened by jdetrey #20582: socket.getnameinfo() does not document flags http://bugs.python.org/issue20582 opened by roysmith #20584: On FreeBSD, signal.NSIG is smaller than biggest signal value http://bugs.python.org/issue20584 opened by jgehrcke #20585: urllib2 unrelease KQUEUE on Mac OSX 10.9+ http://bugs.python.org/issue20585 opened by Andrew.Gross #20586: Argument Clinic: functions with valid sig but no docstring hav http://bugs.python.org/issue20586 opened by zach.ware #20587: sqlite3 converter not being called http://bugs.python.org/issue20587 opened by kmk #20589: pathlib.owner() and pathlib.group() raise ImportError on Windo http://bugs.python.org/issue20589 opened by spiralx #20596: Support for alternate wcstok syntax for Windows compilers http://bugs.python.org/issue20596 opened by Jeffrey.Armstrong #20597: PATH_MAX already defined on some Windows compilers http://bugs.python.org/issue20597 opened by Jeffrey.Armstrong #20598: argparse docs: '7'.split() is confusing ma
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
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, that breaks any backwards compatibility if your SQL library mapped NULL to None in earlier versions. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Function to handle None in sort operation, was Re: python 3 niggle: None < 1 raises TypeError
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 recent call last): > File "", line 1, in > TypeError: unorderable types: NoneType() < int() While it is trivial to fix >>> sorted([1,2,None,4,5,None,6], ... key=lambda x: (x is None, x)) [1, 2, 4, 5, 6, None, None] maybe the key should be given a name like functools.none_first/none_last in order to offer a standard approach? On the other hand I'm not sure I like none_last(x) < none_last(y) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
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 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 attributes that can > either be None or, for sake of argument, a numeric value. > >>> [...] It was considered. It's not obvious where you want "None" to appear in your ordering, so you will have to implement this by yourself. I can't come up with anything obviously shorter. >>> >>> I have to agree with Lennart. The fact that SQL defines an order for >>> NULL and other values doesn't mean it's obvious or right in any way (I >>> never remember which way it goes). >> >> SQL doesn't define an order for NULL, it's more like a "quiet NaN" - >> if either operand is NULL, the result is also NULL. (I ran into this >> recently, in the context of "NULL == value" and "NULL != value" both >> being effectively false). > > 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. They do, but it's not consistent: MS SQL Server: orders NULLs first (in table order; stable sort) Sybase ASE:orders NULLs first (in arbitrary order) Oracle:orders NULLs last (in arbitrary order) PostgreSQL:orders NULLs last (in arbitrary order) IBM DB2: orders NULLs last (in table order; stable sort) Reference: tests done with actual databases. A note about consistency: None is always ordered first in Python 2, so there is a precedent. And since Python's list.sort() is stable, Python 2 is in the same camp as MS SQL Server. >From Python-2.7.6/Objects/object.c: /* None is smaller than anything */ if (v == Py_None) return -1; if (w == Py_None) return 1; 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 recent call last): File "", line 1, in TypeError: unorderable types: NoneType() < int() -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 14 2014) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2014-02-12: Released mxODBC.Connect 2.0.4 ... http://egenix.com/go53 : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
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 PyPy, Cython > and Jython. ;-) > > Oleg. > -- > Oleg Broytmanhttp://phdru.name/p...@phdru.name >Programmers don't die, they just GOSUB without RETURN. Unicode + bytes explodes in order to get the error sooner.i.e Not waiting for the killer 8bit string. So None<1 is the opposite ! sort(somelist) is a ticking bomb in py3 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
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 Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
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 ... ASC and last if you do ORDER BY ... DESC.""" Not configurable in MySQL. It's apparently not part of the standard, according to Wikipedia: http://en.wikipedia.org/wiki/Order_by So definitely SQL's handling of NULL should not be any sort of guide as regards Python's treatment of None. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
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 in Oracle, with (IIRC) > NULLS LAST as default. But I agree, this is not an argument in favour > of doing the same in Python. IIRC, MySQL and PostgreSQL sort them in the opposite order from each other (or it's possibly just Teiid's PostgreSQL emulation that is the opposite of MySQL). Either way, it nicely illustrates *why* we didn't grant None an exemption from the "no implicit cross-type ordering operations" in 3.x. It does make *adapting* to other models like SQL a bit more painful though. 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 -> None mapping and in many cases +/- infinity already work fine). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
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 matter: http://www.postgresql.org/docs/9.3/static/sql-select.html#SQL-ORDERBY In short, NULL is by default considered greater than anything else (last in an ascending sort, first in a descending sort), but this can be inverted. Oddly enough, the syntax is NULLS FIRST vs NULLS LAST, not NULLS LOW vs NULLS HIGH. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
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 agree, this is not an argument in favour of doing the same in Python. Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
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 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 attributes that can > >> > either be None or, for sake of argument, a numeric value. > >> > > > [...] > >> > >> It was considered. It's not obvious where you want "None" to appear in > >> your ordering, so you will have to implement this by yourself. I can't > >> come up with anything obviously shorter. > > > > I have to agree with Lennart. The fact that SQL defines an order for > > NULL and other values doesn't mean it's obvious or right in any way (I > > never remember which way it goes). > > SQL doesn't define an order for NULL, it's more like a "quiet NaN" - > if either operand is NULL, the result is also NULL. (I ran into this > recently, in the context of "NULL == value" and "NULL != value" both > being effectively false). 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. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
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 concrete I case I have is implementing stable ordering for the >> > python Range objects that psycopg2 uses. These have 3 attributes that can >> > either be None or, for sake of argument, a numeric value. >> > > [...] >> >> It was considered. It's not obvious where you want "None" to appear in >> your ordering, so you will have to implement this by yourself. I can't >> come up with anything obviously shorter. > > I have to agree with Lennart. The fact that SQL defines an order for > NULL and other values doesn't mean it's obvious or right in any way (I > never remember which way it goes). SQL doesn't define an order for NULL, it's more like a "quiet NaN" - if either operand is NULL, the result is also NULL. (I ran into this recently, in the context of "NULL == value" and "NULL != value" both being effectively false). We could theoretically do something similar, but the NULL handling in SQL is a frequent source of bugs in filter definitions, so that really doesn't sound like a good idea. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
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 the > > python Range objects that psycopg2 uses. These have 3 attributes that can > > either be None or, for sake of argument, a numeric value. > > [...] > > It was considered. It's not obvious where you want "None" to appear in > your ordering, so you will have to implement this by yourself. I can't > come up with anything obviously shorter. I have to agree with Lennart. The fact that SQL defines an order for NULL and other values doesn't mean it's obvious or right in any way (I never remember which way it goes). Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
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
> python Range objects that psycopg2 uses. These have 3 attributes that can
> either be None or, for sake of argument, a numeric value.
>
> 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, other._upper, other._bounds))
>
> Because None < 1 raises a TypeError, in Python 3 I have to do:
>
> def __lt__(self, other):
> if not isinstance(other, Range):
> return NotImplemented
> for attr in '_lower', '_upper', '_bounds':
> self_value = getattr(self, attr)
> other_value = getattr(other, attr)
> if self_value == other_value:
> pass
> elif self_value is None:
> return True
> elif other_value is None:
> return False
> else:
> return self_value < other_value
> return False
>
> Am I missing something? How can I get this method down to a sane size?
It was considered. It's not obvious where you want "None" to appear in
your ordering, so you will have to implement this by yourself. I can't
come up with anything obviously shorter.
Or, well, this, but it's not exactly pretty:
def __lt__(self, other):
if not isinstance(other, Range):
return NotImplemented
ninf = float('-inf') # So None is lower than anything else.
return ((self._lower if self._lower is not None else ninf,
self._upper if self._upper is not None else ninf,
self._bounds if self._bounds is not None else ninf) < (
other._lower if other._lower is not None else ninf,
other._upper if other._upper is not None else ninf,
other._bounds if other._bounds is not None else ninf))
Or maybe:
def __lt__(self, other):
if not isinstance(other, Range):
return NotImplemented
s = (self._lower, self._upper, self._bounds)
if None is s:
return True
o = (other._lower, other._upper, other._bounds)
if None in o:
return False
return s < o
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
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, other._upper, other._bounds)) > > Because None < 1 raises a TypeError, in Python 3 I have to do: > > def __lt__(self, other): > if not isinstance(other, Range): > return NotImplemented > for attr in '_lower', '_upper', '_bounds': > self_value = getattr(self, attr) > other_value = getattr(other, attr) > if self_value == other_value: > pass > elif self_value is None: > return True > elif other_value is None: > return False > else: > return self_value < other_value > return False > > Am I missing something? How can I get this method down to a sane size? Can you be certain that all your values are either None or positive integers? If so, try this: def __lt__(self, other): if not isinstance(other, Range): return True # or NotImplemented, not sure why this change return ((self._lower or 0, self._upper or 0, self._bounds or 0) < (other._lower or 0, other._upper or 0, other._bounds or 0)) That'll treat all Nones as 0, and compare them accordingly. If you can't depend on them being positive (eg if you need None to be less than 0 rather than equal - even more so if you need it to be less than negative numbers), you'll need to more explicitly check. But this is nice and tidy, if it works. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError
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 values often work well in the case of numeric data, but a custom AlwaysLess or AlwaysGreater type works for arbitrary data). You can either do that dynamically, or else cache the normalised values when the attributes are set. Python 2 used to guess, Python 3 makes developers decide how they want None to be handled in the context of ordering operations. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] python 3 niggle: None < 1 raises TypeError
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 attributes that can either be None or, for sake of argument, a numeric value. 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, other._upper, other._bounds)) Because None < 1 raises a TypeError, in Python 3 I have to do: def __lt__(self, other): if not isinstance(other, Range): return NotImplemented for attr in '_lower', '_upper', '_bounds': self_value = getattr(self, attr) other_value = getattr(other, attr) if self_value == other_value: pass elif self_value is None: return True elif other_value is None: return False else: return self_value < other_value return False Am I missing something? How can I get this method down to a sane size? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
