Re: An addendum to the escaping proposals

2007-11-13 Thread Robert Coup
On 14/11/2007, Chris Green <[EMAIL PROTECTED]> wrote: > > > On Nov 10, 2007 8:58 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> > wrote: > > > Yeah, I'm not really sure what I mean, design-wise. I feel a little > > uncomfortable about requiring the csrf key all the time in form > > submissions, but I c

Re: Model post_save doesn't play well with Model.save overriding

2007-11-13 Thread Malcolm Tredinnick
On Tue, 2007-11-13 at 22:58 -0600, Gary Wilson wrote: [...] > I would think most use cases for overriding save() involve doing something > before or after the actual saving of the object. In other words, having a > pre_save() and post_save() means that few people would need to override save() >

Re: Model post_save doesn't play well with Model.save overriding

2007-11-13 Thread Gary Wilson
James Bennett wrote: > On 11/13/07, Gary Wilson <[EMAIL PROTECTED]> wrote: >> How about introducing pre_save and/or post_save methods. The signal firing >> happens in pre_save and post_save. You can override whatever you want - >> pre_save, save, or post_save depending on your needs. This would

Re: ModelForms

2007-11-13 Thread Russell Keith-Magee
On Nov 13, 2007 5:37 AM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > On 11/11/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > > > The problem I have with ModelForm is that it doesn't feel like it has > > any parallels with the existing class-based formdefinitions. ... > I see your poin

Re: Python history won't work in Django shell (maybe found bug?)

2007-11-13 Thread Collin Grady
Deryck Hodge said the following: > It's the variable that says whether or not the option --plain was > used. It determines whether the normal Python shell is used or > iPython. iPython is used if available unless --plain is set. Hmm, that sounds like a bug then, as this happens even when ipytho

Re: Python history won't work in Django shell (maybe found bug?)

2007-11-13 Thread Deryck Hodge
On Nov 13, 2007 3:48 PM, Todd O'Bryan <[EMAIL PROTECTED]> wrote: > if not use_plain: ># here's where it uses PYTHONSTARTUP and stuff > > Why the heck is that "if not use_plain" there? If I take it out, > Collin's lovely history script works, even in the Django shell. And I > can't figure out w

Python history won't work in Django shell (maybe found bug?)

2007-11-13 Thread Todd O'Bryan
I finally decided I wanted to get a history working in the Python shell, which I managed by using Collin Grady's script here: http://collingrady.com/2006/11/17/tab-complete-and-a-persistent-history-in-python/ Unfortunately, it wouldn't work in Django's shell launched by ./manage.py. I started

Re: Model post_save doesn't play well with Model.save overriding

2007-11-13 Thread James Bennett
On 11/13/07, Gary Wilson <[EMAIL PROTECTED]> wrote: > How about introducing pre_save and/or post_save methods. The signal firing > happens in pre_save and post_save. You can override whatever you want - > pre_save, save, or post_save depending on your needs. This would also allow > you to disab

Re: Model post_save doesn't play well with Model.save overriding

2007-11-13 Thread Gary Wilson
Jeremy Dunck wrote: > On Nov 13, 2007 10:02 AM, James Bennett <[EMAIL PROTECTED]> wrote: >> Personally, I'm comfortable with documenting the fact that if >> Model.save() is never called, the pre_save and post_save signals will >> never fire (same is true of overridden __init__() and the post_init

Re: Model post_save doesn't play well with Model.save overriding

2007-11-13 Thread Jeremy Dunck
On Nov 13, 2007 10:02 AM, James Bennett <[EMAIL PROTECTED]> wrote: > > On 11/12/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > Perhaps Model.save(raw=False) should become Model.save(raw=False, > > fire_signals=True), leaving it up to the overrider to decide the > > policy? > > Personally, I'm com

Re: Model post_save doesn't play well with Model.save overriding

2007-11-13 Thread James Bennett
On 11/12/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > Perhaps Model.save(raw=False) should become Model.save(raw=False, > fire_signals=True), leaving it up to the overrider to decide the > policy? Personally, I'm comfortable with documenting the fact that if Model.save() is never called, the pre

Re: Mod_python segfault after changeset 5990

2007-11-13 Thread Chase
Thanks, Graham. That would make sense. I'll update Apache's expat version later today and report back if it doesn't work. On Nov 12, 11:46 pm, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > Whoops. Looking at code now in Django, it doesn't actually import the > Python bindings for Subversion. > >

Re: An addendum to the escaping proposals

2007-11-13 Thread Chris Green
On Nov 10, 2007 8:58 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Yeah, I'm not really sure what I mean, design-wise. I feel a little > uncomfortable about requiring the csrf key all the time in form > submissions, but I can't pin down why yet. As a consequence of that, the > middleware do

m2m ordering compared with foreign key & edit_inline

2007-11-13 Thread patrickk
this is a proposal in order to add something like "order_by" to m2m- fields. with using an m2m-field, there“s no possibility to enter (or output) something with a different order than the one provided by the related model. with using a foreign key & edit_inline, it IS possible. so, one could say