Hi !
It might be a stupid question, but is there a reason why
`django.trunk.django.core.files.base.File` is not a subclass of
`file` ?
I ask this because after debugging my code - some urllib2 handler
(http://dpaste.com/437031/), based on a snippet I found somewhere - I
figured out that posted fil
On Mon, Feb 21, 2011 at 8:55 AM, sebastien piquemal wrote:
> Hi !
>
> It might be a stupid question, but is there a reason why
> `django.trunk.django.core.files.base.File` is not a subclass of
> `file` ?
> I ask this because after debugging my code - some urllib2 handler
> (http://dpaste.com/43703
Russ, Carl, thanks for your feedback. Russ, I understand what you say
about not wanting to adopt crypto code because of the additional
responsibility. Unfortunately, there aren't very good options. Django
contrib.auth already makes the recommendation of SHA1 which we all
agree is less than ideal. T
On Mon, Feb 21, 2011 at 3:23 PM, poswald wrote:
> Russ, Carl, thanks for your feedback. Russ, I understand what you say
> about not wanting to adopt crypto code because of the additional
> responsibility. Unfortunately, there aren't very good options. Django
> contrib.auth already makes the recomm
Django devs, I wanted to thank you for a truly awesome framework.
Programming with Python, and web app dev in Django, is truly a
pleasure. Our company, Security Compass, uses Django quite
substantially internally.
We put together a document called the Secure Web Application Framework
Manifesto for
Hello,
I was wondering if others would find it useful to introduce a new
field in Trac to characterise the nature of a ticket, allowing to
choose from at least: "bug report", "feature request", or
"optimisation". I think this would help bring the right focus during
alpha and beta stages, and also
On Mon, Feb 21, 2011 at 3:05 PM, Julien Phalip wrote:
> Hello,
>
> I was wondering if others would find it useful to introduce a new
> field in Trac to characterise the nature of a ticket, allowing to
> choose from at least: "bug report", "feature request", or
> "optimisation".
Trac already has a
One more point - if any of you have questions for somebody who leaves
and breathes web application security every day, please feel free to
fire them off to me:
rohit at securitycompass.com
On Feb 21, 10:21 am, Rohit Sethi wrote:
> Django devs, I wanted to thank you for a truly awesome framework
After hunting down a very elusive bug, I found the cause to be due to the
fact that render_to_string leaves the context in a different state than it
started (due to the context stack being pushed before rendering, and then
not popped).
This behavior differs from a standard Template.render call
On Tue, Feb 22, 2011 at 2:05 AM, Julien Phalip wrote:
> Hello,
>
> I was wondering if others would find it useful to introduce a new
> field in Trac to characterise the nature of a ticket, allowing to
> choose from at least: "bug report", "feature request", or
> "optimisation". I think this would
On Mon, Feb 21, 2011 at 6:36 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
> On Tue, Feb 22, 2011 at 2:05 AM, Julien Phalip wrote:
> > Hello,
> >
> > I was wondering if others would find it useful to introduce a new
> > field in Trac to characterise the nature of a ticket, allowing to
I'm still in favor of adding the "needsinfo" resolution and would love to
see that happen... I guess technically I could even do that one myself via
Trac's web admin if we're all agreed on it.
I'm ambivalent about adding the "ticket type" field back in, though. It can
be useful, but it *is* an
On Mon, Feb 21, 2011 at 11:21 PM, Rohit Sethi wrote:
> Django devs, I wanted to thank you for a truly awesome framework.
> Programming with Python, and web app dev in Django, is truly a
> pleasure. Our company, Security Compass, uses Django quite
> substantially internally.
>
> We put together a d
Russell, awesome feedback. Thanks for being candid. We are on the same
page that the manifesto is really not all that important in and of
itself: The document piece is really only designed to give frameworks
a platform to say "hey, these are what we support" so that web app
developers building secu
I've got one bit of feedback to offer on the document (which I did
bookmark for future reference):
Monolithic documents present a huge problem for finding, using and
retaining information.
A very useful and interesting extension of this type of project would
be to work with people who have experi
15 matches
Mail list logo