Re: Magic-removal status (WAS: Re: Proposal: Use of opts as well as kwargs in DB queries)

Robert Wittams wrote: > > The other issue is the FileField and ManyToManyField things I sent a > message about before. I will attempt to do these tonight. > Hm, I didn't really manage to do these in a satisfactory way yet. Someone else can give it a go, or I'll do it when I get back. Bye for n

Re: Magic-removal status (WAS: Re: Proposal: Use of opts as well as kwargs in DB queries)

Adrian Holovaty wrote: > Here's the current status: Robert is going to finish up manipulator > tweaks by the end of the week, when he leaves for a week-long > vacation. So I'm off tomorrow. The current status afaik is: Core fields removal. core=true and related things now give a validation error

Magic-removal status (WAS: Re: Proposal: Use of opts as well as kwargs in DB queries)

On 12/29/05, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > I have read that page - I didn't realize that it was actually > happening, though. The implication at the end of the wiki entry seemed > to be that there was still some discussion needed as to whether it was > a good idea. I'd say we'r

Re: Proposal: Use of opts as well as kwargs in DB queries

On 12/29/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > BTW, > the query syntax is changing quite a bit -- see > http://code.djangoproject.com/wiki/DescriptorFields -- so you might > have a look at that if you haven't already. I have read that page - I didn't realize that it was actually happe

Re: Proposal: Use of opts as well as kwargs in DB queries

On 12/29/05, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > Following the overwhelming response (accompanied by the sound of > crickets chirping in the distance :-), I've worked up a patch that > implements this change. It's logged as Ticket #1133. > > Given that all the DB stuff is about to cha

Re: Proposal: Use of opts as well as kwargs in DB queries

Hi all, On 12/28/05, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > Given that the (relatively) new Q() syntax for query construction > doesn't require the top level kwarg, doesn't it make sense to allow > unnamed *opts parameters as well as **kwargs in query functions? Following the overwhel

Proposal: Use of opts as well as kwargs in DB queries

Hi, At present, all Django DB query functions accept and use kwargs to construct queries. All top level kwargs queries are then AND'ed together. Given that the (relatively) new Q() syntax for query construction doesn't require the top level kwarg, doesn't it make sense to allow unnamed *opts par