Re: #12012 Logging: Final call for comments

[Kevin Howerton]

Definitely agree.  Caught the missing nullhandler behavior when
logging is off too... though didn't make the connection that this was
likely intended to handle that case.

It might make more sense to put this logic in conf/__init__.py
following the calls to configure the logger.  Though that doesn't
really matter as the handler could only be added once anyhow.

ie:

logger = logging.getLogger('django')
if not logger.handlers:
   logger.addHandler(NullHandler())

Also didn't realize that adding a nullhandler to just the root logger
would remove those warnings (pretty cool)... ended up writing a bit
that adds a nullhandler to any logger without handlers for my
implementation in lumberjack... woops.

-k

On Fri, Oct 1, 2010 at 8:35 PM, Vinay Sajip  wrote:
>
>
> On Oct 1, 7:06 am, Russell Keith-Magee 
> wrote:
>>
>> These are fairly minor modifications, so I'm still intending to commit
>> early next week, barring major objections.
>>
>
> As per my answer to Kevin - I think a NullHandler addition to the
> 'django' logger needs to happen internally (not under a site
> developer's control) and the 'null' handler should be removed from the
> examples (as it won't be needed any more). That should make the
> configuration dictionary even simpler :-)
>
> 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: #12012 Logging: Final call for comments

[Kevin Howerton]

Hey...

Discussed with Russell on IRC ... line 21 of log.py...

# Ensure the creation of the Django logger
logger = logging.getLogger('django')

I guess it's trying to check if the logger exists?  The getLogger
method will actually never fail (as far as I'm aware), as nothing
actually happens until you try to push a message to the handler(s) of
that logger... and at that point you will get a warning if the logger
doesn't have handlers associated with it.

I came up with this to check if a logger exists and has been setup,
you can test for the existence of handlers... ie:

logger = logging.getLogger('adsf')
if not logger.handlers:
dictConfig(settings.LOGGING)

I feel like that check is unnecessary anyhow... but I guess that's how
you'd do it if it is necessary.

-k

On Fri, Oct 1, 2010 at 8:54 AM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote:
> On Oct 1, 3:45 am, Kevin Howerton <kevin.hower...@gmail.com> wrote:
>> Regarding the 'version' setting.. .is that in the python 2.7
>> implementation?  I ended up removing it from the included
>> logging-config in lumberjack as it wasn't really doing much.
>
> Yes, it's required so that we can introduce schema changes in future
> Python versions without breaking backwards compatibility. It's best to
> leave it in, it's just an extra line after all.
>
> 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: Error email flooding on high traffic production sites

[Kevin Howerton]

I feel like something like this would be better suited to be in an
external application... since it will fail without a cache-backend.

Also, the implementation will have to change as Russell is about to
commit a logging patch with ticket #12012.

This would be best suited though for a custom handler in an external
app going forward... I will likely add something of this nature to one
of lumberjack's backends (aggregation of some-sort).

-k

On Thu, Sep 30, 2010 at 6:47 AM, Andrew Wilkinson
 wrote:
> Hi,
>
> Sorry the digging up an old thread, I'm a bit behind on my reading of
> django-dev.
>
> I have a patch in the bug tracker that fixes this exact problem -
> http://code.djangoproject.com/ticket/11565. The patch is just over a
> year old now so it might not apply that cleanly to the current trunk.
>
> The patch works by caching an MD5 of the traceback for each error with
> a timeout of settings.ERROR_EMAIL_RATE_LIMIT minutes. This prevents
> the same error being sent more than once in the time. It's not perfect
> because a single error might cause multiple tracebacks and you'd get
> one email for each distinct one. It's definitely better than the
> current situation though. It also relies on you having a cache backend
> set up.
>
> Unfortunately I never did get time to write unittests for it, and
> unittesting something like this is quite hard because of the timeout
> involved.
>
> Hope this is useful,
> Andrew
>
> On Thu, Sep 9, 2010 at 4:26 AM, Simon Litchfield  wrote:
>> Hi all
>>
>> Default behaviour of sending an email on 500 error is great.
>>
>> Problem is on high traffic sites, and you might just be making a quick
>> update- literally within seconds you can bring your mail server down-
>> crash your mail client- or render your gmail account useless.
>>
>> With "batteries included" and "production ready" ethos in mind, I
>> reckon this needs fixing.
>>
>> 1) Max emails per minute setting
>>
>> 2) Include alternative error handler middleware in core
>>
>> I haven't tried it yet, but this looks interesting (note web2py
>> includes this) --
>> http://bitbucket.org/ashcrow/django-error-capture-middleware/wiki/Home
>>
>> Thoughts? I know I'm not the only one who has run into this (Russ?)
>>
>> Cheers
>> Simon
>>
>> --
>> 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.
>
>

-- 
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: #12012 Logging: Final call for comments

[Kevin Howerton]

re: verbose logging configuration.

This bothered me as well initially, though after starting to use
logging extensively I realized that there isn't really a more concise
way to provide all of the features that the logging config brings to
the table.

We can however, create a very concise default setup that mimics the
current admin-email behavior and provide additional documentation on
having more complex setups on djangoproject.com

ie:
LOGGING = {
'handlers': {
 'mail_admins': { 'level': 'ERROR',  'class':
'django.utils.log.AdminEmailHandler' }
}
'loggers': {
'django': { 'handlers': ['mail_admins'], 'level':
'ERROR', 'propagate': True }
}
}

Regarding the 'version' setting.. .is that in the python 2.7
implementation?  I ended up removing it from the included
logging-config in lumberjack as it wasn't really doing much.

I'm really pretty excited about this making it into 1.3... Thanks
guys!  I haven't looked at the code extensively, but it looks really
good (a lot of improvements over what I had).  I will take it for a
test drive this weekend though.

-k


On Thu, Sep 30, 2010 at 8:41 PM, Russell Keith-Magee
 wrote:
> On Fri, Oct 1, 2010 at 1:53 AM, Andy McCurdy  wrote:
>> Russ,
>> This will be a welcomed addition to debugging Django apps. I have a question
>> about startup.py. I notice that startup runs after settings are loaded, but
>> before models. Does this mean that code within startup.py cannot safely
>> access the ORM? If the ORM is fully accessible in startup.py, it's safe to
>> ignore the rest of the mail.
>
> The startup.py proposal has been dropped from the RC version of this patch.
>
> I still believe that there is a strong need for a 'startup logic'
> entry point, but it isn't required for the purposes of logging, and
> there is a significant overlap with the concerns of the AppCache
> refactor that was the subject of a SoC project this year. Rather than
> introduce an interface that wasn't strictly needed and was potentially
> going to be deprecated in the next release, we have opted to leave out
> this piece of functionality.
>
> 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.
>
>

-- 
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: Error email flooding on high traffic production sites

[Kevin Howerton]

Lumberjack is basically a backport of what I'd like built-in logging
support to be.  I also have it built-in to django on my experimental
branch on github...

To over-ride the default email behavior just turn on the 500handler
view in lumberjack.  This is what I perceive as the best method of
catching errors currently, as catching them with signals or middleware
can be troublesome.  If there is an error in your middleware or
signal, the error signal will fail to receive the error and it will
just push out to stderr.

We are currently using lumberjack on a very high traffic website for
just this purpose.  We are just using the stream handler and having
apache catch the errors, though I have tested all of the other
handlers that come with lumberjack on smaller sites.  I also just
added support for arecibo... and the flexibility of the python logging
system allows you to use multiple handlers ... pushing to arecibo,
database, and file all at the same time are possible for example.

I'm also currently working on a tool that will push the errors to a
message queue and then have them be pushed out with websockets...
which I think will be useful for development and staging servers for
debugging.  Though this is more of a poor excuse for me to work with
websockets and rabbitmq, I think it could be useful.  Thoughts?

Anyhow... here's the current project...  If anyone has feature
requests... feedback.. criticism ... i'm always game.

http://github.com/kevin/django-lumberjack

On Thu, Sep 9, 2010 at 5:06 AM, Russell Keith-Magee
 wrote:
> On Thu, Sep 9, 2010 at 11:26 AM, Simon Litchfield  wrote:
>> Hi all
>>
>> Default behaviour of sending an email on 500 error is great.
>>
>> Problem is on high traffic sites, and you might just be making a quick
>> update- literally within seconds you can bring your mail server down-
>> crash your mail client- or render your gmail account useless.
>>
>> With "batteries included" and "production ready" ethos in mind, I
>> reckon this needs fixing.
>>
>> 1) Max emails per minute setting
>>
>> 2) Include alternative error handler middleware in core
>>
>> I haven't tried it yet, but this looks interesting (note web2py
>> includes this) --
>> http://bitbucket.org/ashcrow/django-error-capture-middleware/wiki/Home
>>
>> Thoughts? I know I'm not the only one who has run into this (Russ?)
>
> This exact problem is the reason why adding logging support is on my
> todo list for 1.3. Essentially, the idea is that by merging Vinay's
> logging work, the current behavior of 'send an email on server error'
> can become a configuration item; the default configuration would be to
> send an email (for backwards compatibility), but this setting could be
> easily modified to be 'write to a file', 'write to syslog', 'post to
> Arecibo', 'write to database', or any other logging handler you care
> to write and install -- potentially multiple handlers, if required.
>
> If you want to keep email error handling but want to avoid the
> problems you describe, you can then write (and install) a custom error
> logging handler that has the properties you describe.
>
> 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.
>
>

-- 
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: 1.3: Start deprecating mod_python?

[Kevin Howerton]

Could be good to include some text about using the python loggers on
that WSGI debug page, rather than relying on the apache logging
mechanisms.

In django land ... there's django-devserver, django-debugtoolbar, and
django-lumberjack.

All of them more or less share the same profilers and such.  The only
differences being that devserver targets the terminal, debugtoolbar
targets the in browser toolbar, and lumberjack tries to be a bit more
flexible and uses python-logging.

-k

>
> Once I have reviewed what other profiler options may exist and the
> pros and cons of each, I am likely to include a section on using
> profiling tools in:
>
>  http://code.google.com/p/modwsgi/wiki/DebuggingTechniques
>
> So people could always go there.
>
> Graham
>
> --
> 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: MySQL index hints

[Kevin Howerton]

> For a very high traffic project backed by 20+ DB servers
Slightly OT, but MySQL performance related...

If you are write heavy, there's another issue that I imagine would
bring significant gains on a MyISAM setup of that proportion... and
possibly other databases to a lesser degree (the locking mechanisms
with MyISAM are different).

Basically, right now the ORM will UPDATE or INSERT based off of a
SELECT query it does when you hit save().  So even if the ORM should
already know it's an UPDATE it will run this logic and these queries.

There's "force_update=True" which I imagine would skip the SELECT, but
I was looking into it because the logic here has some other
side-effects as well.

One of the side effects is that if you change a PK, and try to save it
you end up with two rows.  I guess the PK probably shouldn't be
mutable, or we can fix that logic and possible see some gains in
speed.

I have some tests somewhere to try and illustrate how MyISAM locks,
and there might be a couple open tickets relating to side effects...
if there's any interest... kind of waiting until things settle with
the refactor, as I have some ideas I want to try out.

-k

-- 
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: Imports in the tutorial

[Kevin Howerton]

"I agree, and while we're at it also change the settings.py template to
just point to urls instead of project_name.urls"

Indeed, always the first thing I change when I start a project...
Having the project_name there means you are including the directory
above your project in the python path in your wsgi setup, which is not
needed and can cause name collisions and what-not.

-k

-- 
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: Beating on an old issue; counter intuitive cascade deletes on foreign keys

[Kevin Howerton]

This abstract base class likely is a bit less performant than having
in-db support for cascades in pgsql... though it should give you the
behavior you are seeking.

It should set to default, or null if allowed.

Enjoy.

-k

class ClearOnDelete(models.Model):
   def delete(self):
   related_objects = self._meta.get_all_related_objects()
   for object in related_objects:
   accessor_name = object.get_accessor_name()
   related_accessor = getattr(self.__class__, accessor_name)
   related_accessor_instance = getattr(self, accessor_name)

   if related_accessor.related.field.default is not NOT_PROVIDED:
   for relation in related_accessor_instance.all():
   setattr(relation,
related_accessor.related.field.name,
related_accessor.related.field.default)
   relation.save()

   elif related_accessor.related.field.null:
   for relation in related_accessor_instance.all():
   setattr(relation, related_accessor.related.field.name, None)
   relation.save()
   super(ClearOnDelete, self).delete()

   class Meta:
   abstract = True

-- 
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: exception handling memory leak...

[Kevin Howerton]

This was not a "hey you guys are lazy", actually came across it ...
after I had fixed the same issue.

I just posted a patch for you generated off trunk... and left a
hopefully somewhat entertaining explanation of the details surrounding
the issues.

-k

-- 
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.

exception handling memory leak...

[Kevin howerton]

http://code.djangoproject.com/ticket/10758

Can we fix this?  It's a pretty easy fix.

thanks,

-k

-- 
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 in Django

[Kevin howerton]

I added a AdminEmailHandler to my branch and pulled the upstream
changes.

http://github.com/kevin/django-experimental/

It now behaves very close to how django-trunk does on exception ... by
default there is a streamhandler pushing to stderr and the admin email
handler pushing emails to admins.

The sql logging is also integrated into the debug cursor as I don't
really know of any reason why you'd want to have it logging sql
outside of debug-mode.  Also, the sql is unformatted ... Though you
can grab the sql formatter from lumberjack and pygments to see it in
it's full glory.

-k

-- 
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 in Django

[Kevin howerton]

Well, that was just to demonstrate the point that you can have a
really simple minimalist configuration if that's what you want... not
that it's preferable or recommended or anything.. just that if you
need/want simplicity in configuration it's there.

Also, it won't end up in log/messages if that's what you assumed ...
it should be caught by the default apache loggers at minimum, or be
sent to your vhost log if you have logging setup per virtual host.

-k

On May 28, 8:30 pm, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote:
> On May 28, 10:27 pm, Kevin howerton <kevin.hower...@gmail.com> wrote:
>
> > Indeed, though that config does exactly that with apache ... the
> > streamhandler by default spits everything out to stderr which is in
> > turn picked up by apache's logging.
>
> True, but your logging output's then interspersed with everything else
> that writes to stderr - not ideal.
>
> 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 in Django

[Kevin howerton]

"Yes, something like that is a fairly minimal configuration, but
generally I've found a file-based log to be pretty much part of every
site's requirement, for anything but the smallest (toy) site."

Indeed, though that config does exactly that with apache ... the
streamhandler by default spits everything out to stderr which is in
turn picked up by apache's logging.

btw...

My implementation of logging is here:
http://github.com/kevin/django-experimental

and a flushed out demo of what a third party app that utilizes python
logging is here (basically just django-devserver with some extra
pizzaz thanks to pygments and zain's jogging handlers):
http://github.com/kevin/django-lumberjack

-- 
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 in Django

[Kevin howerton]

I see the utility of being able to have additional ways to setup the
logging, though as it is I think the biggest issue people have with
the logging stuff is that the dictconfig is already fairly
intimidating looking.  If someone really wants to disable the default
setup of logging, it should be as simple as flipping a setting, then
calling their own loggers by hand in settings or __init__.

I think primarily the first goal should be with the logging stuff to
do like Russ detailed, and replicate the current functionality of the
exception handling and admin emails.

I'd also be curious as to if you guys think it would be a good idea to
integrate the messages framework with python logging.  It seems like
it follows a similar paradigm, though there might be some snaffu's
with trying to get access to the request object in a handler/logger.

And though we've been showing mostly complex fancy examples to demo
the power of the dictconfig stuff ... you can actually make really
simple concise configurations as well.

ie:

config = {
 'handlers':{'stream':{'level':'DEBUG',
'class':'logging.StreamHandler',},
 },
 'loggers':{
'django':{'handlers':['stream']},
 }
}

My current branch of django-experimental has a working implementation
of the exception handling and query logging (lifted from simon's
initial proposal).

There is also a proof of concept project I started called django-
lumberjack that will work in 1.2 to demo how the handlers, backends,
and formatters can be integrated with current profiling, debugging
tools we use.  I took the middlewares from dcramer's devserver
project, and the handlers from zain's jogging.  I haven't tested the
email handlers, though the pygmented terminal output of exceptions and
queries should be working out of the box.

-k


On May 28, 12:46 pm, Vinay Sajip  wrote:
> On May 28, 4:48 pm, Russell Keith-Magee 
> wrote:
>
>
>
>
>
> > Following some discussion at the DjangoCon.eu sprints, here's what
> > we've got on the table regarding adding logging support to Django.
>
> > The core of Vinay's work is essentially ready to go -- the logging
> > configuration code is an implementation of what has been accepted as a
> > PEP, so there's no reason for us to use anything else.
>
> > As for landing this in trunk - the consensus is that this should be
> > done in two parts:
>
> > The first commit will be the the actual core logging infrastructure -
> > the logging config parsing module, and the hooks to get a logging
> > configuration parsed and installed.
>
> > The second commit will be the addition of actual logging. The
> > intention here is to be initially conservative; two immediate targets
> > would be to replace calls to mail_admins() with logging calls, and
> > replacing debug messages in management commands with their logging
> > equivalent.
>
> Makes sense.
>
> > At this point, it largely becomes a political problem -- we don't want
> > Django's core to get bogged down in trivial logging calls, so we need
> > to develop our policy on when we add a logging statement to trunk, and
> > at what trace level, and so on. Of course, none of this prevents end
> > users from putting whatever logging they want into their own code. It
> > also doesn't prevent the core logging code and initial logging calls
> > being added to trunk; we can develop the logging policy over time once
> > the core is in place.
>
> > On a technical level, the only issue that needs resolving is the issue
> > of how to trigger configuration of logging in the first place. The
> > current patch implements this using signals (a bootstrap plus pre/post
> > model load signals). The consensus at the sprints is that we should
>
> They're not of course signals in the dispatcher sense - just ordinary
> functions which get called back directly from the framework code.
>
> > take this opportunity to kill an old request -- 'startup' handling.
>
> > Under this proposal, startup would look like this:
>
> >  * Once settings have been successfully imported, logging is
> > configured based on settings.LOGGING. This guarantees that logging
> > will always be configured, rather than relying on users successfully
> > invoking logging in their own settings file or similar. This will
> > essentially replace the BOOTSTRAP_CALLBACK in Vinay's current patch.
> >  * We then look for a 'startup.py' in each app included in
> > INSTALLED_APPS, and import that module. This is the replacement for
> > (PRE|POST)_MODEL_CALLBACKS in Vinay's current patch
>
> Replacing the BOOTSTRAP_CALLBACK with auto-configuring logging via the
> LOGGING setting will of course work, but not be as flexible as things
> are at present. You won't be able to do anything else at that time -
> you just get logging configured for you, under the hood. Now that
> isn't a problem since the dictConfig API should handle all of the
> common and less-common scenarios, but if a user had a valid reason for
> 

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 <kmtra...@gmail.com> 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
> 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?

[Kevin Howerton]

I did.

On Wed, May 5, 2010 at 12:56 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> On Wed, May 5, 2010 at 11:48 AM, Kevin Howerton
> <kevin.hower...@gmail.com> 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?

[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 <vinay_sa...@yahoo.co.uk> wrote:
>
> On May 5, 4:47 am, Kevin Howerton <kevin.hower...@gmail.com> 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 <vinay_sa...@yahoo.co.uk> wrote:
>
> On May 5, 4:47 am, Kevin Howerton <kevin.hower...@gmail.com> 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 <vinay_sa...@yahoo.co.uk> wrote:
>
> On May 5, 4:47 am, Kevin Howerton <kevin.hower...@gmail.com> 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.

logging?

[Kevin Howerton]

Realized today that by default django more or less suppresses errors
sent to stderr when debug is off.  Well I guess it uses email sent to
admins by default.  Though, I distinctly remember stderr being sent
into my apache logs for some reason.  Maybe this was when I was using
mod_python rather than mod_wsgi?

I think that comprehensive logging might be beneficial in the
long-run.  Not sure if django currently has any logging that occurs at
various levels?

For starters though, we should patch the default behavior so that it
logs errors to the python logging system when it handles an exception.
 I can do this, and even write some documentation on how to setup and
use a simple python logger.

Where would be the most appropriate place for this patch?  Right now I
just created a custom server_error view that takes care of it, but
perhaps it would be more appropriate for it to be in
core/handlers/base.handle_uncaught_exception ?

http://code.djangoproject.com/browser/django/trunk/django/core/handlers/base.py#L148

or here?

http://code.djangoproject.com/browser/django/trunk/django/views/defaults.py#L16

Thanks guys,

-k

-- 
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: managing javascript and css resources

[Kevin Howerton]

>Nothing I've seen so far solves, or even addresses the original need for
>_not_ sourcing the same script numerous times (thanks to widgets with
>their own media)

The widget and admin media system needs to be re-evaluated IMO
none of these solutions are going to address the flaws you are
referring to.

What we need is an API for form actions, and a standard set of drivers
(reference implementation included in "your favorite js framework").

Once you have that, you can have your widgets know what js-driver-set
you are using and avoid duplicate importation of the core framework
components.

-- 
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: managing javascript and css resources

[Kevin Howerton]

The django-compress looks a bit better as it has the option to do the
versioning (based on a file hash), compression, and concatenization
with a management command.
Django_compressor does this all on page load, which is not production
worthy IMO.

Generating an MD5 hash on page load is un-needed overhead as well.  In
order to do this you are loading each js/css file into memory as you
render your templates. If you are using either of these tools in
production I highly recommend that you have those template fragments
cached.

Our compression scripts rely on the git-hash.  The negative to this is
that when you increase your version you expire every css/js file,
though I feel this might be a benefit in some ways (we can alter all
of our JS based by changing a version number in our settings file).
The real positive to this is that you don't even touch the filesystem
in production, let alone have to generate an md5 hash.

As far as concatenization goes, I really believe that this at least
should be separated out from the templates, if not just simply done by
hand.  Having random different concatenization of css/js littered
throughout 100+ templates can be a bit daunting to maintain.  Doing
the concat in a python file would work very well though

global = ('carousel.js', 'menu-bar.js', 'modal.js')
newspage = ('widgets.js', 'calendar.js', 'weather.js')

I've always just achieved the same effect by just throwing all the
different little files that are required for each page type ... into
one file, though that's probably due to a lack of an acceptable
alternative solution rather than anything else.

-k

-- 
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: Cujo .... an experimental branch of django.

[Kevin Howerton]

>From the github:



"* Commits should be atomic: they should each encompass a single logical
   change that works on its own.  You can use "git rebase --interactive" to
   collapse multiple commits into a single commit before pushing your code
   up for contribution."


I think the idea is to basically have feature branches that are pushed
back into Tom's repo as atomic commits... That Should make things
relatively easy to deal with right?


On Wed, Apr 21, 2010 at 2:33 PM, Jeremy Dunck  wrote:

On Wed, Apr 21, 2010 at 1:14 PM, Tom X. Tobin 
> wrote:
> ...
> > There are no formal plans (on experimental's side) to merge anything
> > from experimental to trunk.  Anyone is welcome to package up code from
> > experimental and champion a change for inclusion in Django proper, but
> > it won't be me; I'm done working with patch files and Trac tickets.
> > :-)
>
> This will be pretty difficult to pull off unless there are feature
> branches in -experimental.  Will you recommend that, at least?
>
> --
> 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: managing javascript and css resources

[Kevin Howerton]

"I understand that Django has historically been
anti-javascript-framework-blessing, and I'm wondering if opening this
can of worms would mean having to incorporate some kind of a pluggable
backend system (for working with different frameworks, or multiple
frameworks at a time) - something I've briefly considered, but started
foaming at the mouth as a result."

We should look to Rails 3 JS Helpers for some prior art ... I have a pretty
good idea of how we can easily have a widget system that spits out JS of
your desired flavor... I just have to write the code.. heh.

"These aren't something we could easily incorporate.  Just automating
JS and CSS bundling and compression would be a big help.  This is a
good place to start on that:"

I have a build-bot that appropriately compresses and versions our JS and
GZips it... then sends it off to our CDN. I use a template tag to vary on
user-agent to serve up the ungzipped content to IE6.  I've found this to be
the preferred method over available open-sourced django tags... It does
almost zero processing at runtime  (just the tag that varies on user-agent).

Also I don't like how some of the available libraries encourage
concatenization of js/css files that shouldn't be concatenated (that should
all be done by hand for best results IMO).

-- 
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: Cujo .... an experimental branch of django.

[Kevin Howerton]

Thanks for the support Russ...

I think Cujo (the name at least) has been abandoned and I have joined my
efforts with some other developers also interested in contributing to an
experimental branch.

http://github.com/tomxtobin/django-experimental
http://groups.google.com/group/django-experimental?hl=en

My goal certainly isn't to break backwards compatibility if at all possible.
 Especially when the first few things I want to take care of... are just
tickets I'm cherry picking that have already had significant time and effort
invested in them by other django developers. In addition it will definitely
help me orient myself with the process of getting patches pushed back
upstream.

On the other hand, I think it might be a great place for developers to test
the waters with features that are a bit more radical...or break backwards
compatibility, or are less likely to hit trunk because of scope creep or
what-have you.

I guess what I'm really looking for is a playground, not really a branch
that is necessarily hostile in any way other than the development process
will hopefully be a bit more experimental.

Hopefully though, much of what happens in django-experimental
*eventually*makes it upstream.

-k

-- 
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.

Cujo .... an experimental branch of django.

[Kevin Howerton]

Cujo... for starters it's Amon Tobin's first moniker (he remixes jazz
into some delightful tunes, if you don't know of him I strongly
recommend you go to your local record store and pick up a copy of
"Adventures in Foam").

Also, I felt it was somewhat apt due to the rabid nature of the
discussions the past few days ... and I think there's a Stephen King
novel of the same name about a dog with rabies or something.

So we have a clever name ... someone needs to make a rabid, crazy-eyed
pony for the logo and I think we are pretty much done.

Also, if anyone wants to help with the code ... that would be good too.

Currently, my main two concerns are this ticket (
http://code.djangoproject.com/ticket/7539 ... which already has a
working patch I believe) ... and what I perceive is poor exception
handling in templates.

http://www.bitbucket.org/kevin.howerton/cujo/wiki/Home

-- 
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: High Level Discussion about the Future of Django

[Kevin Howerton]

"That is, in fact, our policy. 1.1 is compatible with 1.0; 1.2 with 1.1; etc."

1.1 and 1.2 are by definition not point releases.  Point releases
don't introduce new features.

On Thu, Apr 15, 2010 at 3:32 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> On Thu, Apr 15, 2010 at 1:57 PM, Kevin Howerton
> <kevin.hower...@gmail.com> wrote:
>> The level of resistance I see to change or outsider code contribution
>> is an enormous de-motivator for people (like me) to want to make any
>> contributions in the first place.  Why should I contribute a patch to
>> your flawed architecture if I'm going to be talked down to, ridiculed,
>> then eventually have the patch rejected because it breaks code in some
>> edge-use-case?
>
> I'm sorry that you've felt ridiculed or talked down to. I can promise
> you that wasn't the intent. To satiate my own curiosity, and to help
> me not make similar mistakes, could you point me to where that's
> happened?
>
>> It's a good idea to avoid breaking backwards compatibility in point
>> releases, but as far as major releases go ... I whole heartedly
>> encourage it.
>
> That is, in fact, our policy. 1.1 is compatible with 1.0; 1.2 with 1.1; etc.
>
>> Personally I believe my time might be better spent developing a fork,
>> than arguing over clear flaws in architecture decisions that "can't be
>> changed".
>
> This is open source, and that's your prerogative. If you want to start
> a fork, do. I hope you'll consider contributing back to the trunk, but
> that's up to you.
>
> For better or worse, we've chosen a development policy that
> prioritizes stability, maturity, and longevity. If those aren't your
> priorities, then perhaps a fork is the right answer.
>
> 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: Pass Thru Image Proxy Patch Interest?

[Kevin Howerton]

Why not just use the backend feature that already exists?

I have an S3 backend that does this...

It checks if it's on S3, if not it serves it locally.  If it's on S3
it throws the url into memcache, and bob is your uncle.

On Wed, Apr 14, 2010 at 9:27 AM, Russell Keith-Magee
 wrote:
> On Wed, Apr 14, 2010 at 8:58 PM, Ed Menendez  wrote:
>> Agree on avoiding additional setting.
>>
>> Re: cache
>> Basically if the file is not found locally then it goes out to the URL
>> to get it. So a local file couldn't be overwritten as that's the first
>> thing it checks. Cache is currently an option to the view too. Which
>> should be documented so it can be turned off if disk space is limited
>> locally.
>
> Ok. We can work through details once we're in the new feature
> discussion phase for 1.3.
>
>> Re: 1.2
>> No problem. Should I not even open a ticket with the patch until after
>> or is it OK to do now?
>
> Feel free to open a ticket now, just don't put it on the 1.2 milestone.
>
> 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.
>
>

-- 
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: High Level Discussion about the Future of Django

[Kevin Howerton]

"You seem to be suggesting that a fork will somehow magically fix the
speed of Django development. I ask you: who is going to work on this
fork?"

I think a hostile fork is almost a certain outcome if development
continues as it has.  Not only is the resistance to make backwards
incompatible changes in future releases a bad policy for the quality
of the framework, but the behavior in trac has a negative effect on
community contributions.

The level of resistance I see to change or outsider code contribution
is an enormous de-motivator for people (like me) to want to make any
contributions in the first place.  Why should I contribute a patch to
your flawed architecture if I'm going to be talked down to, ridiculed,
then eventually have the patch rejected because it breaks code in some
edge-use-case?

Personally I believe my time might be better spent developing a fork,
than arguing over clear flaws in architecture decisions that "can't be
changed".

It's a good idea to avoid breaking backwards compatibility in point
releases, but as far as major releases go ... I whole heartedly
encourage it.  If keeping backwards compatibility was a good idea, my
macbook pro would have a 5.12" floppy drive, a 3.25" drive, a jazz
drive, it would accept serial and adb plugs and maybe have a
display mode to emulate those green crt monitors of yore.

Good software is about removing flaws, improving the architecture, and
learning from past mistakes.  If this comes at a price, then pay.

-k

On Wed, Apr 14, 2010 at 9:25 AM, Russell Keith-Magee
 wrote:
> On Wed, Apr 14, 2010 at 8:34 PM, veena  wrote:
>
>> I know there's django deprecation policy nicely documented
>> http://docs.djangoproject.com/en/1.1/internals/release-process/#internal-release-deprecation-policy
>>
>> But what I don't know is how you discover it. Is it described
>> somewhere in the text or the video from conference? What were the
>> reasons to have this deprecation policy? Was there any user research?
>> Research of when the django users upgrade, what are the main problems
>> of upgrades and how they imagine upgrading should work?
>
> The policy was arrived at after a debate between the core team, based
> on how the core team believe a well-behaved project should behave. For
> the record, it wasn't much of a debate, either - we were all pretty
> much in agreement on the core points from the beginning.
>
> In the opinion of the core, well-behaved projects don't require
> massive rewrites (or worse - subtle bug chasing efforts) every time a
> new release is made. Developers using a library should have the
> confidence to know that when they write code, it will continue to work
> for a long time, not just until the core developers have a change of
> heart.
>
> I would suggest to you that one of the reasons for Django's success
> has been it's policy on backwards compatibility.
>
>> What I try to say is that I'm little bit afraid that it seems like
>> improvements of django will take years instead of months.
> ...
>> I think this could lead to fork the django by some devs
>> and rapid development of this fork
>
> You seem to be suggesting that a fork will somehow magically fix the
> speed of Django development. I ask you: who is going to work on this
> fork?
>
> Progress on Django may be slower than many would like, but it's not
> slow because we're hampered by backwards compatibility. It's because
> the core team all have full time jobs, families and friends, and we
> contribute to Django in our spare time. If you want to fix the speed
> of development, pitch in.
>
> 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.
>
>

-- 
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: Inappropriate behavior [was: Re: default delete() clear() behavior and you.]

[Kevin Howerton]

sorry.  my intention wasn't to make light of violence of any nature.
the image i posted was an actual ad for las vegas.  i just returned
from there (for the millionth time, i have family that live there..
not the biggest fan of vegas) ... and thus it was on my mind.  i will
contain my sardonic wit henceforth, as it clearly doesn't translate
well on the internet.

sorry again.

-k

On Tue, Apr 6, 2010 at 12:14 AM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> On Mon, Apr 5, 2010 at 1:06 PM, Kevin howerton <kevin.hower...@gmail.com> 
> wrote:
>> ps.  I didn't really murder a hooker in vegas
>
> This sort of "joke" is highly offensive, and isn't appropriate here.
> Frankly, I don't think it's appropriate *anywhere*, but I actually
> have some power to stop this sort of crap here, and I'm using it.
>
> Violence against women and sex workers is very real, and joking about
> it trivializes the very real pain of survivors. The image you posted
> could have been highly hurtful to those who've experienced violence;
> images and jokes about sexualized violence trigger painful memories.
>
> I recognize that you probably didn't intend to offend. Nevertheless,
> you did: I found your "joke" offensive and tasteless, and the image
> you posted more so. Discriminatory and exclusionary humor causes real
> pain and is not appropriate here.
>
> 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: default delete() clear() behavior and you.

[Kevin Howerton]

I only killed one hooker, but it was really small so I don't know if it counts.

The problem with those patches though are that they don't appear
(correct me if i'm wrong) to account for handling different deletes
per reverse relation.  You really need to have a more granular
approach.  If an object has two parents pointing at it; one with NULL,
and one with a DEFAULT set... how would you be able to have it handle
the different behavior on both?  It seems like the patches mentioned
in that ticket would only allow you to either delete(cascade=defaults)
or delete(cascade=nulls)... when you really need it to vary based on
the parent field.  Not sure what whether all of the databases can
handle that behavior?

Also, regardless of whether an elegant solution that relies on the
database exists for the delete method, I feel like the clear method
should be patched to match the behavior of the code I posted.

-k
On Mon, Apr 5, 2010 at 5:20 PM, Florian Apolloner <f.apollo...@gmail.com> wrote:
> Uhm, your fix fixes the problem at the wrong end. This can and should
> be supported by the database's native capabilities. This would be the
> ticket for it: http://code.djangoproject.com/ticket/7539
>
> But I like your imagination, or is there more truth behind your story
> than you'd admit?
>
> Cheers,
> Florian Apolloner
>
> On Apr 5, 8:06 pm, Kevin howerton <kevin.hower...@gmail.com> wrote:
>> Hi.
>>
>> So I came across a use-case for wanting to delete content (which
>> django doesn't really handle exactly to my liking).  I just got back
>> from a vacation in vegas and noticed in a drunken stupor I had posted
>> some pictures on my blog that should I really shouldn't have 
>> (http://i.imgur.com/5oj15.jpgSFW).
>>
>> Anyhow, currently django's only delete behavior (to my knowledge) is
>> to delete all objects related from a reverse relation.  I think it
>> would be preferable to actually delete only objects that have NOT NULL
>> **and** no default set.
>>
>> Right now clear() sort of fills some of the void for what you need to
>> do prior to deleting an object, but it fails to handle DEFAULT
>> conditions.
>>
>> I realize changing the default behavior of the delete() method is
>> probably out of the question... and there are a bunch of tickets open
>> asking for cascades and what-not, that will hopefully one day fill the
>> void.  clear(), however, *should* handle DEFAULTS in the same way it
>> handles null=True.
>>
>> Also, I wrote a mix-in class that fixes the delete method to work as I
>> believe it should... for those of you with similar use-cases.  Anyone
>> have any feedback on it?
>>
>> ps.  I didn't really murder a hooker in vegas (I don't even have a
>> blog), just felt that I should provide a relevant use-case ;)
>>
>> from django.db.models.fields import NOT_PROVIDED
>> from django.contrib import admin
>>
>> class ClearOnDelete(models.Model):
>>     def delete(self):
>>         related_objects = self._meta.get_all_related_objects()
>>         for object in related_objects:
>>             accessor_name = object.get_accessor_name()
>>             related_accessor = getattr(self.__class__, accessor_name)
>>             related_accessor_instance = getattr(self, accessor_name)
>>
>>             if related_accessor.related.field.default is not
>> NOT_PROVIDED:
>>                 for relation in related_accessor_instance.all():
>>                     setattr(relation,
>> related_accessor.related.field.name,
>> related_accessor.related.field.default)
>>                     relation.save()
>>             elif related_accessor.related.field.null:
>>                 for relation in related_accessor_instance.all():
>>                     setattr(relation,
>> related_accessor.related.field.name, None)
>>                     relation.save()
>>         super(ClearOnDelete, self).delete()
>>
>>     class Meta:
>>         abstract = True
>
> --
> 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.

default delete() clear() behavior and you.

[Kevin howerton]

Hi.

So I came across a use-case for wanting to delete content (which
django doesn't really handle exactly to my liking).  I just got back
from a vacation in vegas and noticed in a drunken stupor I had posted
some pictures on my blog that should I really shouldn't have (
http://i.imgur.com/5oj15.jpg SFW).

Anyhow, currently django's only delete behavior (to my knowledge) is
to delete all objects related from a reverse relation.  I think it
would be preferable to actually delete only objects that have NOT NULL
**and** no default set.

Right now clear() sort of fills some of the void for what you need to
do prior to deleting an object, but it fails to handle DEFAULT
conditions.

I realize changing the default behavior of the delete() method is
probably out of the question... and there are a bunch of tickets open
asking for cascades and what-not, that will hopefully one day fill the
void.  clear(), however, *should* handle DEFAULTS in the same way it
handles null=True.

Also, I wrote a mix-in class that fixes the delete method to work as I
believe it should... for those of you with similar use-cases.  Anyone
have any feedback on it?

ps.  I didn't really murder a hooker in vegas (I don't even have a
blog), just felt that I should provide a relevant use-case ;)

from django.db.models.fields import NOT_PROVIDED
from django.contrib import admin

class ClearOnDelete(models.Model):
def delete(self):
related_objects = self._meta.get_all_related_objects()
for object in related_objects:
accessor_name = object.get_accessor_name()
related_accessor = getattr(self.__class__, accessor_name)
related_accessor_instance = getattr(self, accessor_name)

if related_accessor.related.field.default is not
NOT_PROVIDED:
for relation in related_accessor_instance.all():
setattr(relation,
related_accessor.related.field.name,
related_accessor.related.field.default)
relation.save()
elif related_accessor.related.field.null:
for relation in related_accessor_instance.all():
setattr(relation,
related_accessor.related.field.name, None)
relation.save()
super(ClearOnDelete, self).delete()

class Meta:
abstract = True

-- 
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.