On 12/3/07, Mike Scott <[EMAIL PROTECTED]> wrote:
> 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 suppose it depends on what you mean by "conforms"; if we wanted to
run with that, I'd ask why you can iterate directly over a QuerySet in
a for loop instead of doing something like, say
queryset = MyModel.objects.all()
for obj in queryset.iterate():
print obj
After all, iteration is implemented using a special Python feature
just the same as slicing, and it's not necessarily obvious that a
QuerySet is something you ought to be able to iterate over without
calling a special method.
> 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.
I'm very much against maintaining two separate ways to do the same
thing. And I'm very strongly in favor of using the "Pythonic" solution
as opposed to the "SQL" solution.
> 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:
That's the point, though, where it's important to know how Python's
slicing syntax is applied to custom classes, and to go look to see how
the slicing is implemented. We could do a better job of documenting
exactly what slicing does (since it translates into LIMIT/OFFSET in
the DB query), but that still doesn't strike me as an argument for
killing off what is, essentially, the standard Python syntax for this
sort of operation.
> 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.
After I wrote my second reply to Adrian, I decided to really go
all-out and just write a blog entry about this; my main beef is with
calling things "magic" when really they're just standard Python
features, but maybe it'll help shed some light on the larger
discussion:
http://www.b-list.org/weblog/2007/dec/03/magic/
--
"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
-~----------~----~----~----~------~----~------~--~---
