On Oct 11, 2:32 am, Simon Willison wrote:
> Is there a straight forward solution to this that I've been missing,
> or is it an ongoing problem? If it's a problem, can we fix it? What
> makes it so difficult to fix (I'm going to guess there's no easy
> solution, or we would have sorted it out ages
I'm now tracking the logging implementation in ticket #12012:
http://code.djangoproject.com/ticket/12012
I've started posting patches from my branch there. Again, this is just
exploratory code at the moment but I'm keen to receive as much
feedback on the implementation as possible.
--~--~---
On Oct 11, 2:32 am, Simon Willison wrote:
> Alternatively, should I just stick my log configuring code in the
> Setting class constructor and leave well alone?
For the moment, I've done exactly that:
http://github.com/simonw/django/commit/eb9737129501a6d17014afdb55c8bb4d5222b693
Full patch aga
I've got to the point in the logging implementation where I want to
add support for logging related settings in settings.py.
The current idea (suggested by Ivan Sagalaev) is to allow for a
standard Django-style setting that look something like this:
LOGGING = {
'django.db.sql': {
'
On Sat, Oct 10, 2009 at 7:03 PM, veena wrote:
> Today I was on very bad wifi connection. Constantly dropped. 20
> seconds to load a page.
> I save in admin in two tabs and got a notice in one tab from the other
> tab.
>
> But I agree, I defer this "bug" for the first release od django
> messaging
On Sat, Oct 10, 2009 at 8:21 PM, Russell Keith-Magee wrote:
> One thought that has occurred to me is that rather than using msg as
> the complete literal error string, we could use it as a prefix to the
> literal.
>
> i.e., to take line 124 that you used as an example:
>
> > def assertFormError(s
On Sat, Oct 10, 2009 at 1:16 AM, Christian Oudard
wrote:
>
> First off, thank you all for responding and discussing this issue.
>
> Responding to Russell's comments on the quality of the patch, I agree
> that it needs better test coverage. I've uploaded an updated patch
> which covers all exit po
On Sun, Oct 11, 2009 at 6:19 AM, Hanne Moa wrote:
>
> On Sat, Oct 10, 2009 at 13:51, Russell Keith-Magee
> wrote:
>> Looking at #3591 in particular - another big part of the problem is
>> that the ticket tries to solve a theoretical problem that, in
>> practice, doesn't really exist - that of na
Today I was on very bad wifi connection. Constantly dropped. 20
seconds to load a page.
I save in admin in two tabs and got a notice in one tab from the other
tab.
But I agree, I defer this "bug" for the first release od django
messaging. I think django isn't now in right mood to add there some
f
On Sat, Oct 10, 2009 at 6:44 PM, Hanne Moa wrote:
> The suggested API: how hard will it be to use different message-types
> in addition to the syslog-like ones?
I think it should definitely be easy, if not actively encouraged. IMO
those constants should just be strings, or integers which can ea
On Sat, Oct 10, 2009 at 19:53, Tobias McNulty wrote:
> I should have also added:
>
> * Coming to consensus on a de facto standard API suitable for
> inclusion in Django
The suggested API: how hard will it be to use different message-types
in addition to the syslog-like ones? I use django-notify
On Sat, Oct 10, 2009 at 13:51, Russell Keith-Magee
wrote:
> Looking at #3591 in particular - another big part of the problem is
> that the ticket tries to solve a theoretical problem that, in
> practice, doesn't really exist - that of namespace collisions in
> applications.
That's funny, has hap
I'd love to see this change get put in. I think the most common case
for forms is to trim whitespace, not the other way around. I'd rather
have the extra work come in for the rare case (when you wanted to
preserve leading/trailing spaces).
-Taylor
On Oct 10, 11:37 am, Barry Pederson wrote:
>
On Oct 10, 2:04 pm, Ned Batchelder wrote:
> My strong feeling is that these two goals will quickly become impossible
> to reconcile. I think the idea of a conference site is a good one
> (everyone will understand the problem domain, lots of interesting
> avenues to explore, it's not yet-another-
> * We should de-emphasize the "apps live inside of projects" thing.
+1 on that. In fact I wonder whether we should in fact emphasize just
the opposite -- that apps should *not* live inside of projects. I get
that one of the purposes of the tutorial is to get you up and running
fast, but when so
On Sat, Oct 10, 2009 at 2:05 PM, David Cramer wrote:
> The proposal per your email is more or less how django-notices works.
For comparison I added django-notices to the Available Options:
http://code.djangoproject.com/wiki/SessionMessages#AvailableOptions
--
Tobias McNulty
Caktus Consulting
The proposal per your email is more or less how django-notices works.
Sent from my iPhone
On Oct 10, 2009, at 12:53 PM, Tobias McNulty
wrote:
>
> On Sat, Oct 10, 2009 at 1:19 PM, Tobias McNulty > wrote:
>> Things that still need to be discussed/done:
>>
>> * Coming to consensus on what 3rd pa
On Sat, Oct 10, 2009 at 1:19 PM, Tobias McNulty wrote:
> Things that still need to be discussed/done:
>
> * Coming to consensus on what 3rd party app we actually choose to
> extend/modify to fit into Django
>
> * What to do with the existing user message API (see
> http://code.djangoproject.com/w
In hopes of jump starting this conversation once again, I made some
significant changes to the wiki page that try to sum up the state of
the conversation so far in a better way:
http://code.djangoproject.com/wiki/SessionMessages
Things that still need to be discussed/done:
* Coming to consensus
On Sat, Oct 10, 2009 at 6:04 AM, Ned Batchelder wrote:
> My strong feeling is that these two goals will quickly become impossible to
> reconcile. I think the idea of a conference site is a good one (everyone
> will understand the problem domain, lots of interesting avenues to explore,
> it's not
On Sat, Oct 10, 2009 at 9:11 AM, Vinay Sajip wrote:
>
>
>
> On Oct 10, 1:56 pm, Simon Willison wrote:
>> I just hacked in a logger that increments a counter for every message
>> - it indicates that there are 158,527 SQL statements executed by the
>> test suite, which means we should expect to ad
On May 13, 2:56 am, Russell Keith-Magee
wrote:
>On Wed, May 13, 2009 at 7:48 AM, thebitguru wrote:
>> Hi,
>> What do we need to make a decision for ticket 6362 (http://
>> code.djangoproject.com/ticket/6362)?
> We need to wait until we're not trying to get v1.1 out the door.
> We are w
> The tutorial is extremely important. It will be the first part of the
> docs read by 98% of new users. Don't complicate it by tying it to
> DjangoCon. This thread has already seen requests for features that
> will be great for real use, but would probably be too much to put into
> a tuto
Ned,
You really ought to show us all how to use that time machine. :)
On Oct 10, 2009, at 8:49 AM, Ned Batchelder
wrote:
>
> +1
>
> http://nedbatchelder.com/blog/200908/humane_email_validation.html
>
> I was going to kibbitz on the fix (removing a single * would have
> sufficed), and real
On Sat, Oct 10, 2009 at 9:35 PM, James Bennett wrote:
>
> In light of yesterday's security issue, I'd like to propose that we
> significantly dumb down the regex Django uses to validate email
> addresses.
>
> Currently, the regex we use covers many common cases, but comes
> nowhere near covering
+1
http://nedbatchelder.com/blog/200908/humane_email_validation.html
I was going to kibbitz on the fix (removing a single * would have
sufficed), and realized we were once again in the quagmire of email
regex validation.
--Ned.
James Bennett wrote:
> In light of yesterday's security issue, I
In light of yesterday's security issue, I'd like to propose that we
significantly dumb down the regex Django uses to validate email
addresses.
Currently, the regex we use covers many common cases, but comes
nowhere near covering the entire spectrum of addresses allowed by the
RFC; several tickets
On Oct 10, 1:56 pm, Simon Willison wrote:
> I just hacked in a logger that increments a counter for every message
> - it indicates that there are 158,527 SQL statements executed by the
> test suite, which means we should expect to add slightly over a second
> to the time taken for the overall u
On Oct 10, 12:51 pm, Russell Keith-Magee
wrote:
> It isn't just a matter of core developers not having enough time to
> review a specific patch - it's that there is a lot more design work
> required.
[snip]
> In the case of #3591, there is still a lot of design work required.
> That design disc
Russell Keith-Magee wrote:
> On Sat, Oct 10, 2009 at 6:55 AM, Rob Hudson wrote:
>
>> I, too, like the idea of a conference site. It fills a void and
>> sounds useful for upcoming conferences. I wasn't too crazy about the
>> blog idea, and was convinced away from the snippets idea. So shall w
On Oct 10, 1:41 pm, Simon Willison wrote:
> Oops, yes you're right - I misread the numbers. A 2.5 second different
> would correspond to around 350,000 log messages (assuming the rate of
> 130,000/second from my microbenchmark) - I have no idea how many
> statements the unit tests execute in tota
On Oct 10, 12:55 pm, Luke Plant wrote:
> > master: 314.442s
> > logging: 317.096s
>
> > Since there's nothing at all in my logging code that will speed
> > anything up, I'm putting that down to chance (I did run the suite a
> > few times first to "warm up" the VM I used, but like I said, this
> >
On Saturday 10 October 2009 07:31:31 Simon Willison wrote:
> master: 314.442s
> logging: 317.096s
>
> Since there's nothing at all in my logging code that will speed
> anything up, I'm putting that down to chance (I did run the suite a
> few times first to "warm up" the VM I used, but like I sai
On Sat, Oct 10, 2009 at 5:11 PM, Vinay Sajip wrote:
>
>> While it may not be *technically* too late to get the feature on the
>> voting list, my Magic 8-ball predicts that any vote on #3591 will have
>> the same result as last time - Rejected, needs more design work.
>>
>> All the serious proposa
> While it may not be *technically* too late to get the feature on the
> voting list, my Magic 8-ball predicts that any vote on #3591 will have
> the same result as last time - Rejected, needs more design work.
>
> All the serious proposals for v1.2 on the wiki have had extensive (and
> recent) di
35 matches
Mail list logo
