On 2/21/2014 7:57 PM, Chris Angelico wrote:

On Sat, Feb 22, 2014 at 12:10 PM, Glenn Linderman <v+python@g.nevcal.com> wrote:

Here's a challenge: There has been a big thread about None versus (SQL)
Null. Show how an except: expression can help the DB API more easily convert
from using None to using a new Null singleton, and you'll have a winner :)

Heh! I'm not entirely sure how that would work, as I've only skimmed
the DB API thread, but I understand part of it is to do with sorting.
I'm not sure how you could embed an except-expression into that
without either changing the sort function or potentially doing part of
the sort twice:

lst = sorted(stuff) except TypeError: sorted(stuff, key=keyfunc)

at which point you may as well go straight to the key= form from the start.

Yes, the "challenge" was sort of tongue-in-cheek... it was the latest heavily opinionated thread with no conclusion... and if a particular feature could help arrive at a good solution I think a lot of people would be happy! And probably a lot would still think it wasn't a good solution!

It does help acceptance of a new feature to describe and demonstrate a solution to a compelling problem; Stephen's recent explanation of LBYL and EAFP expressions helped make it more compelling to me, it sounded like you added some of that to the PEP, which is good. Some folks didn't find the PEP examples compelling, it seems.

The sorting is a smoke-screen. The real problem is that None and Null are not the same thing, and so internally the DB Api should invent and use Null, and translate to None (optionally) at the interfaces, for backwards compatibility until their users can update their software to use Null also.

The implementation of Null can handle the comparison/sorting issue... there are a fixed number of types for SQL, so it isn't that hard.