Nested Namespaces don't Reverse

I have a simple example that is giving me some trouble. When a project has multiple instances of an application referenced by patterns nested more than one level deep it seems impossible to look up using reverse () with only two path components. No matter what the current_app argument is set to.

ANNOUNCE: Django 1.2 alpha 1 released

The first alpha preview package for Django 1.2 is now available. * Release notes: http://docs.djangoproject.com/en/dev/releases/1.2-alpha-1/ * Download instructions: http://www.djangoproject.com/download/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You

Re: Design and code review requested for Django string signing / signed cookies

On Jan 5, 2:33 pm, Luke Plant wrote: > On Tuesday 05 January 2010 16:53:17 Elias Torres wrote: > > > Simon, > > > I'm not a security expert by any means, but I really the fact that > > you're making use of HMACs in your design. I will ask a good friend > > (Ben Adida) who's

Re: Final call for feedback: Multi-db

On Wed, Jan 6, 2010 at 12:42 AM, Brett Hoerner wrote: > On Dec 22 2009, 4:27 pm, Russell Keith-Magee > wrote: >> I'll need to cogitate on this over my Christmas pudding :-) > > Did you come to any conclusions, or need any more feedback on the read-

Re: Possible contrib.humanize addition

Thanks for your reply - I'll have a look into how this would work with other languages and get back to you if it looks like it would work easily with other languages. Regards, Harry On Jan 6, 3:45 am, Russell Keith-Magee wrote: > On Wed, Jan 6, 2010 at 5:24 AM, harrym

Re: Possible contrib.humanize addition

On Wed, Jan 6, 2010 at 5:24 AM, harrym wrote: > I'm working a templatetag that determines whether to use 'a' or 'an' > in front of English words. My particular use case for this is in a > tumblelog app I'm developing - many different types of entry may be > added (link,

Re: Design and code review requested for Django string signing / signed cookies

oops.. I mean really *like*. Thanks. On Jan 5, 12:09 pm, Karen Tracey wrote: > On Tue, Jan 5, 2010 at 11:53 AM, Elias Torres wrote: > > > I'm not a security expert by any means, but I really the fact that > > you're making use of HMACs in your design. > >

Re: Design and code review requested for Django string signing / signed cookies

On Tuesday 05 January 2010 16:53:17 Elias Torres wrote: > Simon, > > I'm not a security expert by any means, but I really the fact that > you're making use of HMACs in your design. I will ask a good friend > (Ben Adida) who's really an expert on the subject to see if your > paranoia on adding a

[JOB] Python/Django Web Developer, NYC | 75-100k

This is a full time, on-site, salaried position is located in New York City paying $75,000-$100,000. No telecommuting allowed. US Citizens, Green Card holders, EAD or CAN only please. Thank you. My New York City client is an international comparative shopping search engine that accumulates its

Re: Design and code review requested for Django string signing / signed cookies

On Tue, Jan 5, 2010 at 11:53 AM, Elias Torres wrote: > > I'm not a security expert by any means, but I really the fact that > you're making use of HMACs in your design. > There seems to be a key word missing here: really the fact... (One might guess based on the rest of the

Re: Design and code review requested for Django string signing / signed cookies

Simon, I'm not a security expert by any means, but I really the fact that you're making use of HMACs in your design. I will ask a good friend (Ben Adida) who's really an expert on the subject to see if your paranoia on adding a salt and hashing the key helps you in any way. My intuition says if

Re: idea for using RequestContext by default

On Tue, Jan 5, 2010 at 9:38 AM, Russell Keith-Magee wrote: > To clarify your position Jacob - are you advocating that > shortcuts.render() should return a TemplateReponse? Or are you > suggesting that we add a TemplateResponse *and* a shortcut.render() > that is an analog

Re: idea for using RequestContext by default

On Tue, Jan 5, 2010 at 11:00 PM, Jacob Kaplan-Moss wrote: > On Tue, Jan 5, 2010 at 7:41 AM, Russell Keith-Magee > wrote: >> I haven't taken the temperature of anyone else in the core, but you >> can take it as read that Simon and myself are both +1.

Re: idea for using RequestContext by default

On 5 Jan 2010, at 15:00, Jacob Kaplan-Moss wrote: > On Tue, Jan 5, 2010 at 7:41 AM, Russell Keith-Magee > wrote: >> I haven't taken the temperature of anyone else in the core, but you >> can take it as read that Simon and myself are both +1. The sprint >> this >>

Re: idea for using RequestContext by default

On Tue, Jan 5, 2010 at 7:41 AM, Russell Keith-Magee wrote: > I haven't taken the temperature of anyone else in the core, but you > can take it as read that Simon and myself are both +1. The sprint this > weekend would be a great opportunity to advocate for inclusion of >

Re: idea for using RequestContext by default

Russell Keith-Magee wrote: > Certainly - and Simon made exactly this proposal during the review of > the CSRF work. Simon even provided a sample implementation: > > http://groups.google.com/group/django-developers/msg/b1b3f8854b9ae2b1 Thanks! I keep missing nice things on django-dev@ due to many

Re: idea for using RequestContext by default

On Tue, Jan 5, 2010 at 9:23 PM, Ivan Sagalaev wrote: > Russell Keith-Magee wrote: >> I'm in complete agreement with Simon on this point. I fail to see the >> benefit of decorators in this context. > > I can see one valid point that "render_to" guys have. Which is, >

Re: idea for using RequestContext by default

Russell Keith-Magee wrote: > I'm in complete agreement with Simon on this point. I fail to see the > benefit of decorators in this context. I can see one valid point that "render_to" guys have. Which is, incidentally, has nothing to do with the decorator syntax. An HttpResponse with an opaque

Re: idea for using RequestContext by default

Hi Davor, On Tue, Jan 5, 2010 at 5:06 PM, rebus_ wrote: > Hi, > > This is the "natural" sequence of doing things anyway, i don't see why > would you shuffle it around. > > 1. process stuff into variables > 2. add said variables to a ContextRequest > 3. send said

Re: idea for using RequestContext by default

Hi, This is the "natural" sequence of doing things anyway, i don't see why would you shuffle it around. 1. process stuff into variables 2. add said variables to a ContextRequest 3. send said ContextRequest to a template for rendering. In the example buttman gave in his link [1] you could say