Re: An issue with ticket system

On Fri, Sep 18, 2009 at 9:48 PM, Alex Gaynor wrote: > > On Fri, Sep 18, 2009 at 6:44 PM, Joshua Russo > wrote: > > I just tried to update a patch on a ticket that I had created but the > file I > > uploaded isn't displaying. It shows in the list

Re: An issue with ticket system

On Fri, Sep 18, 2009 at 6:44 PM, Joshua Russo wrote: > I just tried to update a patch on a ticket that I had created but the file I > uploaded isn't displaying. It shows in the list and with the correct file > size but when I try to view the file it's empty. I've upload

An issue with ticket system

I just tried to update a patch on a ticket that I had created but the file I uploaded isn't displaying. It shows in the list and with the correct file size but when I try to view the file it's empty. I've upload quite a few patches previously so I'm pretty sure it's not my process.

Re: CSRF proposal and patch ready for review

On Sep 18, 12:09 am, Luke Plant wrote: > OK, here is my response.  I hope this doesn't turn into a personal my-code-vs- > your-code match (especially as most of "my code" is really other people's code > and ideas :-) but I want to make sure we do this right, as it

Re: CSRF proposal and patch ready for review

On Sep 17, 3:42 pm, Simon Willison wrote: > All good points - the change in function signature naturally fell out > of the CSRF work (since the form needs access to the request object in > both cases) but you've convinced me that it's a step too far - I'll > see if I can

Re: Proposal for 1.2: built-in logging with django.core.log

On Sep 18, 6:21 pm, Eric Holscher wrote: > I have looked into Logging before for another project, and I found that > SQLAlchemy's support seemed to be a pretty good model to follow. They define > all of their loggers under the sqlalchemy namespace, and then you can >

Re: Proposal for 1.2: built-in logging with django.core.log

I have looked into Logging before for another project, and I found that SQLAlchemy's support seemed to be a pretty good model to follow. They define all of their loggers under the sqlalchemy namespace, and then you can configure different handlers for different things[1]: import logging

Re: Multitable model inheritance

Hi, This kind of question belongs to Django-Users group. Django-Developers is for thread regarding the development of Django itself. Thanks On 18 sep, 04:51, nisha wrote: > Hi, > > I have my models defined like this. > > class Image(models.Model): >     description =

#9194: Allow additional hashing algorithms for passwords

Hi. There is a feature described in a ticket #9194[1], which has been marked as 'Design decision needed'. Is it still being discussed, or has it been forgotten completely? I'm working on a patch for myself, but I'm not sure whether I should attach it to ticket when I finish, if it's marked that

RE: Multitable model inheritance

Hi, I have my models defined like this. class Image(models.Model): description = models.CharField(max_length=500) . class ImageStatic(models.Model): """ Image metadata not under change control """ def latest(self): return

Re: django.contrib.markup and ReST

[sorry if this message appeared second time] > This is intended behavior from docutils: if the reST document starts > with a header it is considered the "document header" and is > intentionally not a part of the fragment by default. Rather than > using the body the correct approach would be to

Re: SoC merge plans?

On Sep 17, 1:48 pm, Russell Keith-Magee wrote: > My hesitation here is that there one of the outstanding changes is a > fairly big refactor of the way the SQL backend handles queries, and I > want to make sure it's right before we inflict it on the world. In > particular,