James, I'm think what I'm getting at more is not the fact that its "magical", maybe that is the wrong choice of word. But my opinion is more of the fact that it doesn't conform to the rest of the django database commands.
I do think you put it aptly in asking do we want to be more SQL-style or Python-style. Ultimately it boils down to people understanding the framework better, and keeping it as is may infact do that. I think it is something that needs to be considered quite carefully. Promoting slicing as the recommended way, but still allowing a limit() function in there to conform with the rest of the db api. Conformity, to a set standard (which in this case doesn't seem to exist - which is another reason I am +1 on the DEP idea), is better than doing it just cause you can. What the issue was (and the reason I bought this up) was that it was understood that the python functionality was executed after the method was, and therefor there was an understanding that it wouldn't make any difference: Models.objects.filter(date__gt=date_start)[:1] However, it did and it would have been clearer as: Model.objects.filter(date__gt=date_start).limit(1) Its something that has been solved by marking with a comment, however I'm firmly a fence sitter at this point, so I'm ready to be swung either way. But I don't think your comments so far have done so. Mike. On Dec 3, 2007 7:13 PM, James Bennett <[EMAIL PROTECTED]> wrote: > > On 12/2/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > Frankly, I have found the slicing syntax hard to understand and > > error-prone myself. I think one of the reasons it seems magic is that > > it's one of the *rare* cases in which we use a Python > > "magic-syntax-ism" (like operator overloading, for instance) in the > > framework, plus the fact that, what, *every* other piece of QuerySet > > functionality uses a method. It seems bolted on. > > > > I'd be +1 on adding a distinct limit() method, and keeping the legacy > > list method for masochists who actually enjoy coding in that way. > > And.. it's late and I'm possibly not thinking clearly, but I feel like > fleshing out what I've already said, because this is something I have > a strong opinion on. > > Let's step back from the case at hand and consider something else so > it'll be a bit more objective to look at. That means another "magic" > Python method, so I'll pick the __str__()/__unicode__() combo we do on > model classes. > > To someone who's not familiar with Python, the fact that defining > these methods will cause a complex object to -- in certain > circumstances -- "magically" become a string is undoubtedly confusing. > But the solution to that isn't to stop using them, it's to help people > become familiar with the conventions of Python programming; if we > switched to, say, defining 'toUnicodeString()' and 'toByteString()' on > models, a lot more people would be able to immediately pick up Django > and grok what's going on, but we'd be going against the grain of > Python, which provides __unicode__() and __str__() for these purposes > already, and we'd be confusing people who are familiar with Python and > who expect that "convert Object X to a string" is going to call > __unicode__() or __str__(). > > I don't think there's anybody here who'd advocate adding explicit > string-generating methods on models just for the sake of letting > people avoid the need to understand how Python works; we'd be working > against the language in a painful way, and in the long run it'd hurt a > lot more than it helped. > > Getting back to the issue at hand, slicing a QuerySet is the same > situation: a lot of people would undoubtedly grok things more quickly > if there were explicit "limit()", "offset()", etc. methods on > QuerySet, but Python already provides a standard language feature for > objects which want to emulate a sequence and allow users to retrieve > only a portion of the sequence, and defining our own separate set of > methods for this would be working against the language in a big way, > and we'd be doing it, essentially, so that people don't have to learn > how Python works. Which is a disservice to everyone who uses Django: > > 1. Experienced Python programmers would wonder why the hell we're not > just using the features Python provides for this use case. > 2. Inexperienced Python programmers would just get bitten the first > time they tried to slice some other sequence type and be right back in > the same boat they were in originally. > > And, ultimately, referring to a standard language feature as "magic" > does a large disservice both to Python and to people who are trying to > learn Django and Python: the slicing syntax, and the way it's > implemented, is no more or less "magical" than, say, a Java class > which implements standard interfaces out of java.util or java.lang. > > So if it's possible to have a negative vote which involves aleph > numbers or other such suitably infinite quantities, that's how I'd > vote on this change. > > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of > correct." > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
