I'm in the camp that thinks making foo=None useful is a good thing. To the python programmer who is our audience, this has a very clear semantic. Especially when you take the scenario of using one object's values to create a query for objects like it. Having to special case None seems arbitrary and confusing.
Michael, could you help us out by elaborating on what code you have that you would have to re-write? __isnull would be deprecated but wouldn't go away. With the current semantics, you couldn't have any foo=None uses in your code (since it means nothing useful), so how could changing its meaning to something useful break your code? I agree that reopening decisions arbitrarily is a bad thing. But reconsidering in light of persistent and intelligent opposition is simply being flexible and listening to your customers. --Ned. Michael Radziej wrote: > Hi, > > first, I really dislike to reopen discussions after more than one year, not > just for this particular question but in general. We won't get anywhere if > don't keep to decisions, except for cases where new and important arguments > appear. > > I don't see any new points in this discussion. The "new user" argument has > been brought up in the original discussion, too. The question was settled, > described in documentation > (http://www.djangoproject.com/documentation/db-api/#exact), and there's a > regression test for it (regressiontests/null_query). I don't think it's a > good idea to reopen decisions at will. > > Furthermore, the database query lookup is listed as a stable API > (http://www.djangoproject.com/documentation/api_stability/) > > Worse, the proposed change will mean to change an existing API so that it > doesn't break *loudly*, but it will silently produce different results. > > I'd accept all these problems for something important. But in this case? > It's a question that will always be a bit arbitrary. Currently we get > complaints from newbies, after the change we'll get complaints from people > used to think SQL. > > Personally, I've relied on the decision as it was made, and the changes will > mean a lot of rewriting (well, of course the work will be more in finding > the places where it breaks). It would not be very friendly to your users to > break compatibility in this way. > > > On Tue, Jul 17, Malcolm Tredinnick wrote: > > >> On Tue, 2007-07-17 at 07:28 +0200, Michael Radziej wrote: >> [...] >> >>> While interpreting __exact=None as "WHERE ... = NULL" might confuse new >>> users, it is probably just what users used to SQL expect (at least for me it >>> comes quite naturally). >>> >> I wasn't convinced by this argument back in October and I still aren't. >> Firstly, it shouldn't be what users of SQL will expect. I think you're >> generalising from one case and it's not representative. Nobody writing >> an SQL query directly will ever be writing "foo=NULL" in their queries. >> > > Of course not. That's what I mean (it's not a real code line): > > # find all siblings of this object > siblings_qset = models.Something.objects.filter(parent__exact=obj.parent_id) > > I've got better use cases that include building complicated filters, but > they are hard to explain without background. > > >> It's just a waste of keystrokes and processor time. It's guaranteed to >> never match anything but will often disguise a bug, since a quick >> eye-scan might not notice the "=" since we often assume a seasoned SQL >> coder isn't going to make that blunder and just notice the column name >> and the NULL check. So I don't buy the argument that an SQL coder is >> going to expect such a construct to ever be created. I certainly don't >> and I've written more than a few thousand lines of SQL in my years >> (again, it's one example, but don't focus on that; look at the logic of >> why this isn't going to be a construct that is ever used). >> >> Secondly, we're talking about the mapping from a Python construct to an >> SQL construct, something which doesn't have a natural mapping, so all >> constructs are going to be slightly artificial. >> >> On a semantic level "foo=None" (since we can't write "foo is None" in a >> function call) can be fairly easily understood as "foo has the special >> value None", since it's entirely analogous to "foo=6". At the SQL level, >> "foo is NULL" means "foo has the special value NULL". Mapping None to >> NULL isn't a huge leap in the trip from Python to SQL, so the whole >> process shouldn't be counter-intuitive (yes, there will be exceptions, >> but there always are). Remember that we're writing the ORM for Python >> coders, so using natural-looking Python behaviour is important. >> > > Well, there are two ways to interprete this particular lookup. > > The ORM is an ORM for relational database users, and you won't get far if > you have no idea what NULL is. Django does not abstract away the relational > database. If you don't know what a relational database is, you probably > better off using Zope ... > > I consider your point of view as valid as mine. And it was brought up in the > original discussion, too. > > >>> I guess you cannot make both groups completely happy, but your proposed >>> change is also backwards incompatible and has been explicitly decided >>> different before. Can you please reconsider? >>> >> I'm not convinced about the huge negative impact of the change, either. >> There was *one* use-case touted (by Deryck Hodge) in the original >> thread. It has limited applicability. It's only for disjunctive ("or") >> filters, since a sequence of conjunctions like >> filter(foo=None).filter(bar=6) is just a complicated way of writing the >> empty list unless you're using, say, PostgreSQL 7.1 or something else >> that doesn't handle NULLs correctly. >> >> I didn't like this change when it went in and I wouldn't be unhappy to >> see it fixed. As usual, though, it's not the complete end of the world >> if it doesn't change, just makes it a less beautiful place. >> > > Russell has based the decision on uses within the django tests that appear > to come naturally for him, too, so I don't share your opinion that this > change wouldn't affect anything. Also, it questions your opinion that the > current semantics are pointless: > > http://groups.google.com/group/django-developers/msg/b3f7e4cf6f9ffd98, > Russell Keith-Magee wrote: > > --- quoting Russell --- > Hence the documentation to that effect. No, it isn't a particularly > useful expression, but it does have at least one use case (discussed > below). > > I wasn't aware of the Oracle issue; but that strikes me as a problem > that should be fixed at the backend level, rather than as a reason to > exclude a feature. > > [On 10/14/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:] > >> So doesn't this defeat the purpose of the exercise now? Using >> > > __exact=None is now a synonym for "please don't ever return anything > > (except on Oracle)" whereas I thought your were shooting for "where this > > field is NULL". > > The use case that started this for me is in the regression test - a > related manager for an unsaved object. In this case, 'don't ever > return anything' is _exactly_ the right response, because nothing can > be related to the unsaved object. > > Mapping __exact=None to _isnull=True will give effectively the same > results, but via a 'return everything with a primary key value of NULL > - which is nothing' interpretation of the problem. > > However, as you noted earlier, this second approach is redundant given > the existence of _isnull. It also hides a path to the expression of > some valid (albiet edge case) SQL. The interpretation suggested by > Michael struck me as a good way to avoid the redundancy, fix the bug I > found, expose a small corner of legal SQL statements, and ultimately > required less code to implement. > > The biggest problem I could see was the potential for '__exact=None > doesn't mean what you think it does' amongst newcomers. For me, the > best solution to this problem is documentation. > --- end of quote --- > > > So (really) long, > > Michael > > > -- Ned Batchelder, http://nedbatchelder.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
