DjangoCon.eu is on right now

[Russell Keith-Magee]

Hi all,

This is a reminder to everyone that DjangoCon.eu is on during this
week. Jacob, Jannis, myself, and several other prominent django-dev
contributors are in Berlin, and as a result, we may not be able to pay
as much attention to django-dev as would would normally.

So - if you post a Grand Proposal for Django 1.3 Awesomeness, please
don't be offended if we don't respond as quickly as we would normally.

We will be sprinting at the conference on Thursday and Friday. If you
have a detailed proposal that would benefit from some round-table
discussion while several core developers are in the same room, please
post your proposal and we'll try to discuss it. Alternatively, if you
wait until early next week, life should return to relative normality.

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-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

[Vinay Sajip]

On May 24, 10:37 am, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:

>
> We will be sprinting at the conference on Thursday and Friday. If you
> have a detailed proposal that would benefit from some round-table
> discussion while several core developers are in the same room, please
> post your proposal and we'll try to discuss it. Alternatively, if you
> wait until early next week, life should return to relative normality.

Now that Django 1.2.1 has been released, I'd like to raise again the
question of introducing logging into Django, which was mooted by Simon
Willison (http://code.djangoproject.com/wiki/LoggingProposal) for
inclusion in 1.2, but then shelved for lack of time/other priorities.
I don't know if it's too early to bring this up for 1.3, but the
Python changes relating to dictionary-based configuration have been
added to Python (for inclusion in 2.7 and 3.2) and with a standalone
implementation (dictconfig) which can be co-opted for use in Django
with earlier versions of Python.

I've created a logging branch which mirrors Django trunk just after
the 1.2 release. The branch incorporates the dictconfig module and
also allows a simple mechanism for initialising logging (using
dictconfig or any other mechanism) via settings.py (with no need to
worry about multiple imports of settings.py). As an illustration, I've
added logging statements in some Django modules (e.g. request
handling, app loading, SQL execution) which don't do any actual
logging by default, but which can be turned on by a suitable logging
configuration.

The logging branch is available on Launchpad., which uses the Bazaar
DVCS. I know that Bazaar isn't everyone's favourite, but it should be
easy enough to import this into Mercurial or Git when the time comes.

The branch is at

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

This will allow anyone to review the changes made to Django to
incorporate logging. These are fairly small in scope:

django/conf/__init__.py (added hooks for bootstrap one-off operations
during Django initialisation, to be used for e.g. logging
configuration)
django/db/models/loading.py (added hooks for running user-defined code
before and after app/model loading operations)
django/utils/log.py (new file to hold Django logging-specific code,
based on Simon Willison's version mentioned in ticket #12012).
django/utils/dictconfig.py (new file, holding code to allow logging
configuration via dicts in a way compatible with Python 2.7, 3.2 and
usable with older Python versions).

In addition, logging statements have been added to:

django/db/models/loading.py (app/model loading)
django/core/handlers/base.py (exception handling, including uncaught
exceptions)
django/db/backends/util.py (SQL statement execution)
django/core/handlers/wsgi.py (Unicode exception during request
handling)

Overall the changes are fairly modest and should be fairly easy to
review. Basic diffs to show what was added:

http://bazaar.launchpad.net/~vinay-sajip/django/logging/revision/53 -
Added callback hooks
http://bazaar.launchpad.net/~vinay-sajip/django/logging/revision/55 -
Added log module reference
http://bazaar.launchpad.net/~vinay-sajip/django/logging/revision/56 -
Added log module itself
http://bazaar.launchpad.net/~vinay-sajip/django/logging/revision/55 -
Removed log module reference (as not needed)
http://bazaar.launchpad.net/~vinay-sajip/django/logging/revision/61 -
Added dictconfig.py and changed code to use it
http://bazaar.launchpad.net/~vinay-sajip/django/logging/revision/62 -
Added useful default to configuration
http://bazaar.launchpad.net/~vinay-sajip/django/logging/revision/63 -
Added logging to app loading
http://bazaar.launchpad.net/~vinay-sajip/django/logging/revision/65 -
Added logging for SQL and uncaught exceptions in request handling
http://bazaar.launchpad.net/~vinay-sajip/django/logging/revision/67 -
Added some more logging to request handling code
http://bazaar.launchpad.net/~vinay-sajip/django/logging/revision/69 -
Added more logging to WSGI handler

There's also a simple test project which you can use to play with
these changes. This is available at

https://code.launchpad.net/~vinay-sajip/+junk/django-logtest

This is a vanilla 1.2-generated project which has changes only to
settings.py. These illustrate how to initialise logging, configure
listeners for class_prepared (as an example), and how to configure
logging to generate output from the logging statements added to
Django.

I'd like to get some feedback on these changes, which are intended to
make it as easy as possible to introduce logging into Django itself as
well as configure logging with a Django site both for internal Django
operations as well as contrib apps and other, third-party Django apps.

Since many of the core team will be at DjangoCon.eu, hopefully there
will be a chance while all are together to discuss the proposal about
logging.

As well as feedback on the general approach I've taken, I'm also
interested in getting feedback as to where you think logging
statements should be added in Django itself. For example,
django.contrib.auth and django.contrib.admin would appear to be good
candidates. I hope to garner suggestions for other areas - perhaps
security-related, such as CSRF violations.

Looking forward to that feedback,


Vinay Sajip

[Graham Dumpleton]

On May 24, 7:37 pm, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:

> Hi all,
>
> This is a reminder to everyone that DjangoCon.eu is on during this
> week. Jacob, Jannis, myself, and several other prominent django-dev
> contributors are in Berlin, and as a result, we may not be able to pay
> as much attention to django-dev as would would normally.
>
> So - if you post a Grand Proposal for Django 1.3 Awesomeness, please
> don't be offended if we don't respond as quickly as we would normally.
>
> We will be sprinting at the conference on Thursday and Friday. If you
> have a detailed proposal that would benefit from some round-table
> discussion while several core developers are in the same room, please
> post your proposal and we'll try to discuss it. Alternatively, if you
> wait until early next week, life should return to relative normality.
>
> Yours,
> Russ Magee %-)

Be nice if you can work out direction on uniform Django entry point
for hosting such that behaviour is always the same and not different
between development server and other hosting mechanisms. For why this
is a problem with WSGI hosting see my blog post at:

http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html

If don't see it as an issue, then if you are at Sydney PyCon I can
find you there and we can argue about it. :-)

BTW, I have separate ideas about making WSGI hosting simpler, but been
hard so far to get anyone interested. Part of the problem is that
authors of each hosting mechanism are content with their own way of
doing things and don't appear to really want to cooperate in coming up
with one better standard interface. :-(

Graham

[Russell Keith-Magee]

Yes, I'll be at Pycon.AU, so we should certainly use the opportunity
to thrash out some details if we can. I'll try and get some of the
discussion started during the sprints so I'll be well armed by the
time PyCon comes around.

> BTW, I have separate ideas about making WSGI hosting simpler, but been
> hard so far to get anyone interested. Part of the problem is that
> authors of each hosting mechanism are content with their own way of
> doing things and don't appear to really want to cooperate in coming up
> with one better standard interface. :-(

Armin Ronacher has been singing a similar song this week. I agree that
Django hasn't been good at interacting with the broader community when
it comes to this sort of issue. I could come up with all sorts of
excuses for why this is the case, but excuses won't fix anything --
ultimately we just need to do better.

Yours,
Russ Magee %-)

[Russell Keith-Magee]

On Tue, May 25, 2010 at 1:21 PM, Vinay Sajip <vinay...@yahoo.co.uk> wrote:
> On May 24, 10:37 am, Russell Keith-Magee <freakboy3...@gmail.com>
> wrote:
>>
>> We will be sprinting at the conference on Thursday and Friday. If you
>> have a detailed proposal that would benefit from some round-table
>> discussion while several core developers are in the same room, please
>> post your proposal and we'll try to discuss it. Alternatively, if you
>> wait until early next week, life should return to relative normality.
>
> Now that Django 1.2.1 has been released, I'd like to raise again the
> question of introducing logging into Django, which was mooted by Simon
> Willison (http://code.djangoproject.com/wiki/LoggingProposal) for
> inclusion in 1.2, but then shelved for lack of time/other priorities.
> I don't know if it's too early to bring this up for 1.3, but the
> Python changes relating to dictionary-based configuration have been
> added to Python (for inclusion in 2.7 and 3.2) and with a standalone
> implementation (dictconfig) which can be co-opted for use in Django
> with earlier versions of Python.

Your timing is dead on, and I'm personally interested in targeting
logging for 1.3.

> The branch is at
>
> https://code.launchpad.net/~vinay-sajip/django/logging/

...

> This will allow anyone to review the changes made to Django to

> I'd like to get some feedback on these changes, which are intended to
> make it as easy as possible to introduce logging into Django itself as
> well as configure logging with a Django site both for internal Django
> operations as well as contrib apps and other, third-party Django apps.
>
> Since many of the core team will be at DjangoCon.eu, hopefully there
> will be a chance while all are together to discuss the proposal about
> logging.

Agreed; Are you at the conference? If so, corner me at some point
(either during the break or during the sprints); if you're not, I'll
try and review the code at some point and give you some feedback.

Yours,
Russ Magee %-)

[Vinay Sajip]

On May 25, 8:38 am, Russell Keith-Magee <russ...@keith-magee.com>
wrote:

>
> Your timing is dead on, and I'm personally interested in targeting
> logging for 1.3.

That's good news :-)

> Agreed; Are you at the conference? If so, corner me at some point
> (either during the break or during the sprints); if you're not, I'll
> try and review the code at some point and give you some feedback.

Sadly, I couldn't come to DjangoCon.eu. Have a great conference, and I
look forward to your feedback.

Regards,

Vinay Sajip

[Jacob Kaplan-Moss]

On Tue, May 25, 2010 at 10:28 AM, Vinay Sajip <vinay...@yahoo.co.uk> wrote:
>> Agreed; Are you at the conference? If so, corner me at some point
>> (either during the break or during the sprints); if you're not, I'll
>> try and review the code at some point and give you some feedback.
>
> Sadly, I couldn't come to DjangoCon.eu. Have a great conference, and I
> look forward to your feedback.

If you can, try to jump onto #django-sprint at some point during the
sprints and find me (jacobkm) or Russ (freakboy43234542334 or
something) -- I'll be cornering Russ to talk about your proposal, so
we might end up having some questions for you.

At first glance, though, I'm thinking this looks pretty good -- though
the log config file is giving me slight flashbacks to
log4j.properties... /me shudders.

Jacob

[Vinay Sajip]

On May 25, 10:27 am, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> At first glance, though, I'm thinking this looks pretty good -- though
> the log config file is giving me slight flashbacks to
> log4j.properties... /me shudders.

Do you mean this bit?

LOGGING = {
'version': 1,
'formatters': {
'default': {
'format': '%(asctime)s %(levelname)-1.1s [%(name)s] %
(message)s',
},
},
'handlers': {
'file': {
'class': 'logging.FileHandler',
'filename': '/tmp/logtest.log',
'mode': 'w',
'formatter': 'default',
},
'sqlfile': {
'class': 'logging.FileHandler',
'filename': '/tmp/logtest-sql.log',
'mode': 'w',
'formatter': 'default',
},
},
'root' : {
'level' : 'WARNING',
'handlers' : ['file'],
},
'loggers': {
'logtest': { 'level': 'INFO' },
'django': { 'handlers': ['file'] },
'django.core.urlresolvers': { 'level': 'DEBUG' },
'django.core.handlers.base': { 'level': 'DEBUG' },
'django.db.models.loading': { 'level': 'DEBUG' },
'django.db.backends.util': { 'level': 'DEBUG', 'propagate':
False,
'handlers': ['sqlfile'] },
},
}

That's using the PEP 391 schema which has been approved and
implemented in Python for 2.7/3.2. Obviously it's not the most minimal
configuration in this example - just something to illustrate multiple
log files (SQL and everything else) and the ability to set verbosity
of logging differently for different bits of Django. I'm not proposing
that this be the default for a Django settings.py file as created by
"django-admin.py startproject". A much simpler configuration is
possible, and no doubt we'll come up with one as the recipe gets
baked.

As far as the IRC thing goes - I'll try to be around Thursday and
Friday so that I can hook up with you on #django-sprint.

Regards,

Vinay Sajip

[Graham Dumpleton]

On May 25, 5:24 pm, Russell Keith-Magee <russ...@keith-magee.com>
wrote:

From what I understand of where Armin is coming from he wants to
rewrite WSGI from scratch effectively based on everything we have
learnt. I totally agree with that and have thought that for quite a
while but saw it as a bit too hard to achieve. Momentum is changing
though on this which is positive.

What I am thinking of is not related to the WSGI interface itself but
the mechanisms around creation and setup of the WSGI application for
deployment. Not ready to explain it more at this point as don't really
have the time and have preference for implementing a proof of concept
as that would explain it better than any description.

Graham

[Gustavo Narea]

Hello, Russell et al.

On May 24, 10:37 am, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:

> We will be sprinting at the conference on Thursday and Friday. If you
> have a detailed proposal that would benefit from some round-table
> discussion while several core developers are in the same room, please
> post your proposal and we'll try to discuss it.

I have one: http://groups.google.com/group/django-developers/browse_thread/thread/5c92a9ea7caae978

If you need more details about how things work, you may check the
manual (it's fully documented) or the source code:
http://packages.python.org/twod.wsgi/manual/
http://bitbucket.org/2degrees/twod.wsgi/src

- Gustavo :)

[Michael P. Jung]

Some time ago I proposed a new field type called "CompositeField". It's
basicly a way of doing composition in Django models.

Its usage looks like:

class CoordField(CompositeField):
x = models.FloatField()
y = models.FloatField()

class Place(models.Model):
name = models.CharField(max_length=10)
coord = CoordField()

And basicly creates this model:

class Place(models.Model):
name = models.CharField(max_length=10)
coord_x = models.FloatField()
coord_y = models.FloatField()

Right now the code lives in a scrap heap repository, which is reused in
many of the projects I work on. All the stuff is BSD licensed!

https://hg.labs.terreon.de/common/chimes/

It would be nice to get some feedback on this proposal and make it more
useful to others. I would like to make a first class project out of it
and add the possibility for composite fields to contain other composite
fields. Admin integration would be awesome, but I've never really looked
into that. The sub fields are normal model fields and can be accessed
from queries and admin naturally.

I'll join the sprints on thursday.

--mp

[Chuck Harmston]

For those not familiar with the previous discussion on the subject:

http://groups.google.com/group/django-developers/browse_thread/thread/e7de5d07d614761a/e3147d2f93bcc804

http://groups.google.com/group/django-developers/browse_thread/thread/32f861c8bd5366a5/22732dc88e644f77

[Michael P. Jung]

Please check out the repacked and slightly refactored implementation of
CompositeField:

http://bitbucket.org/mp/django-composite-field

I'm currently lacking ideas how to get that into admin without having to
specify all subfields in the fieldsets.

--mp

[Russell Keith-Magee]

On Tue, May 25, 2010 at 4:28 PM, Vinay Sajip <vinay...@yahoo.co.uk> wrote:
> On May 25, 8:38 am, Russell Keith-Magee <russ...@keith-magee.com>
> wrote:
>>
>> Your timing is dead on, and I'm personally interested in targeting
>> logging for 1.3.
>
> That's good news :-)
>
>> Agreed; Are you at the conference? If so, corner me at some point
>> (either during the break or during the sprints); if you're not, I'll
>> try and review the code at some point and give you some feedback.
>
> Sadly, I couldn't come to DjangoCon.eu. Have a great conference, and I
> look forward to your feedback.

Hi Vinay,

Sorry I didn't get back to you during the actual sprints; however, we
(Jacob, Jannis, myself, and a couple of others) got a chance to
discuss logging, and the general consensus is that modulo some minor
modifications and additions, what you've proposed is essentially ready
to go.

I'll start a clean thread to thrash out the final details.

Yours,
Russ Magee %-)