Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Gustavo Narea]

Hello,

On May 28, 6:13 pm, Russell Keith-Magee 
wrote:
> This is all very helpful information; thanks for breaking it down like this.
>
> I've talked this over with a few people at the sprints, and we've
> pretty much ended up at the same point -- we're deeply confused.
> Comments inline below.

Thank you very much for taking time to talk about it. :)

Sorry, I think I didn't explain some components well and that led to
the confusion. I'll try to do it better this time...


> I also want to be very clear -- this feedback is *not* us saying "go
> away", it's us saying "we're not clear on what you're proposing and
> why you're proposing it". Please take this criticism in the sprit it
> is intended -- to work out exactly what it is that we *aren't* doing,
> and more importantly, *why* we should be doing it another way.

Sure, I understand.


> > Paste Deploy application factory instead of `manage runserver'
> > --
>
> > The problem with running the application in development mode is that
> > there's no way to add WSGI middleware, it's like Django assumes that
> > you'd only need WSGI middleware on deployment.
>
> > Therefore I think we should either adopt Paste Script's development
> > server (which makes your app behave like it'd do under mod_wsgi, for
> > example; with no Django-specific magic) or implement a development
> > server that serves the WSGI application you give it (which could be
> > wrapped around WSGI middleware, or it could not even be a Django
> > application).
>
> > I'd prefer sticking to Paste Script's server because it's multi-
> > threaded and we could *optionally* use Paste Deploy configuration
> > files, instead of Python files for configuration:
> >http://packages.python.org/twod.wsgi/manual/paste-factory.html
>
> So - what you seem to be proposing here is that we add Paste as a
> dependency of Django in order to support:
>
>  1) A format of configuration that is different to Django's
>  2) Support for WSGI middlewares in the development server


That's right, although the proposal is not mainly to add Paste as a
dependency, but support WSGI middleware in a transparent way; for
example, the way Paste Deploy does.

The reason why I proposed Paste is because it's widely used and it'd
prevent us from implementing something that is already implemented.


> Despite your protestations, (1) is a matter of opinion, and it's not
> an opinion I happen to share. Personally, I really like the fact that
> Django's configuration files are Python files and not Yet Another
> Configuration Format; I also contest the assertion that INI files are
> more configurable.

I agree it's a matter of opinion, and I also have to say that's
secondary. I'm not that interested in changing the configuration
system, at least not within this WSGI-related proposal: I just wanted
to point out another advantage of using Paste, which you could use if
you want to (it wouldn't be mandatory).


> (2) isn't a matter of opinion; however, it's not a use case that I've
> seen a particularly compelling use case for, either. I'm certainly
> willing to be convinced otherwise, though -- now is your opportunity
> to convince us.

Basically, when you need to integrate a piece of WSGI middleware that
must be present both on development and deployment, you have to get
rid of `manage runserver' and use a development server like the one
from Paste or CherryPy.

There are lots of WSGI middleware out there that you may want/need to
use, and there are even projects like Paste or Repoze whose only goal
is to develop framework-independent WSGI libraries (many if not most
of them are middleware). In the following links you can find some of
the WSGI middleware available and find that most of them are
applicable to both development and deployment:
http://pythonpaste.org/modindex.html (some items aren't middleware,
but WSGI applications)

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

[Vinay Sajip]

On May 29, 1:05 am, Waylan Limberg  wrote:
>
> Vinay has already stated that he is making his code (which is part of
> python 2.7) available to be distributed with Django so it will work on
> any version that Django works on.
>

Yes, I've develloped my Launchpad branch (which has the dictconfig
code) on a machine running Ubuntu Dapper, with Python 2.4, as that's
the minimum Python version requirement for Django now :-)

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

[Vinay Sajip]

On May 28, 10:27 pm, Kevin howerton  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

[Waylan Limberg]

On Fri, May 28, 2010 at 4:39 PM, Mathieu Leduc-Hamel  wrote:
> Oh cool! next time I'll check in the PEP list before...
>
> But I don't understand how it'll work with older python version, like
> the current 2.6 branch ?

Vinay has already stated that he is making his code (which is part of
python 2.7) available to be distributed with Django so it will work on
any version that Django works on.

>
> On Fri, May 28, 2010 at 4:33 PM, Vinay Sajip  wrote:
>>
>> On May 28, 9:16 pm, Mathieu Leduc-Hamel  wrote:
>>> I would say, why not use the default python way to config logging,
>>> handler and loggers ? it work fine and many projects are using it.
>>> That way, we'll be able to use the same logging configuration for our
>>> django projects and the different python library that we may use and
>>> we the logging is implemented using the default python way.
>>>
>>> I don't exactly understand why it should be in the settings.py file ?
>>>
>>
>> What's proposed to be in settings.py is the actual configuration, not
>> the mechanism. The mechanism will be the new-in-Python-2.7-and-3.2
>> configuration via dictionaries (rather than via Python code or the ini-
>> style confguration files - see PEP 391 for more details of the
>> rationale behind dict-based configuration).
>>
>> Existing projects (like Django) can use the standalone dictconfig
>> project on BitBucket to get the functionality which will be in Python
>> 2.7 and 3.2, for use with earlier versions of Python. So really,
>> Django is using the same mechanisms as Python for logging. It's good
>> practice to put a shallow interface between the Django and Python
>> logging configuration layers, to allow Django to specify sensible
>> defaults. (There's an example of that in my Launchpad branch - the
>> Django layer adds a default key in the dictionary to specify that by
>> default, existing loggers are not disabled when configuration
>> happens.)
>>
>> Logging of third-party libraries and django-apps (which make use of
>> logging) in a Django site will be customisable through the logging
>> configuration mechanism being proposed. All of Django, your apps and
>> their dependencies, third-party apps and their dependencies - if any
>> of them already use logging in the conventional way, you will be able
>> to modify their logging behaviour through this mechanism.
>>
>> 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.
>
>



-- 

\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

-- 
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: Class based generic views in 1.3?

[Luke Plant]

On Friday 28 May 2010 15:51:32 Jacob Kaplan-Moss wrote:

> My only real objection here is that `as_view` is just a bunch of
> boilerplate::
> 
> urlpatterns = patterns('',
> ('one/', SomeView.as_view()),
> ('two/', SomeOtherView.as_view()),
> ('three', YourView.as_view())
> )
> 
> I just really don't like the way that looks.

Agreed.  I also think that if you have a mixture of normal views and 
class based view, this is ugly:

 urlpatterns = patterns('app.views',
 ('one/', 'some_view_function',
 ('two/', SomeOtherView),
 ('three/', YourView)
 )

and it would be nicer to spell it:

 urlpatterns = patterns('app.views',
 ('one/', 'some_view_function'),
 ('two/', 'some_other_view'),
 ('three/', 'your_view')
 )

and have these additional lines in 'app.views':

some_other_view = SomeOtherView.as_view()
your_view = YourView.as_view()

I know that is just moving the boilerplate around, but it is giving a 
consistent interface.  If some code in a re-usable app moves from 
normal views to class based views, they will have to do something like 
this *anyway* for backwards compatibility.

But I can see that if subclassing is the default way of re-using, then 
exporting these functions gives multiple options about how they should 
be re-used, which you are wanting to avoid.

> > There is also the issue of what to do when you need to add a
> > decorator to someone else's view function.
> 
> Again, I want to encourge "subclass it" as the correct answer here.

In that case, I guess it would be good to make this hard to do wrong, 
by providing helpers that add the decorator to the right end of the 
list of decorators.

Regards,

Luke

-- 
"Oh, look. I appear to be lying at the bottom of a very deep, dark 
hole. That seems a familiar concept. What does it remind me of? Ah, 
I remember. Life."  (Marvin the paranoid android)

Luke Plant || http://lukeplant.me.uk/

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

[Mathieu Leduc-Hamel]

Oh cool! next time I'll check in the PEP list before...

But I don't understand how it'll work with older python version, like
the current 2.6 branch ?

On Fri, May 28, 2010 at 4:33 PM, Vinay Sajip  wrote:
>
> On May 28, 9:16 pm, Mathieu Leduc-Hamel  wrote:
>> I would say, why not use the default python way to config logging,
>> handler and loggers ? it work fine and many projects are using it.
>> That way, we'll be able to use the same logging configuration for our
>> django projects and the different python library that we may use and
>> we the logging is implemented using the default python way.
>>
>> I don't exactly understand why it should be in the settings.py file ?
>>
>
> What's proposed to be in settings.py is the actual configuration, not
> the mechanism. The mechanism will be the new-in-Python-2.7-and-3.2
> configuration via dictionaries (rather than via Python code or the ini-
> style confguration files - see PEP 391 for more details of the
> rationale behind dict-based configuration).
>
> Existing projects (like Django) can use the standalone dictconfig
> project on BitBucket to get the functionality which will be in Python
> 2.7 and 3.2, for use with earlier versions of Python. So really,
> Django is using the same mechanisms as Python for logging. It's good
> practice to put a shallow interface between the Django and Python
> logging configuration layers, to allow Django to specify sensible
> defaults. (There's an example of that in my Launchpad branch - the
> Django layer adds a default key in the dictionary to specify that by
> default, existing loggers are not disabled when configuration
> happens.)
>
> Logging of third-party libraries and django-apps (which make use of
> logging) in a Django site will be customisable through the logging
> configuration mechanism being proposed. All of Django, your apps and
> their dependencies, third-party apps and their dependencies - if any
> of them already use logging in the conventional way, you will be able
> to modify their logging behaviour through this mechanism.
>
> 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 in Django

[Vinay Sajip]

On May 28, 9:16 pm, Mathieu Leduc-Hamel  wrote:
> I would say, why not use the default python way to config logging,
> handler and loggers ? it work fine and many projects are using it.
> That way, we'll be able to use the same logging configuration for our
> django projects and the different python library that we may use and
> we the logging is implemented using the default python way.
>
> I don't exactly understand why it should be in the settings.py file ?
>

What's proposed to be in settings.py is the actual configuration, not
the mechanism. The mechanism will be the new-in-Python-2.7-and-3.2
configuration via dictionaries (rather than via Python code or the ini-
style confguration files - see PEP 391 for more details of the
rationale behind dict-based configuration).

Existing projects (like Django) can use the standalone dictconfig
project on BitBucket to get the functionality which will be in Python
2.7 and 3.2, for use with earlier versions of Python. So really,
Django is using the same mechanisms as Python for logging. It's good
practice to put a shallow interface between the Django and Python
logging configuration layers, to allow Django to specify sensible
defaults. (There's an example of that in my Launchpad branch - the
Django layer adds a default key in the dictionary to specify that by
default, existing loggers are not disabled when configuration
happens.)

Logging of third-party libraries and django-apps (which make use of
logging) in a Django site will be customisable through the logging
configuration mechanism being proposed. All of Django, your apps and
their dependencies, third-party apps and their dependencies - if any
of them already use logging in the conventional way, you will be able
to modify their logging behaviour through this mechanism.

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

[Vinay Sajip]

On May 28, 8:55 pm, Kevin howerton  wrote:
> 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 agree that there should be a simple option for configuration - and
in my example application, the LOGGING dict is used to configure via
dictConfig, but in such a way that an alternative approach can be
easily substituted For most usages, changes to the LOGGING dict would
do exactly what Russ is talking about, but for more esoteric cases,
you'd just replace the contents of init_logging() with whatever you
wanted.

>
> 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 don't disagree with this - apart from the xxx_CALLBACK hooks, the
other stuff I added to Django was to illustrate how things might look
further down the line. I also think there's a case for adding logging
to some of the exception handling stuff, e.g.
handle_uncaught_exception. It's not really a lot of work, since I've
already done some of it ;-)

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

Personally I don't think it's worth it - they are IMO separate
concerns. Changing logging configurations should certainly not affect
the program's behaviour, for example.

> 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']},
>      }
>
> }

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.

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

Likewise in my Launchpad branch, though a little different in the
details from Simon's, though the effect is much the same.

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

[Mathieu Leduc-Hamel]

I would say, why not use the default python way to config logging,
handler and loggers ? it work fine and many projects are using it.
That way, we'll be able to use the same logging configuration for our
django projects and the different python library that we may use and
we the logging is implemented using the default python way.

I don't exactly understand why it should be in the settings.py file ?

On Fri, May 28, 2010 at 11:48 AM, Russell Keith-Magee
 wrote:
> Hi all,
>
> 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.
>
> 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
> 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
>
> This provides a convenient entry point for configuration items such as
> signals. The only runtime guarantee for startup.py is that the
> settings have been imported. This means that you should be able to
> import models, register for signals, or anything else you may want to
> do on startup.
>
> There won't be a project-level startup file. We've been trying to
> discourage the use of projects for a long time, and almost everything
> that needs to be considered as "project level" can be implemented by
> using a "project app" -- either adding a 'project.core' app to the
> mix, or by adding the project directory itself to INSTALLED_APPS. If
> you have a need for a project level startup.py, then this is the
> approach that should be taken.
>
> So - comments? Suggestions?
>
> 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: 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: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Russell Keith-Magee]

On Thu, May 27, 2010 at 5:08 PM, Gustavo Narea
 wrote:
> Hello,
>
> On May 26, 4:52 pm, Ivan Sagalaev  wrote:
>> Could you please give a concise technical overview, in high-level terms,
>> on what twod.wsgi actually does to Django code?
>
> Sure. There are different components, so I'll elaborate on them
> individually:

Hi Gustavo,

This is all very helpful information; thanks for breaking it down like this.

I've talked this over with a few people at the sprints, and we've
pretty much ended up at the same point -- we're deeply confused.
Comments inline below.

I also want to be very clear -- this feedback is *not* us saying "go
away", it's us saying "we're not clear on what you're proposing and
why you're proposing it". Please take this criticism in the sprit it
is intended -- to work out exactly what it is that we *aren't* doing,
and more importantly, *why* we should be doing it another way.

> Paste Deploy application factory instead of `manage runserver'
> --
>
> The problem with running the application in development mode is that
> there's no way to add WSGI middleware, it's like Django assumes that
> you'd only need WSGI middleware on deployment.
>
> Therefore I think we should either adopt Paste Script's development
> server (which makes your app behave like it'd do under mod_wsgi, for
> example; with no Django-specific magic) or implement a development
> server that serves the WSGI application you give it (which could be
> wrapped around WSGI middleware, or it could not even be a Django
> application).
>
> I'd prefer sticking to Paste Script's server because it's multi-
> threaded and we could *optionally* use Paste Deploy configuration
> files, instead of Python files for configuration:
> http://packages.python.org/twod.wsgi/manual/paste-factory.html

So - what you seem to be proposing here is that we add Paste as a
dependency of Django in order to support:

 1) A format of configuration that is different to Django's
 2) Support for WSGI middlewares in the development server

Despite your protestations, (1) is a matter of opinion, and it's not
an opinion I happen to share. Personally, I really like the fact that
Django's configuration files are Python files and not Yet Another
Configuration Format; I also contest the assertion that INI files are
more configurable.

(2) isn't a matter of opinion; however, it's not a use case that I've
seen a particularly compelling use case for, either. I'm certainly
willing to be convinced otherwise, though -- now is your opportunity
to convince us.

Regardless, as you've demonstrated with twod.wsgi -- support for a
"rich" development server is also something that can be provided as an
external resource. Given that the overhead of this change is adding a
dependency to a project that has made a history of not having
dependencies, I'm more inclined to modify the docs to say "If you
want/need to use WSGI middleware as part of your development
environment, you'll need to test your deployments under a full WSGI
container -- either a full web server, or a lightweight test server
such as the one provided by twod.wsgi".

> Better request objects
> --
>
> There are two problems with Django's request objects from a WSGI point
> of view:
>
> - It copies the WSGI environment variables. That makes
> interoperability with WSGI libraries harder or not possible at all,
> because the request can be changed but the WSGI environ wouldn't be
> modified, and vice versa, if the WSGI environ is modified the request
> wouldn't be updated.
> - It doesn't expose an API to handle most of the properties of a
> request -- only the most common ones.
>
> WebOb's request object is a better proxy of the WSGI environ from my
> point of view, which is why I think Django's request object should
> extend it. It doesn't have the problems above and it has more
> features:
> http://packages.python.org/twod.wsgi/manual/request-objects.html
>
> I've managed to sub-class both WebOb.Request and Django's HttpRequest
> without breaking backwards compatibility.

Why do we need to subclass WebOb here? Again, you're proposing the
introduction of a major dependency to Django; if there are
bugs/inconsistencies in Django's WSGI implementation, those bugs
should be fixed. I'm not sure I see why introducing WebOb is the right
approach here.

> Embedded WSGI applications
> --
>
> At present there's no built-in mechanism to run WSGI applications from
> Django. Doing so could be extremely powerful and useful in some
> situations, because it gives you the ability to filter the request
> another application receives, and the response it returns -- Using
> request and response objects, respectively.
>
> And by "WSGI" application, I mean pretty much *any* Web application.
> Java applications, PHP applications, a Web site like www.google.com.
> Anything, thanks 

Re: Logging in Django

[Vinay Sajip]

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
doing logging configuration their own (different) way, or doing their
own early-phase setup code, they'd be out of luck.

> This provides a convenient entry point for configuration items such as
> signals. The only runtime guarantee for startup.py is that the
>
> settings have been imported. This means that you should be able to
> import models, register for signals, or anything else you may want to
> do on startup.

This implies that all the startup.py importing would be done in a
separate loop after all the model loading is done - i.e. the
equivalent of my POST_MODEL_CALLBACKS hook.  If so, how could you hook
into class_prepared, as per my example? Can you confirm that's the
intention?

Thanks for your feedback!

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

[Jacob Kaplan-Moss]

On Fri, May 28, 2010 at 5:48 PM, Russell Keith-Magee
 wrote:
> So - comments? Suggestions?

Just FTR, Russ and I have been talking about this for a few days here
in Berlin, and I'm in agreement with this 100%.

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: Date format localization problem (Django displays dates in format it doesn't accept)

[Horst Gutmann]

Did you already try the patch I attached at
http://code.djangoproject.com/ticket/13621 ? Perhaps this solves your
problem too :-)

On Fri, May 28, 2010 at 4:50 PM, Ludwik Trammer  wrote:
> Hi,
>
> There is quite a serious problem with Django 1.2's format localization
> and forms. At first I noticed Djnago ignores L10N date formats when
> displaying dates in form fields, but calendar widgets in admin don't.
> So when you try using the calendar, date format goes back and forth
> between localized and unlocalized versions. I opened a ticket couple
> of days ago (#13591) calling it an "usability" problem (because it is
> utterly confusing to have a date format changing, when the only thing
> you expected to be changed was a date).
>
> It turned out however, that the issue is much more serious (and not
> contained to Django Admin only). Look at the StackOverflow question:
>
> http://stackoverflow.com/questions/2929388/django-1-2-dates-in-admin-forms-dont-work-with-locales-i10ntrue
>
> It turnes out date formats for some countries, shipped with Django,
> doesn't include the "universal" -MM-DD formats as accepted date
> format (DATE_INPUT_FORMATS). Which at first seems logical, but in
> conjunction with the fact that Django always uses the -MM-DD
> format to display dates in forms, ignoring localization settings, the
> result is people are getting form validating errors, when trying to
> edit their models. In other words Django populates form fields with
> data in format it doesn't accept itself.
>
> Ludwik Trammer
>
> --
> 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: Class based generic views in 1.3?

[Ben Firshman]

If a class-based view by definition is instantiated on each request, we get a 
couple of neat things. For example, storing state on self.

Storing state on self makes things a heck of a lot easier. We are going to 
create a "View" and a "ResourceView". A View just renders a template, but a 
ResourceView has some kind of resource attached to it (model instance, 
QuerySet, whatever). On View, this would be the get_context() signature (where 
args and kwargs are from the URL):

def get_context(self, request, *args, **kwargs):


When we create ResourceView, we need to pass the resource in here somehow, 
interfering with args and kwargs:

def get_context(self, request, resource, *args, **kwargs):


We would have to redefine all the methods which require the resource. It seems 
neater to store it on self.

We have solved accidentally instantiating the view by raising an exception if a 
View instance is called twice. Of course, people who understand the threading 
issues are free to create their own class-based views.

I like this method because of its transparency. I fear having to explain 
as_view() in the documentation. Thread problems are hard to understand.

Ben

On 28 May 2010, at 16:51, Jacob Kaplan-Moss wrote:

> This is a bit of a tricky thing to discuss since we've been talking
> about this IRL at the sprints, and also on the list. I'll try to sum
> up where we are now, but if anything isn't clear, ask.
> 
> We're currently working towards URLpatterns of the form::
> 
>('...', SomeView)
> 
> i.e. passing a class directly, which would be instantiated implicitly
> then called.
> 
> The reason we're trying it this way is thread safety: if a view is a
> class, then people *will* store state on self. So if we have single
> instances in views like we do now, then we're giving folks enough rope
> to hang themselves. By having each request get a fresh instance we
> avoid that problem.
> 
> The other alternative we discussed was having the base view class do
> something with threadlocals to make sure state saved on self is
> threadsafe. I vetoed that because I hate threadlocals :)
> 
> On Fri, May 28, 2010 at 3:41 PM, Luke Plant  wrote:
>> I'm sure that will work.  My main reluctance is using isinstance()
>> when it isn't necessary, and having to change the definition of what a
>> 'view' is when it isn't strictly necessary. (A view is no longer
>> simply "a callable that takes a request and returns a response").
> 
> I *am* a bit worried by this -- I'm not sure redefining the definition
> of "view" is such a good idea. "A view is a callable or a class with
> callable instances" isn't nearly as simple and nice a recommendation.
> 
>> If, however, we encouraged `MyClassView.as_view()` from the start, we
>> can cope with constructor arguments more easily - it changes to
>> `MyClassView.as_view(somearg=something)`.
> 
> My only real objection here is that `as_view` is just a bunch of boilerplate::
> 
>urlpatterns = patterns('',
>('one/', SomeView.as_view()),
>('two/', SomeOtherView.as_view()),
>('three', YourView.as_view())
>)
> 
> I just really don't like the way that looks.
> 
> As for accepting extra __init__ arguments: I specifically *don't* want
> to allow this (at least easily) because I want to encourage
> subclassing as the "correct" way of extending views. Yes, this means a
> slight loss of flexibility, but it also means that we're forcing
> people into a more extensible and fuure-proof way of coding, and
> that's a good thing.
> 
>> (Either way, it would still be possible to pass in MyClassView() and
>> get thread safety problems, but it's about making mistakes less
>> natural).
> 
> ... and either way it's pretty easy to issue a warning if you've
> subclassed ``django.views.View`` (my proposed name for the view base
> class) and re-used it for multiple requests.
> 
>> There is also the issue of what to do when you need to add a decorator
>> to someone else's view function.
> 
> Again, I want to encourge "subclass it" as the correct answer here.
> 
>> Given that, for many Django apps, the view functions are part of the
>> public API that needs to be exported (i.e. hooked into people's
>> URLconfs or wrapped for re-use), I think it would be good to encourage
>> practices which will lead to stable and consistent APIs, and so *not*
>> allow or encourage classes to be used directly in the URLconf.
> 
> I think we're in agreement here -- we're both trying to avoid view-ish
> stuff in the URLconfs (a la the old way we used to do generic views
> with dicts in urls.py).
> 
> Having played with it for a few years now, though, I'm finding
> subclassing is really the best way to make this happen.
> 
> So reusable apps instead of exporting functional views export
> class-based ones; users who want to re-use them import, subclass, and
> extend.
> 
> Jacob
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> 

Date format localization problem (Django displays dates in format it doesn't accept)

[Ludwik Trammer]

Hi,

There is quite a serious problem with Django 1.2's format localization
and forms. At first I noticed Djnago ignores L10N date formats when
displaying dates in form fields, but calendar widgets in admin don't.
So when you try using the calendar, date format goes back and forth
between localized and unlocalized versions. I opened a ticket couple
of days ago (#13591) calling it an "usability" problem (because it is
utterly confusing to have a date format changing, when the only thing
you expected to be changed was a date).

It turned out however, that the issue is much more serious (and not
contained to Django Admin only). Look at the StackOverflow question:

http://stackoverflow.com/questions/2929388/django-1-2-dates-in-admin-forms-dont-work-with-locales-i10ntrue

It turnes out date formats for some countries, shipped with Django,
doesn't include the "universal" -MM-DD formats as accepted date
format (DATE_INPUT_FORMATS). Which at first seems logical, but in
conjunction with the fact that Django always uses the -MM-DD
format to display dates in forms, ignoring localization settings, the
result is people are getting form validating errors, when trying to
edit their models. In other words Django populates form fields with
data in format it doesn't accept itself.

Ludwik Trammer

-- 
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: Class based generic views in 1.3?

[Jacob Kaplan-Moss]

This is a bit of a tricky thing to discuss since we've been talking
about this IRL at the sprints, and also on the list. I'll try to sum
up where we are now, but if anything isn't clear, ask.

We're currently working towards URLpatterns of the form::

('...', SomeView)

i.e. passing a class directly, which would be instantiated implicitly
then called.

The reason we're trying it this way is thread safety: if a view is a
class, then people *will* store state on self. So if we have single
instances in views like we do now, then we're giving folks enough rope
to hang themselves. By having each request get a fresh instance we
avoid that problem.

The other alternative we discussed was having the base view class do
something with threadlocals to make sure state saved on self is
threadsafe. I vetoed that because I hate threadlocals :)

On Fri, May 28, 2010 at 3:41 PM, Luke Plant  wrote:
> I'm sure that will work.  My main reluctance is using isinstance()
> when it isn't necessary, and having to change the definition of what a
> 'view' is when it isn't strictly necessary. (A view is no longer
> simply "a callable that takes a request and returns a response").

I *am* a bit worried by this -- I'm not sure redefining the definition
of "view" is such a good idea. "A view is a callable or a class with
callable instances" isn't nearly as simple and nice a recommendation.

> If, however, we encouraged `MyClassView.as_view()` from the start, we
> can cope with constructor arguments more easily - it changes to
> `MyClassView.as_view(somearg=something)`.

My only real objection here is that `as_view` is just a bunch of boilerplate::

urlpatterns = patterns('',
('one/', SomeView.as_view()),
('two/', SomeOtherView.as_view()),
('three', YourView.as_view())
)

I just really don't like the way that looks.

As for accepting extra __init__ arguments: I specifically *don't* want
to allow this (at least easily) because I want to encourage
subclassing as the "correct" way of extending views. Yes, this means a
slight loss of flexibility, but it also means that we're forcing
people into a more extensible and fuure-proof way of coding, and
that's a good thing.

> (Either way, it would still be possible to pass in MyClassView() and
> get thread safety problems, but it's about making mistakes less
> natural).

... and either way it's pretty easy to issue a warning if you've
subclassed ``django.views.View`` (my proposed name for the view base
class) and re-used it for multiple requests.

> There is also the issue of what to do when you need to add a decorator
> to someone else's view function.

Again, I want to encourge "subclass it" as the correct answer here.

> Given that, for many Django apps, the view functions are part of the
> public API that needs to be exported (i.e. hooked into people's
> URLconfs or wrapped for re-use), I think it would be good to encourage
> practices which will lead to stable and consistent APIs, and so *not*
> allow or encourage classes to be used directly in the URLconf.

I think we're in agreement here -- we're both trying to avoid view-ish
stuff in the URLconfs (a la the old way we used to do generic views
with dicts in urls.py).

Having played with it for a few years now, though, I'm finding
subclassing is really the best way to make this happen.

So reusable apps instead of exporting functional views export
class-based ones; users who want to re-use them import, subclass, and
extend.

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: DjangoCon.eu is on right now

[Russell Keith-Magee]

On Tue, May 25, 2010 at 4:28 PM, Vinay Sajip  wrote:
> On May 25, 8:38 am, Russell Keith-Magee 
> 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 %-)

-- 
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: Class based generic views in 1.3?

[Luke Plant]

On Friday 28 May 2010 09:03:02 David Larlet wrote:

> > This will solve the thread safety issue, and doesn't require
> > another import for a decorator, as Jari pointed out.
> > 
> > We could decide whether to apply decorators inside as_view() or
> > __call__().  The argument for putting it in 'as_view' is that
> > __call__ does some processing that you might want to skip
> > entirely (e.g. the get_object() call - if we applied a
> > 'cache_page' decorator, we wouldn't want the get_object() call
> > to be made at all if there was a cache hit).
> 
> We discussed that point with Jacob and it looks like it's easier to
> modify urlresolvers to create a new instance of the class when we
> detect it's a class, this should solve the thread safety issue. Do
> you see any drawback to this approach?

I'm sure that will work.  My main reluctance is using isinstance() 
when it isn't necessary, and having to change the definition of what a 
'view' is when it isn't strictly necessary. (A view is no longer 
simply "a callable that takes a request and returns a response"). I 
guess this is partly about aesthetics, and I know practicality beats 
purity, but:

There might also be the following practical disadvantages when it 
comes to the API we encourage.

If the recommended usage is to do:
urlpatterns = ...
 (r'something/', MyClassView)
  ...

then it would be easy to accidentally do `MyClassView()`, and it would 
appear to work fine, until you later get thread safety issues.  Also, 
if you want to pass arguments to the constructor, you would most 
naturally do `MyClassView(somearg=something)`, and again it would 
appear to work.

If, however, we encouraged `MyClassView.as_view()` from the start, we 
can cope with constructor arguments more easily - it changes to 
`MyClassView.as_view(somearg=something)`.

(Either way, it would still be possible to pass in MyClassView() and 
get thread safety problems, but it's about making mistakes less 
natural).

Of course, if we want to use dotted path syntax in URLconfs - 
"path.to.MyClassView" - rather than imports, then we would *need* to 
have the isinstance() check to be able to cope with it at all.  My 
response to that is: my preference would be that the use of class 
based views should remain an implementation detail, and as far as the 
URLconf is concerned, views.py should be exporting a ready-to-use 
callable not the class. (The class is exported for the purpose of 
other people subclassing, or passing their own constructor arguments, 
not for direct use in the URLconf). 

There is also the issue of what to do when you need to add a decorator 
to someone else's view function.  As a developer, I shouldn't have to 
know that class based views even *exist*, let alone how to use them, 
if I'm just a client - I should *always* be able to say:

  from someapp.views import some_view_function
  my_view_function = login_required(some_view_function)

But if someapp.views has only exported SomeClassView and not 
some_view_function, I now have to do something different.

Given that, for many Django apps, the view functions are part of the 
public API that needs to be exported (i.e. hooked into people's 
URLconfs or wrapped for re-use), I think it would be good to encourage 
practices which will lead to stable and consistent APIs, and so *not* 
allow or encourage classes to be used directly in the URLconf.

Regards,

Luke

-- 
"Oh, look. I appear to be lying at the bottom of a very deep, dark 
hole. That seems a familiar concept. What does it remind me of? Ah, 
I remember. Life."  (Marvin the paranoid android)

Luke Plant || http://lukeplant.me.uk/

-- 
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: Proposal: Schema migration/evolution backend

[Tom Evans]

Slight typo here, I think:

On Fri, May 28, 2010 at 12:06 PM, Andrew Godwin  wrote:
>  - Inside an application, migrations are implicitly ordered by name (by
> string sort, so "0001_initial" is before "0002_second", and "alpha" is
> before "beta", but "11_foo" is not before "2_bar").

'11_foo' would sort before '2_bar', obviously.

'1_bar' would not sort before '11_foo', which I think is the point
Andrew is trying to get across - this will be an alphanumeric sort,
you must prefix with '0' if you want predictability.


Cheers

Tom

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

Re: ipv6 support for runserver - stuck in DDN for 2 yrs

[Erik Romijn]

Hi,

Ramiro Morales wrote:
> On Fri, May 28, 2010 at 7:25 AM, Erik Romijn  wrote:
>>
>> I noticed that there is a patch for IPv6 support in runserver,
>> http://code.djangoproject.com/ticket/7735 , and a maintainer willing to
>> make it cleanly apply to the latest trunk.
> 
> Could you please expand on the 'a feature we should have' part?.

At a point in the not too far future, there will be IPv6-only hosts.
They will benefit from having runserver being able to listen on IPv6.

cheers,
Erik

-- 
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: Proposal: Schema migration/evolution backend

[Andrew Godwin]

On 28/05/10 13:06, Andrew Godwin wrote:

Hi all,

As perhaps was inevitable, I'm proposing implementing part of a schema 
migration backend in Django. I'm not sure if this is a 1.3 thing (it 
may well be 1.4, perhaps with some implemented in time for 1.3 but not 
exposed), but it's something I'd like to get started in this release 
cycle. To make it clear, I'm happy to make all these changes - I'm alre


For the record, this was supposed to end "I'm already pretty familiar 
with both the model layer and migrations, and I feel like using up all 
my free time."


I'll hit send less quickly next time.

Andrew

--
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: ipv6 support for runserver - stuck in DDN for 2 yrs

[Ramiro Morales]

On Fri, May 28, 2010 at 7:25 AM, Erik Romijn  wrote:
> Hi,
>
> I noticed that there is a patch for IPv6 support in runserver,
> http://code.djangoproject.com/ticket/7735 , and a maintainer willing to
> make it cleanly apply to the latest trunk.
>
> However, for some reason it's been stuck in DDN for two years. Why is
> this? It looks to me like a simple patch for a feature we should have.

Could you please expand on the 'a feature we should have' part?.

I've read the ticket history and there are similar claims there but with
no rationale either.

Regards,

-- 
Ramiro Morales  |  http://rmorales.net

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

ipv6 support for runserver - stuck in DDN for 2 yrs

[Erik Romijn]

Hi,

I noticed that there is a patch for IPv6 support in runserver,
http://code.djangoproject.com/ticket/7735 , and a maintainer willing to
make it cleanly apply to the latest trunk.

However, for some reason it's been stuck in DDN for two years. Why is
this? It looks to me like a simple patch for a feature we should have.

Can this be moved along, or is there something blocking it?

cheers,
Erik

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

Proposal: Schema migration/evolution backend

[Andrew Godwin]

Hi all,

As perhaps was inevitable, I'm proposing implementing part of a schema 
migration backend in Django. I'm not sure if this is a 1.3 thing (it may 
well be 1.4, perhaps with some implemented in time for 1.3 but not 
exposed), but it's something I'd like to get started in this release 
cycle. To make it clear, I'm happy to make all these changes - I'm alre


Firstly, let me make it clear that this is not a proposal to merge South 
into core. Quite the opposite, in fact, the idea is to keep the option 
open to have different migration frontends available and in fact make 
the implementation of them much easier.


Secondly, this particular proposal is something that me and Russ have 
preliminarily agreed on here at the sprints - however, I'd really like 
people to suggest changes and things we may have missed. Implementing 
this essentially consists of drawing a line of how much of a migrations 
framework we'll implement in Django, and I'm only mostly sure we have it 
in the right place.


The first part of the proposal is pretty uncontroversial, and it's to 
implement schema-changing operations on the backends. Specifically, the 
proposed new operations are:


 - add_table
 - delete_table
 - rename_table
 - add_column
 - rename_column
 - alter_column
 - delete_column
 - add_primary_key
 - delete_primary_key
 - add_unique
 - delete_unique
 - add_index
 - delete_index

Some of these operations are already mostly implemented (add_table, 
add_index, etc.) in backends' creation modules, but they'll need a bit 
of rearranging and separating into a full public API. I also plan to 
modify them to take model names and field names, instead of table names 
and column names, so the API is exclusively using the Django model layer 
to represent changes (there's a possibility that some changes make sense 
for schemaless databases as well, specifically renames, so it's best not 
to tie it directly to relational databases).


(Additionally, this means that if someone has specified the table name 
or column name directly using something like Meta: db_table then we'll 
need to have those as either extra arguments to the function or as 
marked strings - e.g mark_raw('auth_users'))


I expect this will take a while and be quite fiddly, but we have the 
codebases of django-evolution and South to draw on for the modification 
code, so there's not much new discovery and backend-specific bugfixing 
to be done.


Additionally, unlike in current South, backends will always be able to 
generate SQL for operations, but it won't necessarily be runnable 
(things like index names can only be resolved at runtime, so you'd get 
code like "DROP INDEX <> ON users;". We feel this 
is a pretty good tradeoff between being able to actually work with 
things like index names (they're basically nondeterministic) while also 
satisfying people who like to read the SQL that's going to be run.


The second part is to implement migration tracking, dependency resolving 
and basic running into Django. There will be a core contract migrations 
have to follow:


 - Migrations are per-application
 - Applications have a directory (usually appname/migrations/, but 
configurable via a setting like SOUTH_MIGRATION_MODULES does now), which 
contains zero or more .sql and .py files
 - Inside an application, migrations are implicitly ordered by name (by 
string sort, so "0001_initial" is before "0002_second", and "alpha" is 
before "beta", but "11_foo" is not before "2_bar").
 - Migrations are uniquely identified by the combination of their app 
label and their migration name.
 - There will be a table, probably "migration_history" or similar, 
which records which migrations have been applied, and when.
 - Django will ship with a "migrate" command, which will work out what 
migrations to run, and run them. There will be an automatic mode which 
runs dependencies, and a manual mode where you say if you'd like to run 
each migration (and ones that are missing dependencies it tells you 
about, but you're not allowed to run).


As for the migration files themselves, the idea is to provide a very 
basic interface that means that apps (and Django itself, potentially) 
can ship migrations that have no dependencies, but that still allows 
third-party tools like South to exist that will provide ORM access and 
autogeneration.


.py migration files will be a normal Python module, and should have a 
"migrate" callable, which will get called with three arguments (a 
connection/operations instance, much like 'south.db.db', reverse, a 
boolean saying if the migration should run backwards, which will be 
entirely optional and some migrations will just raise an error, and 
dry_run, which indicates if the migration should just run through and 
check there's no obvious calling errors, which is useful for catching 
errors on MySQL before the SQL gets sent to the database).


The files can also optionally have a __depends__ variable in scope, 
which should be an iterable of 

Re: GSOC 2010: App Loading - Week 1

[Charlie Nolan]

I think that http://code.djangoproject.com/ticket/13480 may be
relevant to your interests.

-FM

On Fri, May 28, 2010 at 8:22 AM, Arthur Koziel  wrote:
> Hey there,
>
> my name is Arthur Koziel and I'll be working on the app loading refactor for 
> this year's gsoc program. I'm currently a business informatics student in 
> dortmund, germany and working towards my bachelor's degree.
>
> I didn't get any coding done this week. I attended the djangocon.eu 
> conference in berlin and used the chance to discuss the project with my 
> mentor (Jannis Leidel) in person. However, I've uploaded part of my proposal 
> to my website [0]. It would be great to get some feedback on that.
>
> So, what's up for next week? tests! The current app loading implementation 
> doesn't have any tests and it's important to have the current implementation 
> properly tested in order to validate the refactored code later on.
>
> The code will be available in the 'soc2010/app-loading' branch in django's 
> svn repository [1]. I'll be posting a weekly progress report each friday on 
> this mailing list.
>
> Arthur
>
> [0]: http://www.arthurkoziel.com/gsoc2010/proposal.txt
> [1]: http://code.djangoproject.com/svn/django/branches/soc2010/app-loading/
>
> --
> 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.

GSOC 2010: App Loading - Week 1

[Arthur Koziel]

Hey there,

my name is Arthur Koziel and I'll be working on the app loading refactor for 
this year's gsoc program. I'm currently a business informatics student in 
dortmund, germany and working towards my bachelor's degree.

I didn't get any coding done this week. I attended the djangocon.eu conference 
in berlin and used the chance to discuss the project with my mentor (Jannis 
Leidel) in person. However, I've uploaded part of my proposal to my website 
[0]. It would be great to get some feedback on that.
 
So, what's up for next week? tests! The current app loading implementation 
doesn't have any tests and it's important to have the current implementation 
properly tested in order to validate the refactored code later on.

The code will be available in the 'soc2010/app-loading' branch in django's svn 
repository [1]. I'll be posting a weekly progress report each friday on this 
mailing list.

Arthur

[0]: http://www.arthurkoziel.com/gsoc2010/proposal.txt
[1]: http://code.djangoproject.com/svn/django/branches/soc2010/app-loading/

-- 
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: Class based generic views in 1.3?

[David Larlet]

Le 28 mai 2010 à 00:01, Luke Plant a écrit :

> On Thursday 27 May 2010 17:29:28 David Larlet wrote:
>> Hello,
>> 
>> We're working on this with Ben during djangocon.eu sprint [1]. Any
>> comment appreciated, still a work in progress though.
> 
> Looks cool.  I think Jari's idea of a class method to instantiate the 
> classes would be a great pattern to establish - something like an 
> 'as_view' classmethod on the base class which returns a view function 
> that uses the class:
> 
>@classmethod
>def as_view(cls, *initargs, **initkwargs):
>def view(*args, **kwargs):
>obj = cls(*initargs, **initkwargs)
>return obj(*args, **kwargs)
>return view
> 
> The developer can choose whether to write 'MyClassView.as_view()' 
> directly into the URLconf, or put a line into views.py like 'my_view = 
> MyClassView.as_view()'
> 
> This will solve the thread safety issue, and doesn't require another 
> import for a decorator, as Jari pointed out.
> 
> We could decide whether to apply decorators inside as_view() or  
> __call__().  The argument for putting it in 'as_view' is that __call__ 
> does some processing that you might want to skip entirely (e.g. the 
> get_object() call - if we applied a 'cache_page' decorator, we 
> wouldn't want the get_object() call to be made at all if there was a 
> cache hit).
We discussed that point with Jacob and it looks like it's easier to modify 
urlresolvers to create a new instance of the class when we detect it's a class, 
this should solve the thread safety issue. Do you see any drawback to this 
approach?
That way we can declare decorators via a decorators' list [1] or directly in 
the class [2]. I'm not fond of the second way, decorating a decorator, but we 
can create decorators dedicated to class based views easily that way.
> 
> On that point, I think 'GenericView' should be split into 'ClassView' 
> and 'GenericView'.  The get_object() call is probably not a good thing 
> to have on a base class.
Agreed, I'll make that change.

Thanks,
David

[1] 
http://github.com/bfirsh/django-class-based-views/blob/master/class_based_views/tests/views.py#L24
[2] 
http://github.com/bfirsh/django-class-based-views/blob/master/class_based_views/tests/views.py#L43

-- 
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: Admin sloooow with postgresql and a 160k record table

[Marcob]

On 27 Mag, 22:58, Alex Gaynor  wrote:

> FWIW Jacob was wrong, there is another tiket, but I can't find out now
> (yay trac search ;)), so don't be offended if I close your ticket.

Alex, no offense at all :-)

Ah, you don't be offended but I already closed it as a dupe of 8408
(thanks to Jeremy).

Ciao.
Marco.

-- 
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: Introducing a CACHE_MIDDLEWARE_KEY_PREFIX-like setting for all cacheing operations (#12831)

[Silvio]

Great idea, I'd like to see this implemented too.

Running a memcached instance for small sites seems like overkill.

I'm willing to help write whatever code is necessary.

Silvio

On May 24, 4:21 am, Julien Phalip  wrote:
> Hi,
>
> Several people have expressed interest in ticket #12831, which has
> also been marked as DDN. So I thought the next step would be to bring
> it up on this list - let me know if that's not the right thing to do.
>
> Basically, I think that it would make sense and that it would be very
> useful if a new setting was introduced to allow the systematic
> addition of a prefix to avoid key collisions across multiple site
> instances, that is for all cacheing operations, not just for per-site
> cacheing (which is currently possible with the
> CACHE_MIDDLEWARE_KEY_PREFIX setting).
>
> What do you guys think about this? Does this ticket have a chance to
> be accepted or is it fundamentally a bad idea?
>
> Many thanks.
>
> Kind regards,
>
> Julien
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

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