newforms NullBooleanField / BooleanField
The current behaviour of BooleanField kind of negates the need for NullBooleanField. Contrary to the docs (and I'm pretty sure there's a ticket for it) a BooleanField(required=True) doesn't actually fail validation if a widget. Personally, I like this behaviour better. Would we be losing any functionality if we just had a BooleanField that behaved as NullBooleanField does now? A side note, while I'm looking at the code I see that the clean method of BooleanField is a bit ugly. It'd be better to handle that if value == 'False' as a custom hidden widget. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [GSoC] Aggregate Support to the ORM
On Thu, Apr 24, 2008 at 10:14 PM, Nicolas Lara <[EMAIL PROTECTED]> wrote: > On the ıssue of returnıng model objects ınstead of values > (dıctıonarıes): I belıeve the problem wıth that ıs ınconsıstency, > sınce when usıng values to restrıct the elements that are grouped > together you cannot retrıeve an object. I am -0 on retrıevıng the > objects because ıt becomes complıated for the users, but wouldn't > opose much because values ıs specıfıed whenever a valuesQuerySet would > be returned. I'm not sure why you see this as being complicated for users: >>> authors = Author.objects.annotate(book__sum='books_published') >>> for a in authors: ...print a.name,'has published',a.books_published,'books.' There is no problem making each a in authors an actual Author object; the only difference is that each author is annotated. Sure, this means that the author intances have attributes that aren't part of the original definition of Author, but this is perfectly consistent with Python - you can associate arbitrary attributes with any object instances. If a values() clause is involved in a query, then it makes sense that what gets returned should be a value list rather than an object - but that's perfectly consistent with the behaviour of values() currently. However, in the simple case - where you are grouping by full object instances - I don't see why we shouldn't return object instances. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: SVN Milestones
On Thu, Apr 24, 2008 at 8:19 PM, James Bennett <[EMAIL PROTECTED]> wrote: > * Marty's file backend work needs to land, because that drastically > improves both the ease of file handling in general and the ability > to use popular storage solutions like Amazon S3. I know you said your list isn't necessarily exhaustive, but I thought I should pass along a conversation Jacob and I had not too long ago. He'd like to get Mike Axiak's work on #2070 merged prior to my filestorage patch, since it's a bit easier to modify mine to work with his than the other way around. The fix for #2070 looks like it may have slight backwards-incompatibilities on its own, so it should probably be considered part of the 1.0 list anyway, but it's definitely a prerequisite for mine to go in, and since mine's on the list... Of course, you guys with the commit bit can hash it out amongst yourselves as to how you want to do it, I'm fine with it either way. I just wanted to make sure I made that conversation known, since I don't think it got passed along to the rest of the crew. -Gul --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: SVN Milestones
On Wed, Apr 23, 2008 at 5:58 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I'll make some time to do a pass through the VersionOneFeatures list and > rationalise things a bit. We can start pulling together a list of > tickets that are absolute blockers, too (I gather James already had some > of that stuff written down somewhere). The trick there is keeping the > list somewhat managed and not suffering form everybody adding pet > features. It's something the release manager should probably own. I do have a list. I've been wary of publishing it because this sort of thing inevitably turns into a festival of people posting things that are important to *them* but not necessarily important to Django as a whole, and assuming that a refusal to put them on a "1.0 feature list" represents the utter failure of Django as a project. So. Keep three things in mind as you read this: 1. This is not a comprehensive list of every single thing that'll happen before 1.0; this is merely a list of the most important things that need to happen before I'd feel comfortable calling anything "Django 1.0". 2. My criteria for this list involve a combination of things that are huge and universally agreed to be important; things that -- though they may be minor or isolated -- make it noticeably easier to use Django in a common situation; and things that, while less important, involve backwards-incompatible changes and so need to happen before we slap a seal of compatibility on 1.0. 3. Unless you have a commit bit or I'd recognize your name from your contributions to Django, don't take this as an invitation to pitch your pet feature. I'm not trying to be mean here, but there are lots of things that simply aren't requirements -- for the project as a whole -- to get to 1.0, and which can sensibly be dealt with, in incremental fashion, at a later time. As such, I naturally pay a lot more attention to people who've demonstrated their understanding of the big picture. So here goes. First up, the big things: * Queryset-refactor * Newforms-admin * Model-level validation * Anything in Django still using oldforms -> uses newforms These just flat-out have to happen, and represent major work. Fortunately, there are already people doing the work and I believe at least three of the four are getting really close. Then there are things which, while more self-contained, contribute significant improvements in common use cases, and which should happen before 1.0. If you're looking for something to work on and you know Django's codebase, this would be the list you want to look at. * Marty's file backend work needs to land, because that drastically improves both the ease of file handling in general and the ability to use popular storage solutions like Amazon S3. * The refactoring of Django's dispatcher. Jacob and, I believe, Jeremy have been working on this, and it's key because right now signals are incredibly useful but dog-ass slow. * WSGI fixes, particularly for SCRIPT_NAME. Yeah, there's a common pattern people use to work around it, but we should knock this out before 1.0; we already solved the problem of building a full URL for relative redirects, so we should be able to solve this too. * The template tag loading mechanism needs to get fixed; it's the last bit of arguable "magic" in Django, and the number of times now that I've seen people angrily trying to work out why we look in "django.templatetags" indicates that it's causing headaches. * Reverse URL resolution needs some love, because right now there are all kinds of not-too-complex regular expressions that it'll choke on. And since reverse resolution is one of the keys to portable, reusable code, we need to get that cleaned up. * The way django.template.Variable does resolution needs to take filters into account, so that tags which use it can be passed variables with filter expressions and work properly. Then there are some backwards-incompatible things which, while not as big, need to happen. These are going to need an experienced person banging out the design and then coding it up: * The oft-proposed INSTALLED_APPS refactoring needs to happen, so that things like re-using an app multiple times in the same Django instance will be easy and the hackiness of app_label will go away. * The mechanism for specifying and ordering middleware needs to be reworked, so that some of the nastier situations people can get into with figuring out what order to put their middleware in (and some situations where there's simply no possible ordering that works) will go away. And that's my list. Twelve things which, for one reason or another, need to happen before we roll a 1.0 release. Again, that doesn't mean we'll ignore all other work before 1.0, just that these are the really important things that have to happen. And as a pre-emptive note because someone will notice and point it out:
Re: Model Inheritance in qsrf and User?
On Wed, Apr 23, 2008 at 11:16 PM, Rob Hudson <[EMAIL PROTECTED]> wrote: > Now that queryset-refactor has implemented model inheritance (and will > soon be in trunk), will the recommended way to tie in new columns to > contrib.auth.models.User change? For example, if we want to add in > profile information specific to our apps? Well, I personally have been saying for over a year that inheritance has never been and never will be the right way to do that, so I think y'all know what my answer is... -- "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 -~--~~~~--~~--~--~---
Re: [GSoC] Aggregate Support to the ORM
Sorry ıf thıs goes on the wrong thread. I am wrıttıng at the moment
from turkey, where google groups ıs blocked.
In short: I belıeve Malcom's reply says ıt all except for the fact
that the 'havıng' clause would be expressed wıth a fılter modıfıer.
The ORM would take care of puttıng the requested fılter ın a 'havıng'
clause or ın a 'where' clause...
On the ıssue of returnıng model objects ınstead of values
(dıctıonarıes): I belıeve the problem wıth that ıs ınconsıstency,
sınce when usıng values to restrıct the elements that are grouped
together you cannot retrıeve an object. I am -0 on retrıevıng the
objects because ıt becomes complıated for the users, but wouldn't
opose much because values ıs specıfıed whenever a valuesQuerySet would
be returned.
On Wed, Apr 23, 2008 at 5:54 PM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 2008-04-23 at 07:50 -0700, Eratothene wrote:
> > It looks that API lacks support for SQL HAVING clause, this one should
> > be distinct from filter, GROUP BY without HAVING is often useless.
> >
> > Consider adding it to api (something like
> > Model.objects.aggregate(height__sum).having(sex='M'))
> >
> > Also do not forget to add HAVING clause to .extra() method.
>
> You may wish to go back and read the earlier thread(s) about this on
> this group where this has been discussed before.
>
> One goal in the design here has been to avoid leaking lots of SQL into
> the API: "having" and "group by" crop up as a natural function in the
> use of aggregates, but they aren't necessarily needed in isolation. The
> idea is not to rewrite SQL in Python. Rather, we want to provide certain
> pieces of functionality -- in this case, aggregations support -- that is
> mapped to SQL. So the SQL will use "having" and "group by" but they
> don't to be exposed at the Python level.
>
> Regards,
> Malcolm
>
> --
> Save the whales. Collect the whole set.
> http://www.pointy-stick.com/blog/
>
>
>
>
> >
>
--
Nicolas Lara
Linux user #380134
Public key id: 0x152e7713 at http://keyserver.noreply.org/
# Anti-Spam e-mail addresses:
python -c "print '@'.join(['nicolaslara', '.'.join([x for x in
reversed( 'com|gmail'.split('|') )])])"
python -c "print '@'.join(['nicolas', '.'.join([x for x in reversed(
've|usb|labf|ac'.split('|') )])])"
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
