Re: Finalizing descriptor implementation

Russell Keith-Magee wrote: >1) What should be the behaviour of __set__ for descriptors where > multiple values are allowed (ForeignKey, ManyToManyField)? > Known Objections: > Kieren Holland suggested that Article.reporter_set = [r1,r2] implies > that reporter_set is an ordered collection, becau

Re: Proposal: Regular Expression Field Lookups

On 3/6/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > On Mar 4, 2006, at 3:36 PM, Tom Tobin wrote: > > Furthermore, it implements a slightly > > backwards-incompatible change with regards to the admin interface: > > regular expression searches can be performed by placing the search > > phrase

Re: Proposal: Regular Expression Field Lookups

On Mar 6, 2006, at 6:40 PM, Ian Holsman wrote: > but this patch isn't just for the admin interface, it would allow any > application to use a regex easily. > as for the inconsistencies.. Ah, look like I wasn't clear enough: I'm -1 to allowing regex access *in the admin interface*; the rest of

Re: Proposal: Regular Expression Field Lookups

On 3/7/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > On Mar 4, 2006, at 3:36 PM, Tom Tobin wrote: > > Furthermore, it implements a slightly > > backwards-incompatible change with regards to the admin interface: > > regular expression searches can be performed by placing the search > > phras

Re: Proposal: Move all auth code to django.contrib.auth

On Mar 6, 2006, at 6:18 PM, Joseph Kocherhans wrote: > Authentication pieces are currently spread out through a bunch of > different modules. I propose that they all move to > django.contrib.auth. +1 -- sounds great. Jacob --~--~-~--~~~---~--~~ You received this

Re: Proposal: Regular Expression Field Lookups

On Mar 4, 2006, at 3:36 PM, Tom Tobin wrote: > Furthermore, it implements a slightly > backwards-incompatible change with regards to the admin interface: > regular expression searches can be performed by placing the search > phrase between slashes (e.g., /like this/). I'm -1 on this; the admin in

Re: Validation-aware models revisited

On Mar 5, 2006, at 6:31 AM, Malcolm Tredinnick wrote: > Was there any discussion at PyCon about validation-aware models? Yeah, we talked about this quite a bit, but never actually got to a final solution. Adrian's actually on vacation right now -- in Hawaii, the lucky bastard -- but he told

Re: Finalizing descriptor implementation

Howdy -- Russ, I can't thank you enough for your work on this stuff. Half these edge cases I wouldn't have even thought of 'til they bit me in the ass -- I really appreciate it :) Now, onto your questions: > I propose that: 'Article.reporter_set = X' be allowed, where X is any > iterable.

Proposal: Move all auth code to django.contrib.auth

Authentication pieces are currently spread out through a bunch of different modules. I propose that they all move to django.contrib.auth. I think this will make it easier to understand where the essential pieces are. Here are the specific changes: django.parts.auth.formfields.AuthenticationForm -

Re: [Changeset] r2489 - django/branches/magic-removal/django/db/models

On Monday 06 March 2006 23:53, Luke Plant wrote: > Sorry about that, I've just committed an alternate solution that > should fix it. Can you check? I'm lying, here. jkocherhans beat me to it and I assumed that my commit succeeded. But it is fixed anyway. Luke -- "The number you have diale

Re: [Changeset] r2489 - django/branches/magic-removal/django/db/models

On Monday 06 March 2006 23:16, Ian Holsman wrote: > Hi Guys. > > this breaks my application. > I've got too 'apps' which don't have a models.py file (they are just > views/templatetags) > and I get the following error http://django.pastebin.com/587919 Sorry about that, I've just committed an alte

Re: [Changeset] r2489 - django/branches/magic-removal/django/db/models

Hi Guys. this breaks my application. I've got too 'apps' which don't have a models.py file (they are just views/templatetags) and I get the following error http://django.pastebin.com/587919 On 3/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Author: lukeplant > Date: 2006-03-06 13:32:49

RequestUserMiddleware changing to AutheticationMiddleware

A heads up to those tracking magic-removal. I've just committed a change that renames RequestUserMiddleware to AutheticationMiddleware. You will need to update your settings.py files accordingly. request.user has been abstracted out of the mod_python and wsgi handlers entirely. Now, if you attempt

Re: Latest MR Branch and "_user_source"

Kevin wrote: > The generic views use RequestContext (was DjangoContext) and that > requires request.user be set. RequestContext doesn't necessarily require request.user to be set. RequestContext just runs through all the TEMPLATE_CONTEXT_PROCESSORS, which includes django.core.context_processors.a

Re: Restarting the webserver under mod_python

Here's how I do it: It's different from how you guys are doing these now, but I think it's a good way of doing things. Best Regards, -jj On 3/5/06, Antonio Cavedoni <[EMAIL PROTECTED]> wrote: > Hello everyone, Shanno

Re: Latest MR Branch and "_user_source"

On 3/6/06, Kevin <[EMAIL PROTECTED]> wrote: > The generic views use RequestContext (was DjangoContext) and that > requires request.user be set. > > I'd be nice if that middleware dependency could be removed since my > site never needs authentication and so the extra middleware is > redundant. I'd

Re: Latest MR Branch and "_user_source"

I had this exact same problem when I switched the magic removal branch. The error manifested itself when I tried to access a url that uses the direct_to_template generic view. The generic views use RequestContext (was DjangoContext) and that requires request.user be set. I'd be nice if that mid

Re: Latest MR Branch and "_user_source"

ChaosKCW wrote: > As far as I know I dont access request.user. But I still got the error > which is why I asked about it being required. I do have session > middleware installed, so I am guessing that session middleware accesses > request.user then ? Someone correct me if I'm wrong. I don't thin

Re: Tutorial updates for magic removal

D'oh! - thanks guys ;) Cheers, Tone --~--~-~--~~~---~--~~ 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,

Re: Finalizing descriptor implementation

Hi! >1) What should be the behaviour of __set__ for descriptors where >multiple values are allowed (ForeignKey, ManyToManyField)? Allow assignement of any iterator. If people are confused by the fact that a list has an order and a set doesn't, they will be confused by the fact of sets themselves

Re: Finalizing descriptor implementation

On 3/6/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > 2) If a related attribute currently has a value of None, should the > > __get__ method return None, or raise a DoesNotExist if accessed? Does > > this behaviour change if the attribute is set null=True? > > I don't understand this, becau

Peter Ma wants to talk to you using Google Talk

I've been using Google Talk and thought you might like to try it out. We can use it to call each other for free over the internet. Here's an invitation to download Google Talk. Give it a try! --- Peter Ma wants to talk to you fo

Re: Tutorial updates for magic removal

On the Ticket. --~--~-~--~~~---~--~~ 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

Re: Latest MR Branch and "_user_source"

Hi As far as I know I dont access request.user. But I still got the error which is why I asked about it being required. I do have session middleware installed, so I am guessing that session middleware accesses request.user then ? Thanks, C --~--~-~--~~~---~--~---

Re: Finalizing descriptor implementation

> 2) If a related attribute currently has a value of None, should the > __get__ method return None, or raise a DoesNotExist if accessed? Does > this behaviour change if the attribute is set null=True? > > Personally, I am: > +1 returning None if null=True > +0 returning None if null=False > > 3)