Re: logging?

[Vinay Sajip]

On May 5, 4:47 am, Kevin Howerton  wrote:

I think the plan was to look at integrating logging after the 1.2
release was done. The original discussion was here:

http://groups.google.com/group/django-developers/browse_frm/thread/8551ecdb7412ab22/

With Django's configuration style, it would be beneficial to use
dictionary-based configuration as introduced in PEP 391 and
implemented in Python trunk (2.7/3.2). For older Python versions,
Django could use my standalone implementation of PEP-391 functionality
available at

http://bitbucket.org/vinay.sajip/dictconfig/

I have a Django branch which shows how logging can be easily
integrated during startup, and it's at

https://code.launchpad.net/~vinay-sajip/django/logging

It's a proof-of-concept, last merged with trunk in Jan 2010, but the
changes are simple so it shouldn't be a problem to bring up to date.
I'll look at doing this once 1.2 is out.

Regards,


Vinay Sajip

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Silently replaced session_key

[George Sakkis]

On May 4, 11:05 pm, Jacob Kaplan-Moss  wrote:

> On Tue, May 4, 2010 at 3:11 PM, George Sakkis  wrote:
> > Is this a bug or a feature ?
>
> Take a look at the source (django/contrib/sessions/backends/db.py;
> line 16 - the load() function). If the session key doesn't exist in
> the database, a new session key will be generated. This prevents users
> from being able to "choose" arbitrary session keys, so that's the
> correct thing to do.

Ok, the rationale makes sense (as a default, overridable choice at
least) but the API could be less surprising, e.g. raise an exception
when a non auto-generated key is passed. Also it turns out that it
doesn't really prevent setting a key explicitly, it just makes it more
cumbersome:

session_key = 'secret!!1!'
s = SessionStore(session_key)
s['foo'] = 'bar'
s.session_key = session_key   # I *really* mean session_key dammit
s.save()

This creates two entries, one with a random key and one with
session_key but only the latter's session_data are updated.

The following avoids creating the random key in the first place:

s = SessionStore()
if not s.exists(session_key):
s['foo'] = 'bar'
s.session_key = session_key
s.save()

I'm not sure if these are unintended implementation side effects but
they seem incongruent.

George

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Silently replaced session_key

[Tom Evans]

On Wed, May 5, 2010 at 10:24 AM, George Sakkis  wrote:
> On May 4, 11:05 pm, Jacob Kaplan-Moss  wrote:
>
>> On Tue, May 4, 2010 at 3:11 PM, George Sakkis  
>> wrote:
>> > Is this a bug or a feature ?
>>
>> Take a look at the source (django/contrib/sessions/backends/db.py;
>> line 16 - the load() function). If the session key doesn't exist in
>> the database, a new session key will be generated. This prevents users
>> from being able to "choose" arbitrary session keys, so that's the
>> correct thing to do.
>
> Ok, the rationale makes sense (as a default, overridable choice at
> least) but the API could be less surprising, e.g. raise an exception
> when a non auto-generated key is passed. Also it turns out that it
> doesn't really prevent setting a key explicitly, it just makes it more
> cumbersome:
>
> session_key = 'secret!!1!'
> s = SessionStore(session_key)
> s['foo'] = 'bar'
> s.session_key = session_key   # I *really* mean session_key dammit
> s.save()
>
> This creates two entries, one with a random key and one with
> session_key but only the latter's session_data are updated.
>
> The following avoids creating the random key in the first place:
>
> s = SessionStore()
> if not s.exists(session_key):
>    s['foo'] = 'bar'
>    s.session_key = session_key
>    s.save()
>
> I'm not sure if these are unintended implementation side effects but
> they seem incongruent.
>
> George
>

If you allow users to present new session ids without replacing them,
then you open up an attack vector for a session fixation attack. The
default behaviour is default for a reason.

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Newbie

[sujith h]

Hi,

I am newbie to django. And I had read the first 8 chapters of django from
the django book 2.0
(http://www.djangobook.com/en/2.0/chapter02/). I would like to do code
contribute to django.
I had gone through some of the tickets in the django website
http://code.djangoproject.com/query.
I found a lot of them were little tough for me. Can anyone help me point a
small issue which could
be fixed by a newbie? That help would be very much appreciated :)


Sujith H

-- 
സുജിത് ഹരിദാസന്
Bangalore
http://fci.wikia.com/wiki/Anti-DRM-Campaign
KDE Plasma contributor
 http://sujithh.info

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Newbie

[Tom Evans]

On Wed, May 5, 2010 at 7:16 AM, sujith h  wrote:
> Hi,
>
> I am newbie to django. And I had read the first 8 chapters of django from
> the django book 2.0
> (http://www.djangobook.com/en/2.0/chapter02/). I would like to do code
> contribute to django.
> I had gone through some of the tickets in the django website
> http://code.djangoproject.com/query.
> I found a lot of them were little tough for me. Can anyone help me point a
> small issue which could
> be fixed by a newbie? That help would be very much appreciated :)
>
>
> Sujith H
>

I suggest you write something using django before trying to rewrite
django itself.

Otherwise, a good place for a newbie to start with tickets is with
tickets marked documentation or translations.

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Regression tests and translations for new localflavor feature.

[Felipe Prenholato]

Hello people.

Last night I opened ticket
13473 that
aims easy use of model fields for Braziliam CPF and CNPJ fields (as showed
in ticket).
After initial work, I need to construct tests and make translations.

My first point is: what is right place to put tests?

We have in *tests/regressiontests/forms/localflavor/br.py* that tests for BR
form fields.
In *tests/regressiontests/model_fields/* doesn't have nothing for localized
tests, so we need to create: *
tests/regressiontests/model_fields/localflavor/br.py* ?

Other idea is move tests for BR form fields (and add tests for models) to *
tests/regressiontests/localflavor/br/*, and with that, move tests of *
tests/regressiontests/localflavor/* to *
tests/regressiontests/localflavor/us/* because all found in *
tests/regressiontests/localflavor/* today is about US fields.

So, what is right way to follow?

-- 
Felipe 'chronos' Prenholato.
Linux User nº 405489
Home page: http://chronosbox.org/blog
Twitter: http://twitter.com/chronossc

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Regression tests and translations for new localflavor feature.

[Russell Keith-Magee]

On Wed, May 5, 2010 at 9:03 PM, Felipe Prenholato  wrote:
> Hello people.
> Last night I opened ticket 13473 that aims easy use of model fields for
> Braziliam CPF and CNPJ fields (as showed in ticket).
> After initial work, I need to construct tests and make translations.
> My first point is: what is right place to put tests?
> We have in tests/regressiontests/forms/localflavor/br.py that tests for BR
> form fields.
> In tests/regressiontests/model_fields/ doesn't have nothing for localized
> tests, so we need to
> create: tests/regressiontests/model_fields/localflavor/br.py ?
> Other idea is move tests for BR form fields (and add tests for models)
> to tests/regressiontests/localflavor/br/, and with that, move tests
> of tests/regressiontests/localflavor/
> to tests/regressiontests/localflavor/us/ because all found
> in tests/regressiontests/localflavor/ today is about US fields.

Like I told you in #django-dev on IRC a few days ago (26th April), the
last option (refactor regressiontests/localflavor into a /us branch,
and add /br) is the way to go. We don't have an existing
infrastructure for testing localflavor models because the US
localflavor is currently the only localflavor with models. If you're
going to add Brazilian models, we need to take the opportunity to
provide this infrastructure.

regressiontests/model_fields isn't the right place; that's the tests
for built in fields, not for contrib extensions.

regressiontests/forms/localflavor isn't the right place because this
isn't a form issue.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: logging?

[Kevin Howerton]

Both yours and simon wilsons solutions look like great solutions.
Though possibly over-arching for an initial implementation of logging,
but if an implementation like that makes it into 1.3 in one fell swoop
I would be as happy as a clam.

Making use of python's built-in logging facility should be a very high
priority for any python project that considers itself worthy of being
used in production environments.

You guys are definitely taking the right direction  having
comprehensive logging coverage in my opinion is more important than
having comprehensive test coverage.

What I was suggesting in my post though, was that we alter the default
CRITICAL error handling behavior ... as it stands (by default) all of
my ERRORs are being suppressed in production.  This is pretty
confusing for new users (there were 3 others in IRC with the same
complaint yesterday), and pretty un-pythonic IMO.  Unless I missed
something?

At minimum the documentation should inform the user of this
short-coming, and provide a link to a wiki with the available
work-arounds.

Leaving out logging of critical errors because we don't currently have
the perfect all encompassing logging solution, is not the decision I
would have made.  Doing things in an iterative cycle might work
better.  Step 1: do what you need to have done.  Step 2: do what you
want to have done.

Leaving out critical stuff because you don't know what you want, when
you know what you need that is critical is no bueno.  It's like not
setting a broken arm because you can't decide on what color you want
the fiber glass to be.

-k

ps.  I don't want to get into a flamewar (although it is certainly one
of my specialities... and prefacing this paragraph with this sentence
probably won't help the cause), though after reading that thread I
felt like this needed to be said.

No one here (me included) is allowed to call a *built-in* Python
library un-pythonic especially the logger.

So it shares some similarities with Java?  Some stuff in Java is
awesome.  Some stuff in Ruby is awesome.  Some of the stuff in Rails
is awesome.  Some stuff in C# is awesome.  Some stuff in Perl is
awesome.  I've luckily been able to avoid PHP for my entire career,
but I'm sure there is something really nice about PHP too.   The very
reason python is such a great language is *because* it takes some
(possibly even all of it) of the awesome stuff from a variety of
technologies, not because it wildly diverges and does things uniquely.

I see a lot of this pretentiousness in the programming community in
general, and really it is pretty detrimental to who-ever ends up
spouting it off.  It's very reductionist.  Ignoring prior art just
because it was written in ruby, or targets rails, or runs on the JVM,
or uses CamelCase for function names is stupid.


On Wed, May 5, 2010 at 4:17 AM, Vinay Sajip  wrote:
>
> On May 5, 4:47 am, Kevin Howerton  wrote:
>
> I think the plan was to look at integrating logging after the 1.2
> release was done. The original discussion was here:
>
> http://groups.google.com/group/django-developers/browse_frm/thread/8551ecdb7412ab22/
>
> With Django's configuration style, it would be beneficial to use
> dictionary-based configuration as introduced in PEP 391 and
> implemented in Python trunk (2.7/3.2). For older Python versions,
> Django could use my standalone implementation of PEP-391 functionality
> available at
>
> http://bitbucket.org/vinay.sajip/dictconfig/
>
> I have a Django branch which shows how logging can be easily
> integrated during startup, and it's at
>
> https://code.launchpad.net/~vinay-sajip/django/logging
>
> It's a proof-of-concept, last merged with trunk in Jan 2010, but the
> changes are simple so it shouldn't be a problem to bring up to date.
> I'll look at doing this once 1.2 is out.
>
> Regards,
>
>
> Vinay Sajip
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: logging?

[Kevin Howerton]

Both yours and simon wilsons solutions look like great solutions.
Though possibly over-arching for an initial implementation of logging,
but if an implementation like that makes it into 1.3 in one fell swoop
I would be as happy as a clam.

Making use of python's built-in logging facility should be a very high
priority for any python project that considers itself worthy of being
used in production environments.

You guys are definitely taking the right direction  having
comprehensive logging coverage in my opinion is more important than
having comprehensive test coverage.

What I was suggesting in my post though, was that we alter the default
CRITICAL error handling behavior ... as it stands (by default) all of
my ERRORs are being suppressed in production.  This is pretty
confusing for new users (there were 3 others in IRC with the same
complaint yesterday), and pretty un-pythonic IMO.  Unless I missed
something?

At minimum the documentation should inform the user of this
short-coming, and provide a link to a wiki with the available
work-arounds.

Leaving out logging of critical errors because we don't currently have
the perfect all encompassing logging solution, is not the decision I
would have made.  Doing things in an iterative cycle might work
better.  Step 1: do what you need to have done.  Step 2: do what you
want to have done.

Leaving out critical stuff because you don't know what you want, when
you know what you need that is critical is no bueno.  It's like not
setting a broken arm because you can't decide on what color you want
the fiber glass to be.

-k

ps.  I don't want to get into a flamewar (although it is certainly one
of my specialities... and prefacing this paragraph with this sentence
probably won't help the cause), though after reading that thread I
felt like this needed to be said.

No one here (me included) is allowed to call a *built-in* Python
library un-pythonic especially the logger.

So it shares some similarities with Java?  Some stuff in Java is
awesome.  Some stuff in Ruby is awesome.  Some of the stuff in Rails
is awesome.  Some stuff in C# is awesome.  Some stuff in Perl is
awesome.  I've luckily been able to avoid PHP for my entire career,
but I'm sure there is something really nice about PHP too.   The very
reason python is such a great language is *because* it takes some
(possibly even all of it) of the awesome stuff from a variety of
technologies, not because it wildly diverges and does things uniquely.

I see a lot of this pretentiousness in the programming community in
general, and really it is pretty detrimental to who-ever ends up
spouting it off.  It's very reductionist.  Ignoring prior art just
because it was written in ruby, or targets rails, or runs on the JVM,
or uses CamelCase for function names is stupid.


On Wed, May 5, 2010 at 4:17 AM, Vinay Sajip  wrote:
>
> On May 5, 4:47 am, Kevin Howerton  wrote:
>
> I think the plan was to look at integrating logging after the 1.2
> release was done. The original discussion was here:
>
> http://groups.google.com/group/django-developers/browse_frm/thread/8551ecdb7412ab22/
>
> With Django's configuration style, it would be beneficial to use
> dictionary-based configuration as introduced in PEP 391 and
> implemented in Python trunk (2.7/3.2). For older Python versions,
> Django could use my standalone implementation of PEP-391 functionality
> available at
>
> http://bitbucket.org/vinay.sajip/dictconfig/
>
> I have a Django branch which shows how logging can be easily
> integrated during startup, and it's at
>
> https://code.launchpad.net/~vinay-sajip/django/logging
>
> It's a proof-of-concept, last merged with trunk in Jan 2010, but the
> changes are simple so it shouldn't be a problem to bring up to date.
> I'll look at doing this once 1.2 is out.
>
> Regards,
>
>
> Vinay Sajip
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: logging?

[Kevin Howerton]

Both yours and simon wilsons solutions look like great solutions.
Though possibly over-arching for an initial implementation of logging,
but if an implementation like that makes it into 1.3 in one fell swoop
I would be as happy as a clam.

Making use of python's built-in logging facility should be a very high
priority for any python project that considers itself worthy of being
used in production environments.

You guys are definitely taking the right direction  having
comprehensive logging coverage in my opinion is more important than
having comprehensive test coverage.

What I was suggesting in my post though, was that we alter the default
CRITICAL error handling behavior ... as it stands (by default) all of
my ERRORs are being suppressed in production.  This is pretty
confusing for new users (there were 3 others in IRC with the same
complaint yesterday), and pretty un-pythonic IMO.  Unless I missed
something?

At minimum the documentation should inform the user of this
short-coming, and provide a link to a wiki with the available
work-arounds.

Leaving out logging of critical errors because we don't currently have
the perfect all encompassing logging solution, is not the decision I
would have made.  Doing things in an iterative cycle might work
better.  Step 1: do what you need to have done.  Step 2: do what you
want to have done.

Leaving out critical stuff because you don't know what you want, when
you know what you need that is critical is no bueno.  It's like not
setting a broken arm because you can't decide on what color you want
the fiber glass to be.

-k

ps.  I don't want to get into a flamewar (although it is certainly one
of my specialities... and prefacing this paragraph with this sentence
probably won't help the cause), though after reading that thread I
felt like this needed to be said.

No one here (me included) is allowed to call a *built-in* Python
library un-pythonic especially the logger.

So it shares some similarities with Java?  Some stuff in Java is
awesome.  Some stuff in Ruby is awesome.  Some of the stuff in Rails
is awesome.  Some stuff in C# is awesome.  Some stuff in Perl is
awesome.  I've luckily been able to avoid PHP for my entire career,
but I'm sure there is something really nice about PHP too.   The very
reason python is such a great language is *because* it takes some
(possibly even all of it) of the awesome stuff from a variety of
technologies, not because it wildly diverges and does things uniquely.

I see a lot of this pretentiousness in the programming community in
general, and really it is pretty detrimental to who-ever ends up
spouting it off.  It's very reductionist.  Ignoring prior art just
because it was written in ruby, or targets rails, or runs on the JVM,
or uses CamelCase for function names is stupid.


On Wed, May 5, 2010 at 4:17 AM, Vinay Sajip  wrote:
>
> On May 5, 4:47 am, Kevin Howerton  wrote:
>
> I think the plan was to look at integrating logging after the 1.2
> release was done. The original discussion was here:
>
> http://groups.google.com/group/django-developers/browse_frm/thread/8551ecdb7412ab22/
>
> With Django's configuration style, it would be beneficial to use
> dictionary-based configuration as introduced in PEP 391 and
> implemented in Python trunk (2.7/3.2). For older Python versions,
> Django could use my standalone implementation of PEP-391 functionality
> available at
>
> http://bitbucket.org/vinay.sajip/dictconfig/
>
> I have a Django branch which shows how logging can be easily
> integrated during startup, and it's at
>
> https://code.launchpad.net/~vinay-sajip/django/logging
>
> It's a proof-of-concept, last merged with trunk in Jan 2010, but the
> changes are simple so it shouldn't be a problem to bring up to date.
> I'll look at doing this once 1.2 is out.
>
> Regards,
>
>
> Vinay Sajip
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: logging?

[Jacob Kaplan-Moss]

On Wed, May 5, 2010 at 11:48 AM, Kevin Howerton
 wrote:
> ps.  I don't want to get into a flamewar

Then next time leave out the rambling, ad hominems, and sweeping
generalizations. Focus on technical suggestions -- working code is
even better. If you have problems, suggest fixes concretely.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: logging?

[Kevin Howerton]

I did.

On Wed, May 5, 2010 at 12:56 PM, Jacob Kaplan-Moss  wrote:
> On Wed, May 5, 2010 at 11:48 AM, Kevin Howerton
>  wrote:
>> ps.  I don't want to get into a flamewar
>
> Then next time leave out the rambling, ad hominems, and sweeping
> generalizations. Focus on technical suggestions -- working code is
> even better. If you have problems, suggest fixes concretely.
>
> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: logging?

[Karen Tracey]

On Wed, May 5, 2010 at 12:46 PM, Kevin Howerton wrote:

> What I was suggesting in my post though, was that we alter the default
> CRITICAL error handling behavior ... as it stands (by default) all of
> my ERRORs are being suppressed in production.  This is pretty
> confusing for new users (there were 3 others in IRC with the same
> complaint yesterday), and pretty un-pythonic IMO.  Unless I missed
> something?
>

I think you are missing something. From your earlier note you seem to be
saying that it is information your own code is writing to stderr that is
getting lost somewhere. Django does nothing to suppress anything sent do
stderr. I've got views that write to stderr running under mod_wsgi, and the
stderr output appears in the configured Apache error log. You do need to
either include a newline in the data or explicitly flush stderr for the data
to be written, and that may be a difference from mod_python (I don't
remember enough about mod_python to say one way or the other). I think the
problem you are having is more related to mod_wsgi, and possible differences
between it and mod_python, than Django.


> At minimum the documentation should inform the user of this
> short-coming, and provide a link to a wiki with the available
> work-arounds.
>

It isn't clear to me what shortcoming you think should be documented. If it
is the behavior of mod_wsgi with respect to stderr possibly the deployment
docs for mod_wsgi could mention something, but one danger of Django putting
information like this in the docs is that it gets out of date as mod_wsgi
evolves. In general it seems better to provide a minimum amount of
information in Django doc, stuff that is specific to Django, and point the
user to the appropriate source for authoritative documentation on the
3rd-party package.

For the record, Django's default handling of critical errors when DEBUG is
False is fully documented:

http://docs.djangoproject.com/en/dev/howto/error-reporting/

Karen

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Template Tag Not Reinitialized in Loop

[Apreche]

I had a really strange bug in one of my custom template tags today. It
took me the entire morning to figure it out, but I finally did. I'm
not sure if it's a bug or a feature, but I wanted to make a post to
help the next person who has this same problem.

Let's pretend you make a custom template tag foo. The render method
for foo is in a class FooNode, and you pass it a person from the
context.

{% foo persona %}
{% foo personb %}

Then, as is common, you have a list of people that you render with a
loop in the template.

{% for person in people %}
{% foo person %}
{% endfor %}

It turns out that when a template tag stands alone, the __init__ of
FooNode will be called each time the template tag appears. However,
when the template tag is inside of a loop, the __init__ of the FooNode
is only called once. That single instance of FooNode sticks around,
and it's render method is called over and over as the loop goes
around.

This doesn't seem like that big of a deal. However, my template tag
was written in such a way that data members of FooNode were being set
in the __init__ and reused in the render(). Because the initialization
only happened the first time through the loop, the template tag always
rendered as if it was for the first person in the list. Those data
members carried over to subsequent renders because the Node was not
reinitialized. I managed to fix it, but be aware. If your template
tags are behaving strangely when they are in loops, this is probably
the issue.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Regression tests and translations for new localflavor feature.

[Felipe Prenholato]

Hello Russel.

I started refactoring of localflavor tests but I think that I'm doing
something wrong, I re-ordened in following way:

~/projects/django-trunk-git/tests/regressiontests/localflavor $ tree
.
├── forms.py # import all from us.forms
├── __init__.py
├── models.py # import all from us.models
├── tests.py # import all from us.tests
└── us
├── forms.py # original us tests forms
├── __init__.py
├── models.py # original us tests models
└── tests.py # original us tests tests

That is only way that I found to not enter in a
*'django.core.exceptions.ImproperlyConfigured:
App with label localflavor could not be found'* exception (
http://dpaste.de/crRP/).

But, I'm getting following error when run tests:

~/projects/django-trunk-git $ ./tests/runtests.py
--settings=django_test.settings -v 1 localflavor
Importing model localflavor
Importing model localflavor
Creating test database 'default'...
Creating table django_content_type
Creating table auth_permission
Creating table auth_group_permissions
Creating table auth_group
Creating table auth_user_user_permissions
Creating table auth_user_groups
Creating table auth_user
Creating table auth_message
Creating table django_site
Creating table django_flatpage_sites
Creating table django_flatpage
Creating table django_redirect
Creating table django_session
Creating table django_comments
Creating table django_comment_flags
Creating table django_admin_log
Installing index for auth.Permission model
Installing index for auth.Group_permissions model
Installing index for auth.User_user_permissions model
Installing index for auth.User_groups model
Installing index for auth.Message model
Installing index for flatpages.FlatPage_sites model
Installing index for flatpages.FlatPage model
Installing index for redirects.Redirect model
Installing index for comments.Comment model
Installing index for comments.CommentFlag model
Installing index for admin.LogEntry model
No fixtures found.
.E.
==
ERROR: Test that the get_*_display() methods are added to the model
instances.
--
Traceback (most recent call last):
  File
"/home/felipe/projects/django-trunk-git/tests/regressiontests/localflavor/us/tests.py",
line 11, in test_get_display_methods
place = self.form.save()
  File
"/home/felipe/.py/2.6/lib/python2.6/site-packages/django/forms/models.py",
line 371, in save
fail_message, commit, construct=False)
  File
"/home/felipe/.py/2.6/lib/python2.6/site-packages/django/forms/models.py",
line 86, in save_instance
instance.save()
  File
"/home/felipe/.py/2.6/lib/python2.6/site-packages/django/db/models/base.py",
line 435, in save
self.save_base(using=using, force_insert=force_insert,
force_update=force_update)
  File
"/home/felipe/.py/2.6/lib/python2.6/site-packages/django/db/models/base.py",
line 528, in save_base
result = manager._insert(values, return_id=update_pk, using=using)
  File
"/home/felipe/.py/2.6/lib/python2.6/site-packages/django/db/models/manager.py",
line 195, in _insert
return insert_query(self.model, values, **kwargs)
  File
"/home/felipe/.py/2.6/lib/python2.6/site-packages/django/db/models/query.py",
line 1479, in insert_query
return query.get_compiler(using=using).execute_sql(return_id)
  File
"/home/felipe/.py/2.6/lib/python2.6/site-packages/django/db/models/sql/compiler.py",
line 783, in execute_sql
cursor = super(SQLInsertCompiler, self).execute_sql(None)
  File
"/home/felipe/.py/2.6/lib/python2.6/site-packages/django/db/models/sql/compiler.py",
line 727, in execute_sql
cursor.execute(sql, params)
  File
"/home/felipe/.py/2.6/lib/python2.6/site-packages/django/db/backends/postgresql_psycopg2/base.py",
line 44, in execute
return self.cursor.execute(query, args)
DatabaseError: relation "us_place" does not exist
LINE 1: INSERT INTO "us_place" ("state", "state_req", "state_default...
^


--
Ran 3 tests in 0.013s

FAILED (errors=1)
Destroying test database 'default'...

This error show that at 'syncdb' django not found my models, so, if
importing in this way not works, I'm glad if anyone can help-me to run tests
in 'submodules' at regressiontests directory.

Cheers, Felipe

2010/5/5 Russell Keith-Magee 

> On Wed, May 5, 2010 at 9:03 PM, Felipe Prenholato 
> wrote:
> > Hello people.
> > Last night I opened ticket 13473 that aims easy use of model fields for
> > Braziliam CPF and CNPJ fields (as showed in ticket).
> > After initial work, I need to construct tests and make translations.
> > My first point is: what is right place to put tests?
> > We have in tests/regressiontests/forms/localflavor/br.py that tests for
> BR
> > form fields.
> > In tests/regressiontests/model_fields/ doesn't have nothing for localized
> > tests, so we need to
> > create: tests/regressiontests/model_fields/localflavor/

Re: Template Tag Not Reinitialized in Loop

[burc...@gmail.com]

Hi Apreche,

I don't want to be rude, but you probably wanted to send this to
django-users, it is the place full of users of django framework who
should be aware of your problem and this point of confusion (hm, or
should it be blog post so everyone can google on their problem and
find your message?).
Everyone here in django-dev assumes that you have suggestion to fix
something in django if you're writing here.
Probably, you might suggest to improve django documentation where it
explains how to create custom template tags.
It seems you're really good at writing documentation!
Then, please, go on, improve the current documentation text, create a
ticket, and send your patch.

On Wed, May 5, 2010 at 10:12 PM, Apreche  wrote:
> I had a really strange bug in one of my custom template tags today. It
> took me the entire morning to figure it out, but I finally did. I'm
> not sure if it's a bug or a feature, but I wanted to make a post to
> help the next person who has this same problem.
>
> Let's pretend you make a custom template tag foo. The render method
> for foo is in a class FooNode, and you pass it a person from the
> context.
>
> {% foo persona %}
> {% foo personb %}
>
> Then, as is common, you have a list of people that you render with a
> loop in the template.
>
> {% for person in people %}
> {% foo person %}
> {% endfor %}
>
> It turns out that when a template tag stands alone, the __init__ of
> FooNode will be called each time the template tag appears. However,
> when the template tag is inside of a loop, the __init__ of the FooNode
> is only called once. That single instance of FooNode sticks around,
> and it's render method is called over and over as the loop goes
> around.
>
> This doesn't seem like that big of a deal. However, my template tag
> was written in such a way that data members of FooNode were being set
> in the __init__ and reused in the render(). Because the initialization
> only happened the first time through the loop, the template tag always
> rendered as if it was for the first person in the list. Those data
> members carried over to subsequent renders because the Node was not
> reinitialized. I managed to fix it, but be aware. If your template
> tags are behaving strangely when they are in loops, this is probably
> the issue.

-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: logging?

[Kevin Howerton]

Yeah... not sure, though thank you for actually reading and responding
to my post.

"I think the problem you are having is more related to mod_wsgi, and
possible differences between it and mod_python, than Django."

Absolutely.  Though, I'm not sure if it's the official recommendation
of django-project.com now or not, but most people in the community are
using mod_wsgi in Daemon mode.  It is definitely a result of this,
also I doubt mod_wsgi is going to be changing the nature of their
exception handling code faster than you guys can keep up.  It seems
like a pretty sweet setup right now so hopefully they don't change it
;)

Where django pulls a 500 it should call these two lines, which will
dump the exception raised to stderr.

type, value, traceback = sys.exc_info()
sys.excepthook(type, value, traceback)

If you have a logger setup, which I assume most sane people in
production do (right?!?).  You can pass the exception info to the
logger with and have the same result as one that passes straight to
stderr only you can have more explicit control over how it behaves,
especially if django uses named loggers:

   logger.error("This can't be good", exc_info=True)

We don't really need both, but either one should exist in django if
it's going to support wsgi ;)  Perhaps, I'm missing some config
setting available to mod_wsgi that will replicate mod_python's
behavior in this regard, but i "feel" django should work with a
default setup.

Also, I've tested this on both Fedora 8, and mod_wsgi 2.x ... and the
latest 2.6.5 python + wsgi 3.2.

"http://docs.djangoproject.com/en/dev/howto/error-reporting/";

I can't use email reporting because of performance, logistics, and
sheer volume in production.

-k


On Wed, May 5, 2010 at 1:51 PM, Karen Tracey  wrote:
> On Wed, May 5, 2010 at 12:46 PM, Kevin Howerton 
> wrote:
>>
>> What I was suggesting in my post though, was that we alter the default
>> CRITICAL error handling behavior ... as it stands (by default) all of
>> my ERRORs are being suppressed in production.  This is pretty
>> confusing for new users (there were 3 others in IRC with the same
>> complaint yesterday), and pretty un-pythonic IMO.  Unless I missed
>> something?
>
> I think you are missing something. From your earlier note you seem to be
> saying that it is information your own code is writing to stderr that is
> getting lost somewhere. Django does nothing to suppress anything sent do
> stderr. I've got views that write to stderr running under mod_wsgi, and the
> stderr output appears in the configured Apache error log. You do need to
> either include a newline in the data or explicitly flush stderr for the data
> to be written, and that may be a difference from mod_python (I don't
> remember enough about mod_python to say one way or the other). I think the
> problem you are having is more related to mod_wsgi, and possible differences
> between it and mod_python, than Django.
>
>>
>> At minimum the documentation should inform the user of this
>> short-coming, and provide a link to a wiki with the available
>> work-arounds.
>
> It isn't clear to me what shortcoming you think should be documented. If it
> is the behavior of mod_wsgi with respect to stderr possibly the deployment
> docs for mod_wsgi could mention something, but one danger of Django putting
> information like this in the docs is that it gets out of date as mod_wsgi
> evolves. In general it seems better to provide a minimum amount of
> information in Django doc, stuff that is specific to Django, and point the
> user to the appropriate source for authoritative documentation on the
> 3rd-party package.
>
> For the record, Django's default handling of critical errors when DEBUG is
> False is fully documented:
>
> http://docs.djangoproject.com/en/dev/howto/error-reporting/
>
> Karen
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: logging?

[Mike Axiak]

Why does this facility need to exist within Django? At least one
person [1] has written a middleware to do what you're saying. If it's
that important, people will start to use that app. There are certainly
many potential features people want out of logging, so it'd definitely
be better suited for an external app to bake.

I'd say that the main issue here isn't with lack of logging, but with
lack of a good one-stop Django app repository (DjangoZen [2] is a
start, but missing a lot of functionality). Unfortunately I don't have
time to maintain something like that.

Cheers,
Mike

1: http://github.com/djangrrl/django-logging-middleware
2: http://djangozen.com/

On Wed, May 5, 2010 at 2:53 PM, Kevin Howerton  wrote:
> Yeah... not sure, though thank you for actually reading and responding
> to my post.
>
> "I think the problem you are having is more related to mod_wsgi, and
> possible differences between it and mod_python, than Django."
>
> Absolutely.  Though, I'm not sure if it's the official recommendation
> of django-project.com now or not, but most people in the community are
> using mod_wsgi in Daemon mode.  It is definitely a result of this,
> also I doubt mod_wsgi is going to be changing the nature of their
> exception handling code faster than you guys can keep up.  It seems
> like a pretty sweet setup right now so hopefully they don't change it
> ;)
>
> Where django pulls a 500 it should call these two lines, which will
> dump the exception raised to stderr.
>
>    type, value, traceback = sys.exc_info()
>    sys.excepthook(type, value, traceback)
>
> If you have a logger setup, which I assume most sane people in
> production do (right?!?).  You can pass the exception info to the
> logger with and have the same result as one that passes straight to
> stderr only you can have more explicit control over how it behaves,
> especially if django uses named loggers:
>
>   logger.error("This can't be good", exc_info=True)
>
> We don't really need both, but either one should exist in django if
> it's going to support wsgi ;)  Perhaps, I'm missing some config
> setting available to mod_wsgi that will replicate mod_python's
> behavior in this regard, but i "feel" django should work with a
> default setup.
>
> Also, I've tested this on both Fedora 8, and mod_wsgi 2.x ... and the
> latest 2.6.5 python + wsgi 3.2.
>
> "http://docs.djangoproject.com/en/dev/howto/error-reporting/";
>
> I can't use email reporting because of performance, logistics, and
> sheer volume in production.
>
> -k
>
>
> On Wed, May 5, 2010 at 1:51 PM, Karen Tracey  wrote:
>> On Wed, May 5, 2010 at 12:46 PM, Kevin Howerton 
>> wrote:
>>>
>>> What I was suggesting in my post though, was that we alter the default
>>> CRITICAL error handling behavior ... as it stands (by default) all of
>>> my ERRORs are being suppressed in production.  This is pretty
>>> confusing for new users (there were 3 others in IRC with the same
>>> complaint yesterday), and pretty un-pythonic IMO.  Unless I missed
>>> something?
>>
>> I think you are missing something. From your earlier note you seem to be
>> saying that it is information your own code is writing to stderr that is
>> getting lost somewhere. Django does nothing to suppress anything sent do
>> stderr. I've got views that write to stderr running under mod_wsgi, and the
>> stderr output appears in the configured Apache error log. You do need to
>> either include a newline in the data or explicitly flush stderr for the data
>> to be written, and that may be a difference from mod_python (I don't
>> remember enough about mod_python to say one way or the other). I think the
>> problem you are having is more related to mod_wsgi, and possible differences
>> between it and mod_python, than Django.
>>
>>>
>>> At minimum the documentation should inform the user of this
>>> short-coming, and provide a link to a wiki with the available
>>> work-arounds.
>>
>> It isn't clear to me what shortcoming you think should be documented. If it
>> is the behavior of mod_wsgi with respect to stderr possibly the deployment
>> docs for mod_wsgi could mention something, but one danger of Django putting
>> information like this in the docs is that it gets out of date as mod_wsgi
>> evolves. In general it seems better to provide a minimum amount of
>> information in Django doc, stuff that is specific to Django, and point the
>> user to the appropriate source for authoritative documentation on the
>> 3rd-party package.
>>
>> For the record, Django's default handling of critical errors when DEBUG is
>> False is fully documented:
>>
>> http://docs.djangoproject.com/en/dev/howto/error-reporting/
>>
>> Karen
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http

Re: Silently replaced session_key

[George Sakkis]

On May 5, 12:25 pm, Tom Evans  wrote:
> On Wed, May 5, 2010 at 10:24 AM, George Sakkis  
> wrote:
> > On May 4, 11:05 pm, Jacob Kaplan-Moss  wrote:
>
> >> On Tue, May 4, 2010 at 3:11 PM, George Sakkis  
> >> wrote:
> >> > Is this a bug or a feature ?
>
> >> Take a look at the source (django/contrib/sessions/backends/db.py;
> >> line 16 - the load() function). If the session key doesn't exist in
> >> the database, a new session key will be generated. This prevents users
> >> from being able to "choose" arbitrary session keys, so that's the
> >> correct thing to do.
>
> > Ok, the rationale makes sense (as a default, overridable choice at
> > least) but the API could be less surprising, e.g. raise an exception
> > when a non auto-generated key is passed. Also it turns out that it
> > doesn't really prevent setting a key explicitly, it just makes it more
> > cumbersome:
>
> > session_key = 'secret!!1!'
> > s = SessionStore(session_key)
> > s['foo'] = 'bar'
> > s.session_key = session_key   # I *really* mean session_key dammit
> > s.save()
>
> > This creates two entries, one with a random key and one with
> > session_key but only the latter's session_data are updated.
>
> > The following avoids creating the random key in the first place:
>
> > s = SessionStore()
> > if not s.exists(session_key):
> >    s['foo'] = 'bar'
> >    s.session_key = session_key
> >    s.save()
>
> > I'm not sure if these are unintended implementation side effects but
> > they seem incongruent.
>
> > George
>
> If you allow users to present new session ids without replacing them,
> then you open up an attack vector for a session fixation attack. The
> default behaviour is default for a reason.

I'm repeating myself here but if the intention is to really disallow
user-provided ids. it can be done more clearly: raise an exception if
the key does not exist and make the session_key property read-only.
Now it seems like a bug that you can sort of work around by setting
the key just before saving.

By the way, this does not apply to all backends; file SessionStore for
example uses passed ids as is. Whatever the desired behavior is, it
should apply to all backends, so the relevant logic should  move to
SessionBase.

George

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: logging?

[Jacob Kaplan-Moss]

On Wed, May 5, 2010 at 1:53 PM, Kevin Howerton  wrote:
> Where django pulls a 500 it should call these two lines, which will
> dump the exception raised to stderr.
>
>    type, value, traceback = sys.exc_info()
>    sys.excepthook(type, value, traceback)

No, really it shouldn't.

I made a quick scan of sites I maintain (or help maintain) in
production now. Among them:

- 3 use the built-in errors over email (and this works fine).
- 1 logs exceptions to a local syslog daemon.
- 2 log to a remote syslogd server (one via TCP, the other via UDP).
- 2 log to stderr (and hence to the apache error log)
- 1 logs to stdout (<-- that's probably a bug :)

This all works *right now* without any changes to Django. Further,
your suggested change would break at least a couple of them.

Look, Django's got a *LOT* of ways to customize error handling and logging.

- Use the logging package directly where needed.
- Write a piece exception middleware.
- Subclass the handler (either ModPythonHandler or WSGIHandler) and
override exception handling.
- Write a WSGI exception middleware.

We're not going to add yet-another-extension-point unless you can
point to a very good reason for it, and you haven't yet.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Silently replaced session_key

[Jeremy Dunck]

On Wed, May 5, 2010 at 2:45 PM, George Sakkis  wrote:
...
> I'm repeating myself here but if the intention is to really disallow
> user-provided ids. it can be done more clearly: raise an exception if
> the key does not exist and make the session_key property read-only.
> Now it seems like a bug that you can sort of work around by setting
> the key just before saving.

Allowing an attacker to predictably raise exceptions might be bad.

> By the way, this does not apply to all backends; file SessionStore for
> example uses passed ids as is. Whatever the desired behavior is, it
> should apply to all backends, so the relevant logic should  move to
> SessionBase.

I filed a ticket for this: http://code.djangoproject.com/ticket/13478

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Template Tag Not Reinitialized in Loop

[Apreche]

Well, I think my suggestion is obviously that when a template tag is
in a loop, it should be re-initiated on every iteration, since that
would avoid unexpected and non-obvious side effects.

-Scott

On May 5, 2:52 pm, "burc...@gmail.com"  wrote:
> Hi Apreche,
>
> I don't want to be rude, but you probably wanted to send this to
> django-users, it is the place full of users of django framework who
> should be aware of your problem and this point of confusion (hm, or
> should it be blog post so everyone can google on their problem and
> find your message?).
> Everyone here in django-dev assumes that you have suggestion to fix
> something in django if you're writing here.
> Probably, you might suggest to improve django documentation where it
> explains how to create custom template tags.
> It seems you're really good at writing documentation!
> Then, please, go on, improve the current documentation text, create a
> ticket, and send your patch.
>
>
>
> On Wed, May 5, 2010 at 10:12 PM, Apreche  wrote:
> > I had a really strange bug in one of my custom template tags today. It
> > took me the entire morning to figure it out, but I finally did. I'm
> > not sure if it's a bug or a feature, but I wanted to make a post to
> > help the next person who has this same problem.
>
> > Let's pretend you make a custom template tag foo. The render method
> > for foo is in a class FooNode, and you pass it a person from the
> > context.
>
> > {% foo persona %}
> > {% foo personb %}
>
> > Then, as is common, you have a list of people that you render with a
> > loop in the template.
>
> > {% for person in people %}
> > {% foo person %}
> > {% endfor %}
>
> > It turns out that when a template tag stands alone, the __init__ of
> > FooNode will be called each time the template tag appears. However,
> > when the template tag is inside of a loop, the __init__ of the FooNode
> > is only called once. That single instance of FooNode sticks around,
> > and it's render method is called over and over as the loop goes
> > around.
>
> > This doesn't seem like that big of a deal. However, my template tag
> > was written in such a way that data members of FooNode were being set
> > in the __init__ and reused in the render(). Because the initialization
> > only happened the first time through the loop, the template tag always
> > rendered as if it was for the first person in the list. Those data
> > members carried over to subsequent renders because the Node was not
> > reinitialized. I managed to fix it, but be aware. If your template
> > tags are behaving strangely when they are in loops, this is probably
> > the issue.
>
> --
> Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
> MSN: bu...@live.com
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Template Tag Not Reinitialized in Loop

[Alex Gaynor]

On Wed, May 5, 2010 at 4:27 PM, Apreche  wrote:
> Well, I think my suggestion is obviously that when a template tag is
> in a loop, it should be re-initiated on every iteration, since that
> would avoid unexpected and non-obvious side effects.
>
> -Scott
>
> On May 5, 2:52 pm, "burc...@gmail.com"  wrote:
>> Hi Apreche,
>>
>> I don't want to be rude, but you probably wanted to send this to
>> django-users, it is the place full of users of django framework who
>> should be aware of your problem and this point of confusion (hm, or
>> should it be blog post so everyone can google on their problem and
>> find your message?).
>> Everyone here in django-dev assumes that you have suggestion to fix
>> something in django if you're writing here.
>> Probably, you might suggest to improve django documentation where it
>> explains how to create custom template tags.
>> It seems you're really good at writing documentation!
>> Then, please, go on, improve the current documentation text, create a
>> ticket, and send your patch.
>>
>>
>>
>> On Wed, May 5, 2010 at 10:12 PM, Apreche  wrote:
>> > I had a really strange bug in one of my custom template tags today. It
>> > took me the entire morning to figure it out, but I finally did. I'm
>> > not sure if it's a bug or a feature, but I wanted to make a post to
>> > help the next person who has this same problem.
>>
>> > Let's pretend you make a custom template tag foo. The render method
>> > for foo is in a class FooNode, and you pass it a person from the
>> > context.
>>
>> > {% foo persona %}
>> > {% foo personb %}
>>
>> > Then, as is common, you have a list of people that you render with a
>> > loop in the template.
>>
>> > {% for person in people %}
>> > {% foo person %}
>> > {% endfor %}
>>
>> > It turns out that when a template tag stands alone, the __init__ of
>> > FooNode will be called each time the template tag appears. However,
>> > when the template tag is inside of a loop, the __init__ of the FooNode
>> > is only called once. That single instance of FooNode sticks around,
>> > and it's render method is called over and over as the loop goes
>> > around.
>>
>> > This doesn't seem like that big of a deal. However, my template tag
>> > was written in such a way that data members of FooNode were being set
>> > in the __init__ and reused in the render(). Because the initialization
>> > only happened the first time through the loop, the template tag always
>> > rendered as if it was for the first person in the list. Those data
>> > members carried over to subsequent renders because the Node was not
>> > reinitialized. I managed to fix it, but be aware. If your template
>> > tags are behaving strangely when they are in loops, this is probably
>> > the issue.
>>
>> --
>> Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
>> MSN: bu...@live.com
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group 
>> athttp://groups.google.com/group/django-developers?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

No.  Template tags are initialized at compile time, not at execution
time.  Anything that requires global state should be done in the
render method.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: logging?

[Kevin Howerton]

I don't think you understand what the code I just posted is doing or
what the issue I described pertains to.

All I'm asking for is sane defaults, and consistency between
deployment platforms.  This isn't important?

I think I'm done here.

Thanks for the professionalism.

-k

On Wed, May 5, 2010 at 3:48 PM, Jacob Kaplan-Moss  wrote:
> On Wed, May 5, 2010 at 1:53 PM, Kevin Howerton  
> wrote:
>> Where django pulls a 500 it should call these two lines, which will
>> dump the exception raised to stderr.
>>
>>    type, value, traceback = sys.exc_info()
>>    sys.excepthook(type, value, traceback)
>
> No, really it shouldn't.
>
> I made a quick scan of sites I maintain (or help maintain) in
> production now. Among them:
>
> - 3 use the built-in errors over email (and this works fine).
> - 1 logs exceptions to a local syslog daemon.
> - 2 log to a remote syslogd server (one via TCP, the other via UDP).
> - 2 log to stderr (and hence to the apache error log)
> - 1 logs to stdout (<-- that's probably a bug :)
>
> This all works *right now* without any changes to Django. Further,
> your suggested change would break at least a couple of them.
>
> Look, Django's got a *LOT* of ways to customize error handling and logging.
>
> - Use the logging package directly where needed.
> - Write a piece exception middleware.
> - Subclass the handler (either ModPythonHandler or WSGIHandler) and
> override exception handling.
> - Write a WSGI exception middleware.
>
> We're not going to add yet-another-extension-point unless you can
> point to a very good reason for it, and you haven't yet.
>
> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: logging?

[Jacob Kaplan-Moss]

On Wed, May 5, 2010 at 3:31 PM, Kevin Howerton  wrote:
> I don't think you understand what the code I just posted is doing or
> what the issue I described pertains to.

You want Django to globally catch all exceptions and call
sys.excepthook. I'm telling you that's a bad idea -- I've tried it,
and it breaks a number of sites I have in production.

> All I'm asking for is sane defaults, and consistency between
> deployment platforms.  This isn't important?

>From where I stand the defaults are perfectly sane, and deployment is
demonstrably consistent -- Django does the same thing regardless of
where it's deployed. You're actually asking for the opposite: a
special case for mod_wsgi.

Can you explain to me why none of the exception hooks already put into
Django is sufficient? I've still not been able to glean that from your
posts.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: logging?

[Zain Memon]

Jogging also implements a lot of the ideas from Simon's logging proposal,
and can do what you're saying:

http://github.com/zain/jogging/

On Wed, May 5, 2010 at 12:33 PM, Mike Axiak  wrote:

> Why does this facility need to exist within Django? At least one
> person [1] has written a middleware to do what you're saying. If it's
> that important, people will start to use that app. There are certainly
> many potential features people want out of logging, so it'd definitely
> be better suited for an external app to bake.
>
> I'd say that the main issue here isn't with lack of logging, but with
> lack of a good one-stop Django app repository (DjangoZen [2] is a
> start, but missing a lot of functionality). Unfortunately I don't have
> time to maintain something like that.
>
> Cheers,
> Mike
>
> 1: http://github.com/djangrrl/django-logging-middleware
> 2: http://djangozen.com/
>
> On Wed, May 5, 2010 at 2:53 PM, Kevin Howerton 
> wrote:
> > Yeah... not sure, though thank you for actually reading and responding
> > to my post.
> >
> > "I think the problem you are having is more related to mod_wsgi, and
> > possible differences between it and mod_python, than Django."
> >
> > Absolutely.  Though, I'm not sure if it's the official recommendation
> > of django-project.com now or not, but most people in the community are
> > using mod_wsgi in Daemon mode.  It is definitely a result of this,
> > also I doubt mod_wsgi is going to be changing the nature of their
> > exception handling code faster than you guys can keep up.  It seems
> > like a pretty sweet setup right now so hopefully they don't change it
> > ;)
> >
> > Where django pulls a 500 it should call these two lines, which will
> > dump the exception raised to stderr.
> >
> >type, value, traceback = sys.exc_info()
> >sys.excepthook(type, value, traceback)
> >
> > If you have a logger setup, which I assume most sane people in
> > production do (right?!?).  You can pass the exception info to the
> > logger with and have the same result as one that passes straight to
> > stderr only you can have more explicit control over how it behaves,
> > especially if django uses named loggers:
> >
> >   logger.error("This can't be good", exc_info=True)
> >
> > We don't really need both, but either one should exist in django if
> > it's going to support wsgi ;)  Perhaps, I'm missing some config
> > setting available to mod_wsgi that will replicate mod_python's
> > behavior in this regard, but i "feel" django should work with a
> > default setup.
> >
> > Also, I've tested this on both Fedora 8, and mod_wsgi 2.x ... and the
> > latest 2.6.5 python + wsgi 3.2.
> >
> > "http://docs.djangoproject.com/en/dev/howto/error-reporting/";
> >
> > I can't use email reporting because of performance, logistics, and
> > sheer volume in production.
> >
> > -k
> >
> >
> > On Wed, May 5, 2010 at 1:51 PM, Karen Tracey  wrote:
> >> On Wed, May 5, 2010 at 12:46 PM, Kevin Howerton <
> kevin.hower...@gmail.com>
> >> wrote:
> >>>
> >>> What I was suggesting in my post though, was that we alter the default
> >>> CRITICAL error handling behavior ... as it stands (by default) all of
> >>> my ERRORs are being suppressed in production.  This is pretty
> >>> confusing for new users (there were 3 others in IRC with the same
> >>> complaint yesterday), and pretty un-pythonic IMO.  Unless I missed
> >>> something?
> >>
> >> I think you are missing something. From your earlier note you seem to be
> >> saying that it is information your own code is writing to stderr that is
> >> getting lost somewhere. Django does nothing to suppress anything sent do
> >> stderr. I've got views that write to stderr running under mod_wsgi, and
> the
> >> stderr output appears in the configured Apache error log. You do need to
> >> either include a newline in the data or explicitly flush stderr for the
> data
> >> to be written, and that may be a difference from mod_python (I don't
> >> remember enough about mod_python to say one way or the other). I think
> the
> >> problem you are having is more related to mod_wsgi, and possible
> differences
> >> between it and mod_python, than Django.
> >>
> >>>
> >>> At minimum the documentation should inform the user of this
> >>> short-coming, and provide a link to a wiki with the available
> >>> work-arounds.
> >>
> >> It isn't clear to me what shortcoming you think should be documented. If
> it
> >> is the behavior of mod_wsgi with respect to stderr possibly the
> deployment
> >> docs for mod_wsgi could mention something, but one danger of Django
> putting
> >> information like this in the docs is that it gets out of date as
> mod_wsgi
> >> evolves. In general it seems better to provide a minimum amount of
> >> information in Django doc, stuff that is specific to Django, and point
> the
> >> user to the appropriate source for authoritative documentation on the
> >> 3rd-party package.
> >>
> >> For the record, Django's default handling of critical errors when DEBUG
> is
> >> Fals

Re: Silently replaced session_key

[Matthew Roy]

How so? An exception here will be caught by the app or become a 500. That's
better than possibly using a chosen session key due to miscoding.

Matthew

On May 5, 2010 4:20 PM, "Jeremy Dunck"  wrote:

On Wed, May 5, 2010 at 2:45 PM, George Sakkis 
wrote:
...

> I'm repeating myself here but if the intention is to really disallow
> user-provided ids. it can b...
Allowing an attacker to predictably raise exceptions might be bad.


> By the way, this does not apply to all backends; file SessionStore for
> example uses passed ids ...
I filed a ticket for this: http://code.djangoproject.com/ticket/13478


-- 
You received this message because you are subscribed to the Google Groups
"Django developers" g...

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Silently replaced session_key

[Ulrich Petri]

Am 05.05.2010 um 21:45 schrieb George Sakkis:



I'm repeating myself here but if the intention is to really disallow
user-provided ids. it can be done more clearly: raise an exception if
the key does not exist and make the session_key property read-only.
Now it seems like a bug that you can sort of work around by setting
the key just before saving.




Depending on the backend it might be difficult to determine what  
exactly constitutes a non-existing key.
A visitor could for example have a stale session cookie in their  
browser that has already been evicted from your storage.
In such cases the user would be presented with an exception - not very  
friendly.


Ulrich

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Silently replaced session_key

[George Sakkis]

On May 5, 10:20 pm, Jeremy Dunck  wrote:
> On Wed, May 5, 2010 at 2:45 PM, George Sakkis  wrote:
>
> ...
>
> > I'm repeating myself here but if the intention is to really disallow
> > user-provided ids. it can be done more clearly: raise an exception if
> > the key does not exist and make the session_key property read-only.
> > Now it seems like a bug that you can sort of work around by setting
> > the key just before saving.
>
> Allowing an attacker to predictably raise exceptions might be bad.

The exception would not propagate of course all the way up the stack,
it would be caught by a caller that knows how to handle it (e.g.
middleware). In this way SessionStore backends would be responsible
only for the low level storage details, not the security policy. On
second thought though this is probably impractical since load() is
called implicitly the first time a dict-like method is called, so the
exception could be raised almost anywhere the session is first
accessed.

George

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: logging?

[Vinay Sajip]

On May 5, 8:33 pm, Mike Axiak  wrote:
> Why does this facility need to exist within Django? At least one
> person [1] has written a middleware to do what you're saying. If it's
> that important, people will start to use that app. There are certainly
> many potential features people want out of logging, so it'd definitely
> be better suited for an external app to bake.

I don't think his isn't just about logging for applications: I believe
it's also about logging events within Django itself, which cannot be
done using a middleware or app.

Logging events within Django would be useful for diagnosing certain
types of problems, e.g. those which happen during start-up, request
workflow internal to Django etc.

You don't need special middleware (or anything else) for logging
support in Django applications; the middleware or app is generally
used to do things such as presenting logging output as part of a page,
or to provide some Django-specific handlers (e.g. emailing via Django
configured mailer, rather than using logging's SMTPHandler) and
conventions for logging.

Regards,

Vinay Sajip

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: logging?

[Vinay Sajip]

On May 5, 5:56 pm, Jacob Kaplan-Moss  wrote:
> Then next time leave out the rambling, ad hominems, and sweeping
> generalizations. Focus on technical suggestions -- working code is
> even better. If you have problems, suggest fixes concretely.

To be fair, I'm not sure I saw any ad hominem attacks in Kevin's post
(do correct me if you think I'm wrong). He did disparage a point of
view which says that something must be suspect because of "perceived"
Java (or Ruby, or whatever...) heritage, without ascribing it to any
specific person or group.

Perhaps his comment was in response to some content in the original
thread which I referred to, which mentioned the "Java heritage" FUD.
This stems, it seems, from my acknowledging a debt to some good ideas
(not code) from log4j. I make no apologies for this; good ideas can
come from anywhere, not just Python or Django people. The logging PEP
and package were reviewed by numerous committers on Python-dev when
first proposed, and given the nod - so I don't understand how people
can still have doubts about it's "Pythonicity".

As for performance, there's a page on the Python Wiki (http://
wiki.python.org/moin/LoggingPackage) which provides some rough
performance metrics. I have yet to see any substantive criticisms
based on actual measurements.

Just sayin',

Vinay Sajip

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Django 1.2 release candidate available

[James Bennett]

Tonight we're proud to announce, finally, the first Django 1.2 release
candidate. If all goes well, it will also be the *only* release
candidate, and Django 1.2 final will release one week from today.

For more information, consult:

* The Django project weblog:
http://www.djangoproject.com/weblog/2010/may/05/12-rc-1/
* The release notes: http://docs.djangoproject.com/en/dev/releases/1.2-rc-1/

-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django 1.2 release candidate available

[Rajeev J Sebastian]

On Thu, May 6, 2010 at 10:10 AM, James Bennett  wrote:
> Tonight we're proud to announce, finally, the first Django 1.2 release
> candidate. If all goes well, it will also be the *only* release
> candidate, and Django 1.2 final will release one week from today.

Congrats on yet another great Django release!

When can we start discussing potential small/micro fixes for the next
version of django?

Regards
Rajeev J Sebastian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django 1.2 release candidate available

[James Bennett]

On Wed, May 5, 2010 at 11:53 PM, Rajeev J Sebastian
 wrote:
> When can we start discussing potential small/micro fixes for the next
> version of django?

A week or two after 1.2 final is released.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django 1.2 release candidate available

[Alex Gaynor]

On Thu, May 6, 2010 at 1:07 AM, James Bennett  wrote:
> On Wed, May 5, 2010 at 11:53 PM, Rajeev J Sebastian
>  wrote:
>> When can we start discussing potential small/micro fixes for the next
>> version of django?
>
> A week or two after 1.2 final is released.
>
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of correct."
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

You are however allowed to start earlier if you buy Russ and Karen a
drink, they deserve thanks for all the hard work they've put in.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django 1.2 release candidate available

[Rajeev J Sebastian]

On Thu, May 6, 2010 at 10:37 AM, James Bennett  wrote:
> On Wed, May 5, 2010 at 11:53 PM, Rajeev J Sebastian
>  wrote:
>> When can we start discussing potential small/micro fixes for the next
>> version of django?
>
> A week or two after 1.2 final is released.

Thanks!

Regards
Rajeev J Sebastian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django 1.2 release candidate available

[Rajeev J Sebastian]

On Thu, May 6, 2010 at 10:43 AM, Alex Gaynor  wrote:

>
> You are however allowed to start earlier if you buy Russ and Karen a
> drink, they deserve thanks for all the hard work they've put in.

Oh, I wouldn't miss a chance to make small talk over drinks with the
django gods :D

Regards
Rajeev J Sebastian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.