Re: Adding signing (and signed cookies) to Django core

On Fri, Sep 25, 2009 at 4:46 AM, Simon Willison wrote: > This isn't so bad, since we already have a precedent for this in > request.POST.get_list('foo'). request.COOKIES.get_signed(key) might be > OK. request.COOKIES.get_signed(key) makes the most sense to me since it's clear you are dealing wit

Re: Adding signing (and signed cookies) to Django core

On Fri, Sep 25, 2009 at 6:33 AM, Chris Beaven wrote: > > +1 on the concept of a signing module. > > On Sep 25, 7:48 am, Marty Alchin wrote: > >> The one downside to using get() directly, as opposed to an altogether >> new method, is that get() doesn't raise a KeyError when a value >> doesn't exi

Re: Django Transaction Integrity

I suppose that it's worth mentioning that any support for nested transactions will not be portable to different databases (particularly MySQL) and probably would need to be documented accordingly. Ian On Mon, May 17, 2010 at 7:50 PM, Piet Delport wrote: > Hi Russel, thanks for the response! > >

Re: Django Transaction Integrity

10 at 1:05 AM, Piet Delport wrote: > 2010/5/17 Ian Lewis : >> >> I suppose that it's worth mentioning that any support for nested >> transactions will not be portable to different databases (particularly >> MySQL) and probably would need to be documented accordingly.

Re: Django Transaction Integrity

ld be implemented for MySQL in lieu of nested transactions though. See: http://dev.mysql.com/doc/refman/5.0/en/implicit-commit.html 2010/5/18 Ian Lewis : > Am I missing something? Are we talking about doing some kind of > transaction management at the application level? If not then it's > w

Re: Django Transaction Integrity

> Yes: we're talking about Django's transaction management layer (that is, the > code in django.db.transaction), which controls how Python-level transaction > blocks map to SQL transactions. > > The original email and writeup has a full explanation. :) > Yes. What I was getting at is that django's

Re: Class based generic views in 1.3?

The example he provided isn't terribly good but you don't need an view instance per request (the example will work unless you start adding stuff to self or overwriting self.qs etc). Only shared state is stored at the class level and view customization is done at the class instance level as well. Th

Re: Logging in Django

On Sun, Jun 20, 2010 at 12:19 PM, Russell Keith-Magee wrote: > On Sun, Jun 20, 2010 at 4:59 AM, David North > wrote: >> On 28/05/2010 16:48, Russell Keith-Magee wrote: >> * They have to be sprinkled all over the place (or in a lot of places, at >> least) rather than the logging aspect of the appl

Re: auth.User refactor: reboot

Hi, Eric Florenzano and I actually had a discussion about this at PyCon. My company does Django development and simply doesn't use the Django auth app because it tries to do authentication and authorization in one app and the User models are just to inflexible. Many projects didn't need or want us

Re: auth.User refactor: reboot

Hi, On Sun, Mar 18, 2012 at 9:41 AM, Russell Keith-Magee wrote: >> 1. Django shouldn't decide what fields go on the user model. The app >> provides an abstract base class which developers subclass to add the >> appropriate fields they need. > > +1 THX >> 2. Django shouldn't decide the type of t

Re: auth.User refactor: reboot

Hi, On Mon, Mar 19, 2012 at 1:00 AM, Joe Tennies wrote: > A feature I would love to see is the ability to support multiple forms of > authentication for a single user account. (One account to many credentials.) You can do this already with Django auth by specifying multiple backends to the AUTHE

Re: auth.User refactor: reboot

Hi, On Mon, Mar 19, 2012 at 9:27 PM, Russell Keith-Magee wrote: > On 18/03/2012, at 12:19 PM, Ian Lewis wrote: >> I meant one that was a completely separate concrete base model. The >> current auth forces you to take along with you all the fields on the >> User model. >

Re: auth.User refactor: reboot

Hi, On Tue, Mar 20, 2012 at 2:05 PM, Russell Keith-Magee wrote: > On 20/03/2012, at 8:00 AM, Ian Lewis wrote: >> Though we have had other times where there were multiple types of >> users in a single project. i.e. users that signed up via some >> affiliate program. user

Re: auth.User refactor: reboot

Hi, On Tue, Mar 20, 2012 at 10:37 PM, Russell Keith-Magee wrote: > On 20/03/2012, at 8:38 PM, Tom Evans wrote: >> User profiles solve the issue of app specific data in a better way >> than specifying additional fields on a a base user object, >> particularly as the number of apps increases. Whils

Re: auth.User refactor: reboot

Hi On Fri, Mar 23, 2012 at 8:41 PM, Hanne Moa wrote: > On 21 March 2012 09:40, Ian Lewis wrote: > > To my mind it's the least important of the tenets of the design of > > newauth, but I personally would like to use it at least for admin > > users and normal site users

Re: auth.user refactor: the profile aproach

Hi. iPhoneから送信 On 2012/04/04, at 5:34, Adrian Holovaty wrote: > First, some background: I haven't used the built-in User module in > several years. I always write my own User model from scratch -- it's > so nice and clean. Want a twitter_username field? Just add it. No need > to add a convolute

Re: auth.user refactor: the profile aproach

Hi iPhoneから送信 On 2012/04/06, at 0:29, "Daniel Sokolowski" wrote: > The more I think about it the more it makes sense to me to have a base User > model just a stub with a user Identifier and password field. Sure one could > argue for less ore more fields, but I think the idea > is to pick some

Re: auth.user refactor: the profile aproach

Hi, I'm not getting why you *have* to add fields to the User model to store data pertaining to the user. There is nothing in the proposal for pluggable user models that says you can never have a seperate model with a foreign key to the user model. It just means that you can define your user model

Re: auth.user refactor: the profile aproach

On Tue, Apr 10, 2012 at 11:58 PM, Tom Evans wrote: > On Tue, Apr 10, 2012 at 3:13 PM, Ian Lewis wrote: > > Hi, > > > > I'm not getting why you *have* to add fields to the User model to store > data > > pertaining to the user. There is nothing in the proposal f

Re: ModelForms and the Rails input handling vulnerability

Hi, I'm with Carl in supporting option 3. I think have always thought that ModelForms were unsafe and requiring the fields option would go a long way to making them safer. I don't think I'm stupid and I've personally run into this issue. I have almost *NEVER* run into a case where I want all field

Re: #12012 Logging: request for comments

Hi, On Tue, Sep 28, 2010 at 9:19 AM, Nick Phillips wrote: > I'm worried by the use of "warning" for all 4xx statuses. I think it > still makes sense to use the "original" syslog level definitions[*] as a > guide, and on there I'd suggest that some 4xx statuses would merit > "Info", some "Notice",

Re: #12012 Logging: request for comments

27;t see how a 302 because someone posted something is any less debug > thann the 200 to serve thhhe get. > > Bikesheddinngly yours, > Alex > > On Sep 28, 2010 11:45 AM, "Ian Lewis" wrote: > > Hi, > > On Tue, Sep 28, 2010 at 9:19 AM, Nick Phillips > wrote:

Re: #6735 -- Class based generic views: call for comment

On Sat, Oct 2, 2010 at 12:20 AM, Alex Gaynor wrote: > Not really.  The big win from a class-based view is not being able to > store state, you can do that with local variables, it's being able to > override parts of the behavior without needing to rewrite the entire > view, or add 101 parameters.

Re: #6735 -- Class based generic views: call for comment

On Sat, Oct 2, 2010 at 11:37 AM, David P. Novakovic wrote: > By this reasoning, when you add extra helper methods to your class, > which is the reason for OO views, you need to add/use the data those > methods will modify to the request object? That just doesn't make > sense to me at all. It remin

Re: #6735 -- Class based generic views: call for comment

On Sun, Oct 3, 2010 at 11:20 AM, Russell Keith-Magee wrote: >> The issue is not only the frequency of failure, but how explicit/clear >> it is. The failure here is so obscure and difficult to track down, it >> is likely to generate an outsize support burden. In contrast, raising >> an error on ass

Re: #6735 -- Class based generic views: call for comment

2010/10/3 Łukasz Rekucki : > On 3 October 2010 06:12, Ian Lewis wrote: >> Flask seems to do it the callable singleton way: >> >> http://flask.pocoo.org/docs/patterns/lazyloading/ >> > I never used Flask, so I might be missing something, but I don't see a >

Re: #6735 -- Class based generic views: call for comment

On Sun, Oct 3, 2010 at 8:02 PM, Russell Keith-Magee wrote: >> Other frameworks seem have View/Handler instances per request, such as >> appengine's webapp so there is some precedent for creating an instance >> per request. >> >> http://code.google.com/appengine/docs/python/gettingstarted/handlingf

Translating Django's documentation

Hi all, I am a member of the Japanese Django community which is maintaining a somewhat(read very) outdated version of the Django documentation here: http://djangoproject.jp/doc/ja/1.0/ I'm trying to kickstart a project to update the documentation and in lookin

Re: Translating Django's documentation

On Wed, Oct 13, 2010 at 11:32 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > On Wed, Oct 13, 2010 at 10:20 AM, Ian Lewis wrote: > > Hi all, > > I am a member of the Japanese Django community which is maintaining a > > somewhat(read very) outdated version

Re: Translating Django's documentation

On Wed, Oct 13, 2010 at 4:58 PM, Jannis Leidel wrote: > > > The current state-of-the-art is in the somewhat-badly-named > > "community_redux" branch on my Github account: > > http://github.com/jacobian/djangoproject.com/tree/community_redux, and > > I would *gladly* take input and/or patches into

Re: #6375 -- Class Based Views: Opinions on commit plan

On Fri, Oct 15, 2010 at 2:06 PM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > > > There is this crazy idea im my mind to mark CBVs API as > > "Beta" in 1.3 and put a big warning in the docs that it can change in > > backwards-incompatible was in 1.4. A precedence to this would be > > `d

Re: #6375 -- Class Based Views: Opinions on commit plan

On Sat, Oct 16, 2010 at 1:31 PM, Yo-Yo Ma wrote: > Łukasz Rekucki, > > Thanks for the reply. I wasn't being cynical when I said: > > > If the API for this feature was not so intrinsically > > obscure, it might be a more obvious choice to include it right away, > > What I meant was the design and

Re: contrib.staticfiles app concerns

On Thu, Oct 21, 2010 at 2:40 AM, Waldemar Kornewald wrote: > Today the staticfiles contrib app was committed to trunk. This got me > wondering: Wasn't there recently a discussion about how "contrib" is a > bad idea and all apps should either be in core or live as separate > projects? Is staticfile

Re: contrib.staticfiles app concerns

On Thu, Oct 21, 2010 at 12:25 PM, Jannis Leidel wrote: > Ian, > > > I thought about this too and had a long thread on Twitter with jezdez > about staticfiles. It occurred to me that adding more apps to contrib was > kind of a bad idea. I know "everyone" uses admin etc. but I was of the > understa