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 <m...@egenix.com> 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, consistent and > >> useful choice. > > > > Possibly useful for some apps, sure. Not for my apps. For example, > > when I initialize an object attribute to None in Python 3, I _expect_ > > I'll get an exception if I try to use that attribute in most contexts. > > It makes no more sense to ask whether that attribute is, say, less > > than 3, than it does to add 3 to it. The exception is most useful > > then. More often than not, it was annoying to me that Python 2 > > _didn't_ whine about trying to compare None. > > 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. =) > > This is not garbage data, it's just missing information for > a particular field and you can still happily process such data > without having the information for these fields as values > (indeed in some cases, the information whether a field has a > value or not is important, e.g. for data validations and to cross > check entries). > > You do still want to be able to sort such data, but as it stands, > Python 3 doesn't allow you to, without adding an extra layer > of protection against None values deep inside the structures > you're sorting. > Which in my opinion is fine as the boilerplate is typically minimal. No one has said any solution is going to take even 10 lines of code to work around this. > > >> So why not bring it back > > > > A huge barrier is (or should be) that Python 3 is over 5 years old > > now. Fiddling with the semantics of basic builtin types was possible > > - and even welcome - 6 years ago. Now they really shouldn't be > > touched in the absence of a critical bug, or a wholly > > backward-compatible (with Python 3) addition. > > > >> and perhaps this time in a way that actually does work consistently for > >> all Python objects by implementing the tp_richcompare slot on > >> PyNoneType objects and documenting it ?! > > > > Something to suggest for Python 4, in which case I'll only be -0 ;-) > > Well, like I said: we'd be making something work again that has > worked before and only remove a failure case. The barrier for > entry should be lower in such a case. > But this is still a semantic change. Python 3 users could very well be relying on the fact that comparing against None raises an exception as a way to detect when erroneous data has leaked into some data structure. What is being suggested is a semantic change to a core data type within a major release. We waited until Python 3 to make comparisons against disparate types illegal for a reason. > > This is similar to bringing back the u"" literals. Those used > to cause a SyntaxError and now they no longer do. > I don't think they are similar at all. Allowing the u prefix on strings basically made something that was a typo or accidental hold-over from Python 2 just not throw an error. There was no semantic shift in what u meant in Python 3.2 vs. 3.3 which could break some code. Basically we just made some syntactic fluff not upset the parser which in no way changed the semantic meaning of the string literal it was attached to. Making None sort a specific way is beyond just adding some syntactic fluff. > > Even better: we have a chance to properly document the behavior > this time around and make it consistent all the way. > > 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 would break a lot > of existing DB-API based apps of course... which is the reason > why I'm advocating for changing None instead :-) > Or DB-API stuff needs to be updated to use some None-that-sorts singleton if they want to use None to represent NULL but sort in a specific way. As Tim has said, 3.0 has been out for five years, so we are talking about breaking code for this over what can be viewed as a minor inconvenience for DB code. The current situation is not insurmountable in any way for those that want None to sort. I should also mention I view None as representing nothing, which includes not sharing a type with anything, which is why it can't be compared against any other type in Python 3. But this suggestion of having None sort as the lowest thing no matter what in way says None is implicitly every type when it comes to sorting which breaks that mental model of None representing the void of information by being void of value, but everything when it comes to its type for comparison purposes.
_______________________________________________ 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
