On 10/14/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> Hey Russell,
>
> On Sat, 2006-10-14 at 10:54 +0800, Russell Keith-Magee wrote:
> > On 10/12/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> > >
> > > Russell Keith-Magee:
> > > > Sorry - I'm confused; Are you agreeing with the
On Sat, 2006-10-14 at 03:27 +, afarnham wrote:
> Ok, so I looked at the SQL and it is a huge statement. Once I work out
> what it is doing I may post it here. However, I may just go with a
> straight sql query here and bypass the ORM until these new changes are
> implemented. Any idea of a
Ok, so I looked at the SQL and it is a huge statement. Once I work out
what it is doing I may post it here. However, I may just go with a
straight sql query here and bypass the ORM until these new changes are
implemented. Any idea of a time frame on when those will be up for
testing? I will be
Hi all,
What's the best way to deal with wiki/trac spam? There are a number of
pages out there (i.e.
http://code.djangoproject.com/wiki/ManipulatorScript ) which have some
rather, uh, non-django-like attachments to them, but I can't see any
way to remove them (I guess only admins have attachment
Hey Russell,
On Sat, 2006-10-14 at 10:54 +0800, Russell Keith-Magee wrote:
> On 10/12/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> >
> > Russell Keith-Magee:
> > > Sorry - I'm confused; Are you agreeing with the proposed change, or
> > > saying it contradicts your expectations? (I think you
On 10/12/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
>
> Russell Keith-Magee:
> > Sorry - I'm confused; Are you agreeing with the proposed change, or
> > saying it contradicts your expectations? (I think you are agreeing - I
> > just want to make sure)
>
> My highest preference is to make
On 10/13/06, Ned Batchelder <[EMAIL PROTECTED]> wrote:
> Only a security hole in the sense that a template author could put the DB
> password onto the page (for example) if they were stupid or malicious,
> right?
As I see it, the problem is twofold:
1. It's hard to say definitively which
Only a security hole in the sense that a template author could put the
DB password onto the page (for example) if they were stupid or
malicious, right? I understand the desire to "protect" template
authors from the full power of Python etc, but we don't believe they
are untrusted, or do we?
On 10/13/06, Ned Batchelder <[EMAIL PROTECTED]> wrote:
> In my own context processor, I added 'settings' as the entire settings
> module. Then I can get settings.WHATEVER in the templates. This solved our
> problem of dribbling in individual settings as we needed them. Any feelings
> about
In my own context processor, I added 'settings' as the entire settings
module. Then I can get settings.WHATEVER in the templates. This
solved our problem of dribbling in individual settings as we needed
them. Any feelings about doing that in a standard context? Then there
is no slippery
On 10/13/06, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On 10/13/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> > I'm adding it locally, but was wondering if you'd like a patch for one
> > either to core or contrib?
>
> It came up in ticket 2532, and Adrian vetoed it on the grounds that
> adding
Also, this is the most recent thread about this:
http://groups.google.com/group/django-developers/browse_thread/thread/11b9a6f2b18f7daf/02cb8b3974f0a329?lnk=st=context+processor+settings=1#02cb8b3974f0a329
You can probably find much more threads regarding this.
--Ahmad
On 10/13/06, James
Hi all,
I am having trouble with a Q object look up in one of my apps. When I
execute the following:
Tag.objects.filter(Q(card__owner = u)|Q(usercardmeta__user = u))
an empty queryset is returned. The filtered QuerySet should be
returning this list:
[, , , ]
After stepping through and
On 10/13/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> I'm adding it locally, but was wondering if you'd like a patch for one
> either to core or contrib?
It came up in ticket 2532, and Adrian vetoed it on the grounds that
adding context processors for some settings could be a slippery slope
Adrian Holovaty wrote:
> On 10/13/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
>> Max Derkachev wrote:
>>> There were a lot of words about unicodification of Django, but things
>>> has not been moved a bit further.
>> Or at least it would be nice to hear from someone of the core team why
>> it
On 10/13/06, Jay Parlar <[EMAIL PROTECTED]> wrote:
> I know it's off-topic, but do you have any thoughts as to which
> branch?
Based on my sporadic glances, I'd agree with you that row-level perms
and multi-db both look like good candidates to be finalized and
merged.
--
"May the forces of
On 10/14/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Hey there,
>
> I'm very interested in getting this done, but we've got quite a few
> branches open at the moment. I think we should focus on merging at
> least one of these branches before opening another one, for the sake
> of everybody's
On 10/13/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Max Derkachev wrote:
> > There were a lot of words about unicodification of Django, but things
> > has not been moved a bit further.
>
> Or at least it would be nice to hear from someone of the core team why
> it can't be done (either right
Max Derkachev wrote:
> There were a lot of words about unicodification of Django, but things
> has not been moved a bit further.
Or at least it would be nice to hear from someone of the core team why
it can't be done (either right now or at all). I remember Jacob (I
think) has said once along
There were a lot of words about unicodification of Django, but things
has not been moved a bit further.
The beginning is at
http://groups.google.com/group/django-developers/browse_frm/thread/bad8f2c4628646dc
Regards,
Max
--~--~-~--~~~---~--~~
You received this
On 9/19/06, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On 9/19/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> > Of
> > course 0.90 is easier to get to, but if more developers are coding on
> > 0.91, then maybe I'll try to catch that.
>
> Well, if you can point me at bugs that need to be fixed in
21 matches
Mail list logo
