Hello everyone!
I've found a (may be minor) bug with logging and I'm not sure how it can
be fixed. Here's a stripped-down example showing the problem:
The settings.py simply configures a single root logger:
DEBUG = True
DATABASES = {
'default': {
'engine': 'django.
On Fri, Apr 15, 2011 at 12:30 AM, Jannis Leidel wrote:
> On 14.04.2011, at 17:27, Jacob Kaplan-Moss wrote:
>
>> I think I agree with Ned here: I can't see the downside to fixing it
>> on the release branch. "It violates our policy" doesn't count IMO:
>> it's *our* policy, and we get to break it if
At loggly, we just have a get_request function called by our logging
handlers which digs up through the stack and grabs a request object
from the view. It's not too pretty, but it works.
-Mike
On Thu, Apr 14, 2011 at 5:21 AM, Russell Keith-Magee
wrote:
> On Thu, Apr 14, 2011 at 6:01 AM, Shawn Le
Ok, I created a ticket to track the Babel integration:
http://code.djangoproject.com/ticket/15832
On 14 April 2011 21:47, Jannis Leidel wrote:
>
> I'm not convinced it's much more work, since we really only need to
> replace the string extraction code in makemessages and the
> compilation code in
On 14.04.2011, at 20:09, Łukasz Rekucki wrote:
> On 14 April 2011 18:30, Jannis Leidel wrote:
>> On 14.04.2011, at 17:27, Jacob Kaplan-Moss wrote:
>>
>>> I think I agree with Ned here: I can't see the downside to fixing it
>>> on the release branch. "It violates our policy" doesn't count IMO:
>>
On 14 April 2011 18:30, Jannis Leidel wrote:
> On 14.04.2011, at 17:27, Jacob Kaplan-Moss wrote:
>
>> I think I agree with Ned here: I can't see the downside to fixing it
>> on the release branch. "It violates our policy" doesn't count IMO:
>> it's *our* policy, and we get to break it if there's a
On 14.04.2011, at 17:27, Jacob Kaplan-Moss wrote:
> I think I agree with Ned here: I can't see the downside to fixing it
> on the release branch. "It violates our policy" doesn't count IMO:
> it's *our* policy, and we get to break it if there's a good reason.
> Making translation in JavaScript wor
On Apr 14, 3:51 pm, Jannis Leidel wrote:
> Yeah, please open a ticket, this is defintiely something we need to document
> since the behaviour changed in 1.3.
I opened #15830 (http://code.djangoproject.com/ticket/15830).
Thanks Jannis.
--
You received this message because you are subscribed to
Hey all --
I think I agree with Ned here: I can't see the downside to fixing it
on the release branch. "It violates our policy" doesn't count IMO:
it's *our* policy, and we get to break it if there's a good reason.
Making translation in JavaScript work is a good reason as I see it.
Jannis: can yo
On 4/14/2011 10:30 AM, Jannis Leidel wrote:
On 14.04.2011, at 15:54, Ned Batchelder wrote:
On 4/14/2011 9:26 AM, Jannis Leidel wrote:
On 14.04.2011, at 14:41, Ned Batchelder wrote:
Does anyone else have any opinions on a direction forward to fix this problem?
At the very least I'd like to
On 14.04.2011, at 15:54, Ned Batchelder wrote:
> On 4/14/2011 9:26 AM, Jannis Leidel wrote:
>> On 14.04.2011, at 14:41, Ned Batchelder wrote:
>>
>>> Does anyone else have any opinions on a direction forward to fix this
>>> problem? At the very least I'd like to make a doc patch for 1.3.1 that
On 4/14/2011 9:26 AM, Jannis Leidel wrote:
On 14.04.2011, at 14:41, Ned Batchelder wrote:
Does anyone else have any opinions on a direction forward to fix this problem?
At the very least I'd like to make a doc patch for 1.3.1 that explains the
fragility.
Yeah, a doc patch sounds like a go
On 14.04.2011, at 15:36, Fidel Ramos wrote:
> On Apr 14, 1:52 pm, Ramiro Morales wrote:
>> On Thu, Apr 14, 2011 at 7:51 AM, Fidel Ramos wrote:
>>> I included some fields from localflavor.es.forms in a project, and
>>> expected the error messages to appear translated, as localflavor
>>> already
On Apr 14, 1:52 pm, Ramiro Morales wrote:
> On Thu, Apr 14, 2011 at 7:51 AM, Fidel Ramos wrote:
> > I included some fields from localflavor.es.forms in a project, and
> > expected the error messages to appear translated, as localflavor
> > already has a catalog. However the messages only appeared
On 14.04.2011, at 14:41, Ned Batchelder wrote:
> Does anyone else have any opinions on a direction forward to fix this
> problem? At the very least I'd like to make a doc patch for 1.3.1 that
> explains the fragility.
Yeah, a doc patch sounds like a good plan.
Jannis
--
You received this me
On Thu, Apr 14, 2011 at 8:16 PM, Peter Portante
wrote:
> Looking at line 153 of django/views/decorators/http.py (rev [15927]),
> I just see "return inner". Is there a particular reason why it should
> not be: "return wraps(func, assigned=available_attrs(func))(inner)"?
I suspect it's just histori
On 14.04.2011, at 15:01, Łukasz Rekucki wrote:
> On 14 April 2011 14:41, Ned Batchelder wrote:
>> Does anyone else have any opinions on a direction forward to fix this
>> problem? At the very least I'd like to make a doc patch for 1.3.1 that
>> explains the fragility.
>
> I'm +1 on fixing it no
+1 from the Tabblo group remnants.
On Thu, Apr 14, 2011 at 8:41 AM, Ned Batchelder wrote:
> Does anyone else have any opinions on a direction forward to fix this
> problem? At the very least I'd like to make a doc patch for 1.3.1 that
> explains the fragility.
>
>
--
You received this message
On 14 April 2011 14:41, Ned Batchelder wrote:
> Does anyone else have any opinions on a direction forward to fix this
> problem? At the very least I'd like to make a doc patch for 1.3.1 that
> explains the fragility.
I'm +1 on fixing it now, rather then later. The regex approach was a
bad idea i
Looking at line 153 of django/views/decorators/http.py (rev [15927]),
I just see "return inner". Is there a particular reason why it should
not be: "return wraps(func, assigned=available_attrs(func))(inner)"?
--
You received this message because you are subscribed to the Google Groups
"Django de
Does anyone else have any opinions on a direction forward to fix this
problem? At the very least I'd like to make a doc patch for 1.3.1 that
explains the fragility.
--Ned.
On 4/9/2011 1:02 PM, Ned Batchelder wrote:
On 4/9/2011 11:57 AM, Jannis Leidel wrote:
On 09.04.2011, at 17:32, Ned Batc
On Thu, Apr 14, 2011 at 6:01 AM, Shawn Lewis wrote:
> Hi,
> Is there an idiomatic way to tie messages from a single request together
> with 1.3's new logging features? From the documentation it doesn't look like
> there is. Something like what drlog does
> (http://fairviewcomputing.com/blog/2008/0
On Thu, Apr 14, 2011 at 7:51 AM, Fidel Ramos wrote:
> I included some fields from localflavor.es.forms in a project, and
> expected the error messages to appear translated, as localflavor
> already has a catalog. However the messages only appeared in English.
>
> Turns out the localflavor catalog
I included some fields from localflavor.es.forms in a project, and
expected the error messages to appear translated, as localflavor
already has a catalog. However the messages only appeared in English.
Turns out the localflavor catalog is not automatically loaded, it must
be included manually in t
24 matches
Mail list logo
