QManager - suggested inclusion in Django
Dear Developers, I've written a module which may be helpful to a lot of Django developers, and would like to suggest it for trials and testing, and possible inclusion with Django. I'm currently just looking for developers to help test and work with the module; it should be quite helpful. In summary, it is called 'QManager', and is a Manager subclass which helps developers create Managers from Q objects. QManager instances can be joined by & and |, and by using the negative operator you can create a QManager which is the complement of the original. Essentially, the class helps abstract away a lot of the boilerplate code which is involved in creating managers. Anyone interested can find more details at code.google.com/p/django- qmanager. I've posted a preliminary version of the module up there - it's just one .py file. It's also heavily documented - *everything* has a docstring. I hope you enjoy, Regards, Zack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
HTTP PUT request
Hi, There seems to be an issue with Django in the HttpRequest class, in that I cannot access the data provided in a HTTP PUT request. I'm writing a web app which uses a RESTful interface, but at the moment I have to put together a piece of hacky middleware in order to be able to get the PUT data. What I'm doing now is changing the method to POST, accessing the request.raw_post_data attribute, and then changing the method back to PUT. This seems a little unnecessary, and I'd like to suggest the addition of a content attribute which holds any raw content provided, whether through POST or PUT. Not much code really needs to be changed at all, and I'd be willing to do it myself. It's just that this seems like a bit of a bug in Django. Regards, Zack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: recent MultiValueDict.iteritems change (changeset 8399)
Wouldn't it make sense to add a keyword argument to both itervalues and iteritems, which lets you get lists instead? That would seem easier than writing new methods. Example: >>> dictionary.iteritems(as_list=True) ... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
HttpResponse as a file-like object
Devels, I've noticed in the docs that HttpResponse objects, if initialised with an iterator, cannot be used as file-like objects. This could be fixed quite easily. At the moment, if the response was not initialised with a string, then an error is raised when you try to write to it. Instead, all that needs to be done is this (modified from HttpResponse.write() definition): def write(self, content): if not self._is_string: self._container = itertools.chain(self._container, [content]) else: self._container.append(content) In addition, HttpResponse.tell() doesn't allow you to get the position if the HttpResponse uses an iterator. This could be worked around like this: def tell(self): if not self._is_string: self._container, temp_iter = itertools.tee(self._container) else: temp_iter = self._container return sum(len(chunk) for chunk in temp_iter) Regards, Zack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: HttpResponse as a file-like object
I've written a patch, and I could open a bug with post-1.0 milestone, if that's OK? It's probably a good idea to have a general bug for initialising HttpResponse objects with iterators. On Aug 25, 9:33 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Mon, 2008-08-25 at 12:26 -0700, zvoase wrote: > > Devels, > > I've noticed in the docs that HttpResponse objects, if initialised > > with an iterator, cannot be used as file-like objects. This could be > > fixed quite easily. > > There are lots of problems -- some subtle and some obvious -- when > initialising HttpResponse objects with iterators. There isn't a single > set of simple fixes for all of them, which is why the problems are > there. In short, that behaviour isn't really well supported (and that > will remain unchanged in 1.0). We might need to update the docs to > reflect that fact, but changes to that area of code are out of scope for > 1.0, certainly. > > Regards, > Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Signal Connection Decorators
Hi Django developers, Usually, signal receivers are defined as functions and then connected to a specific signal via a function call outside of the defined function. This can cause clutter, it violates DRY, and it is not very Pythonic in style. Several examples of the current usage pattern are included in the Django documentation, and I don't need to go into too much detail because the majority of people on this list know what I'm talking about. I propose a decorator method, to be added to the Signal class, which would allow you to decorate a signal receiver function and therefore skip the explicit call to signal_instance.connect(...). The usage of such a method would look something like this: from django.db.models.signals import pre_save @pre_save.deco_connect(sender=MyModel) # Could use another name for the method... def receiver(sender, instance, *args, **kwargs): pass # Do something here. I've already written a method like this, and it's very simple in implementation. It also allows you to specify optional keyword arguments, but works without them also. Please consider this for inclusion into the Django trunk. Regards, Zack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Signal Connection Decorators
I've created a ticket: http://code.djangoproject.com/ticket/9015 I've also uploaded a patch with the suggested changes. Regards, Zack On Sep 10, 1:30 pm, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > Patch or ticket, please. > > On Sep 10, 2008, at 3:52, zvoase <[EMAIL PROTECTED]> wrote: > > > > > Hi Django developers, > > Usually, signal receivers are defined as functions and then connected > > to a specific signal via a function call outside of the defined > > function. This can cause clutter, it violates DRY, and it is not very > > Pythonic in style. Several examples of the current usage pattern are > > included in the Django documentation, and I don't need to go into too > > much detail because the majority of people on this list know what I'm > > talking about. > > > I propose a decorator method, to be added to the Signal class, which > > would allow you to decorate a signal receiver function and therefore > > skip the explicit call to signal_instance.connect(...). The usage of > > such a method would look something like this: > > > > > from django.db.models.signals import pre_save > > > @pre_save.deco_connect(sender=MyModel) # Could use another name for > > the method... > > def receiver(sender, instance, *args, **kwargs): > > pass # Do something here. > > > > > I've already written a method like this, and it's very simple in > > implementation. It also allows you to specify optional keyword > > arguments, but works without them also. Please consider this for > > inclusion into the Django trunk. > > > Regards, > > Zack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Signal Connection Decorators
I think the principle of least surprise applies here. It would be very easy just to implement __call__ as a decorator, but by the same token, the signal needs to be used from both ends, and the addition of a __call__ method may confuse some people. As with most problems in programming, we just end up discussing the name :) IMHO, I think the removal of ambiguity is worth the extra 8 characters. If we make a decision (by informal vote), then I'll just go ahead and implement it, and then we just need someone to commit to SVN. Regards, Zack On Sep 11, 10:44 pm, Ludvig Ericson <[EMAIL PROTECTED]> wrote: > On Sep 11, 2008, at 21:19, Justin Fagnani wrote: > > > I just got a chance to look at this, and I like it, but have one > > suggestion. From a usage standpoint, wouldn't it be simpler to have > > the decorator just be the signal name, like @pre_save? I can't see any > > situation where you'd use a decorator for anything but connecting, so > > the ".connect" part just seems unnecessary. > > I just sat using the dispatcher from Django in a project of mine, and > was stunned at > __call__ not being *send*. So no, no __call__ decorator. > > -- Ludvig --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Signal Connection Decorators
Couldn't we move this discussion to the ticket on Django's Trac? http://code.djangoproject.com/ticket/9015 On Sep 12, 1:01 pm, zvoase <[EMAIL PROTECTED]> wrote: > I think the principle of least surprise applies here. It would be very > easy just to implement __call__ as a decorator, but by the same token, > the signal needs to be used from both ends, and the addition of a > __call__ method may confuse some people. As with most problems in > programming, we just end up discussing the name :) > IMHO, I think the removal of ambiguity is worth the extra 8 > characters. If we make a decision (by informal vote), then I'll just > go ahead and implement it, and then we just need someone to commit to > SVN. > > Regards, > Zack > > On Sep 11, 10:44 pm, Ludvig Ericson <[EMAIL PROTECTED]> wrote: > > > On Sep 11, 2008, at 21:19, Justin Fagnani wrote: > > > > I just got a chance to look at this, and I like it, but have one > > > suggestion. From a usage standpoint, wouldn't it be simpler to have > > > the decorator just be the signal name, like @pre_save? I can't see any > > > situation where you'd use a decorator for anything but connecting, so > > > the ".connect" part just seems unnecessary. > > > I just sat using the dispatcher from Django in a project of mine, and > > was stunned at > > __call__ not being *send*. So no, no __call__ decorator. > > > -- Ludvig --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Signal Connection Decorators
I think the "signal.decorate" form is nicer, but the name has to show that there is some sort of connection going on; if you want to know why I think this is, take a look at "The Zen of Python". Basically, it's explicit (you know it refers to *that* signal), it's the obvious way to do it (seeing as we can actually edit the "Signal" class's source code, adding this as a method), and it's substantially more beautiful and explicit. That's what I think, anyway. Plus, we don't write it as signal_connect(signal, receiver). We write it as signal.connect(receiver). It's more compact, explicit, beautiful and obvious. The thing is, can we actually change the 'connect' method, or are we going to give this a new name? Regards, Zack On Sep 14, 12:19 am, Ludvig Ericson <[EMAIL PROTECTED]> wrote: > On Sep 12, 2008, at 13:01, zvoase wrote: > > > I think the principle of least surprise applies here. It would be very > > easy just to implement __call__ as a decorator, but by the same token, > > the signal needs to be used from both ends, and the addition of a > > __call__ method may confuse some people. As with most problems in > > programming, we just end up discussing the name :) > > IMHO, I think the removal of ambiguity is worth the extra 8 > > characters. If we make a decision (by informal vote), then I'll just > > go ahead and implement it, and then we just need someone to commit to > > SVN. > > Yes, so if we decide to go ahead and include decorator functionality, we > have two ways to go: > > [EMAIL PROTECTED] > def f(...): ... > > - or - > > [EMAIL PROTECTED](signal) > def f(...): ... > > I'm not sure which is more Pythonic or which I prefer, considering > Python > mixes and matches these two styles. (math.sqrt, str.encode, etc.) > > Ludvig Ericson > [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Signal Connection Decorators
Oh, yeah, by the way, for those who haven't looked at the ticket, my
implementation changes the 'connect' method, so that it can be used in
the old way ("signal.connect(receiver)"), or as a decorator
("@signal.connect" with "def receiver").
The old 'connect' method is still used (by the new method), only it's
been renamed to '_connect'. This fits with Django's way of having the
raw methods prefixed by an underscore, and the nicer, more general
methods as the name on its own.
This is only in the patch, by the way, it hasn't yet been merged :)
Don't worry, I'm not messing with stuff!
Regards,
Zack
On Sep 14, 1:51 am, zvoase <[EMAIL PROTECTED]> wrote:
> I think the "signal.decorate" form is nicer, but the name has to show
> that there is some sort of connection going on; if you want to know
> why I think this is, take a look at "The Zen of Python". Basically,
> it's explicit (you know it refers to *that* signal), it's the obvious
> way to do it (seeing as we can actually edit the "Signal" class's
> source code, adding this as a method), and it's substantially more
> beautiful and explicit. That's what I think, anyway.
>
> Plus, we don't write it as signal_connect(signal, receiver). We write
> it as signal.connect(receiver). It's more compact, explicit, beautiful
> and obvious.
>
> The thing is, can we actually change the 'connect' method, or are we
> going to give this a new name?
>
> Regards,
> Zack
>
> On Sep 14, 12:19 am, Ludvig Ericson <[EMAIL PROTECTED]> wrote:
>
> > On Sep 12, 2008, at 13:01, zvoase wrote:
>
> > > I think the principle of least surprise applies here. It would be very
> > > easy just to implement __call__ as a decorator, but by the same token,
> > > the signal needs to be used from both ends, and the addition of a
> > > __call__ method may confuse some people. As with most problems in
> > > programming, we just end up discussing the name :)
> > > IMHO, I think the removal of ambiguity is worth the extra 8
> > > characters. If we make a decision (by informal vote), then I'll just
> > > go ahead and implement it, and then we just need someone to commit to
> > > SVN.
>
> > Yes, so if we decide to go ahead and include decorator functionality, we
> > have two ways to go:
>
> > [EMAIL PROTECTED]
> > def f(...): ...
>
> > - or -
>
> > [EMAIL PROTECTED](signal)
> > def f(...): ...
>
> > I'm not sure which is more Pythonic or which I prefer, considering
> > Python
> > mixes and matches these two styles. (math.sqrt, str.encode, etc.)
>
> > Ludvig Ericson
> > [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
RFC: Raise an Exception to return a Response
Dear devels, I use the Http404 exception a *lot*, mainly because I call a lot of functions from within my views (I was raised in the Lisp tradition of refactoring EVERYTHING into separate functions) and it's nice sometimes to override the caller and just return a set response to the client. But the thing is, I do a lot of REST work, and I'm a stickler for keeping to the HTTP standard, so sometimes I need to return a lot of other HTTP status codes to the client, and at the moment I have to explicitly capture everything I call from within my view and then return that. Anyway, my request for comment (RFC) is this: wouldn't it be nice to have an exception which you can instantiate with a response, raise, and then any call to a view function which results in the raising of this exception would return the response? This would be implemented by having some middleware which just sat on top of the view function, checking to see if this error (i.e. 'ResponseException') was raised. If it was, then the response which it held (which would be in its 'response' attribute) would be returned. It sounds a little hard to digest, so I'm working on an example which I'll post soon. For the meantime, take a look at http://dpaste.com/hold/78671/ for a sample implementation. You could probably see how it would all work just from that. Regards, Zack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Raise an Exception to return a Response
Yeah, that's it, process_exception is *definitely* what I need :) But as for the idea, how do you feel about it? By the way, I've just posted a better version of it (sorry for my temporary lack of brain) here: http://dpaste.com/hold/78773/ On Sep 17, 9:26 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote: > On Wed, Sep 17, 2008 at 12:11 PM, zvoase <[EMAIL PROTECTED]> wrote: > > ... > > > I'll post soon. For the meantime, take a look > > athttp://dpaste.com/hold/78671/ > > That won't do what you want, since the "raise" on line 13 will prevent > line 14 from executing. > > I agree, you seem to want process_exception. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Raise an Exception to return a Response
Sorry, here: http://dpaste.com/hold/78774/ On Sep 18, 1:29 am, zvoase <[EMAIL PROTECTED]> wrote: > Yeah, that's it, process_exception is *definitely* what I need :) > But as for the idea, how do you feel about it? > By the way, I've just posted a better version of it (sorry for my > temporary lack of brain) here:http://dpaste.com/hold/78773/ > > On Sep 17, 9:26 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote: > > > On Wed, Sep 17, 2008 at 12:11 PM, zvoase <[EMAIL PROTECTED]> wrote: > > > ... > > > > I'll post soon. For the meantime, take a look > > > athttp://dpaste.com/hold/78671/ > > > That won't do what you want, since the "raise" on line 13 will prevent > > line 14 from executing. > > > I agree, you seem to want process_exception. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: Raise an Exception to return a Response
That's true. That doesn't mean, however, that the ResponseException
class should be removed; it's useful in that you don't need to go like
this:
exc = Exception()
exc.response = HttpResponse('content', ...)
raise exc
You can just do it all in one line. It could be put in
'django.core.exceptions', I would have thought.
It's not *hugely* necessary to have in core, but it would be nice to
integrate it with CommonMiddleware. Plus, on the Django middleware
docs, it says that if there are any suggestions for useful middleware,
just post them to the group.
Well, it's only a suggestion, but I think it could save a lot of time
in development. I have a lot of these suggestions (like, a *lot*), but
I just like to run them all by you guys just to check if there's
anything useful in there.
Regards,
Zack
On Sep 18, 1:35 am, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 17, 2008 at 6:30 PM, zvoase <[EMAIL PROTECTED]> wrote:
>
> > Sorry, here:http://dpaste.com/hold/78774/
>
> > On Sep 18, 1:29 am, zvoase <[EMAIL PROTECTED]> wrote:
> >> Yeah, that's it, process_exception is *definitely* what I need :)
> >> But as for the idea, how do you feel about it?
> >> By the way, I've just posted a better version of it (sorry for my
> >> temporary lack of brain) here:http://dpaste.com/hold/78773/
>
> So, that's a tiny amount of code, and not hard to do on your own.
>
> I don't think it needs to be in core. (Indeed, I've had something
> like this in my stack for quite a while).
>
> Anyway, even if it went in, I'd think hasattr(exception, 'response')
> would be better. What's gained by forcing inheritance here?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Proposal: app objects
I think the app object thing is a really good idea, but I have to say one thing; why not see if some middle ground can be met between the Django cheeseshop idea (going on in another thread in this group) and this. Maybe an app_info.py file in a Django app directory could give some info on that app, including version (probably via SCM revision) and name, dependencies, provisions and conflicts, etc. Probably a good idea to consult the setuptools docs on how Python apps are packaged, and then adapt that to Django apps. The thing about this is, anything you do, you can be guaranteed that someone's already done it. I personally think that you don't need an app object, information should be held within the app and not the settings in the project. Hence the app_info.py file. Regards, Zack On Sep 17, 12:34 pm, HenrikV <[EMAIL PROTECTED]> wrote: > Thats a good list of benefits. The only possible pitfall I see is > making things more complicated rather than simpler. > > I'm not sure that versioning would be a good idea within a Django > project. While version and dependency tracking is a good thing, once > you do it to very fine grained level it becomes a headache rather than > a help. > > Auto-discovery feels completely natural, and it seems like one of the > really good patterns in Django. Allowing explicit configuration is > nice seen in isolation, but giving the developer too many decisions > can be overwhelming, and counterproductive. > > Being able to configure the app_label explicitly is definitely needed, > and being able to set a verbose/localised name is also something that > should be supported. > > Now I will go back to implementing my own patch for explicit > configuration in Django /grin > > On Sep 16, 9:58 am, mrts <[EMAIL PROTECTED]> wrote: > > > App objects are a separate matter from app packaging and > > infrastructure, so I'll bring it up separately. > > > The following can be addressed with app objects. > > > 1. Allow multiple instances of an app object to exist > > > 2. Metadata: > > * name > > * verbose name > > * description > > > 3. Database: > > * possibly database if we have multi-db support > > * table prefix > > > 4. Lessen magic to get rid of autodiscovery: > > * specify models modules explicitly (fallback to 'appname/models.py') > > * specify templatetags modules explicitly (fallback to 'appname/ > > templatetags/*') > > * specify admin modules explicitly (fallback to 'appname/admin.py`) > > * templates > > > 5. Admin configurability: > > > (Use case for the following: a project that contains 10 applications, > > each containing several models. Some of the apps are of primay > > importance, some are less important. Currently, there is no way to > > impose either ordering or hide app contents. This confuses users as > > it's hard to discern important bits from non-important ones.) > > > * app and model ordering in admin index page > > * collapsing (like fieldsets) > > * override app-provided defaults: > > * name/label > > * description > > > 6. Quoting [1]: > > > Currently model._meta.app_label is heavily overloaded, acts as: > > > * Admin app display name (by .title()) > > * Admin permissions prefix > > * DB table creation prefix > > * Dumpdata/Loaddata fixture prefix identifier > > * When explicitly set, used to associate models elsewhere in the > > app structure. > > * RelatedObject? explicit cross-app identification. > > * contrib.contenttypes identification > > > Some of these should remain in the developer's control (model > > association, cross-app model id). Some of these should be in the > > installer's control (admin name, db table prefix). Some of these > > should use new db_prefix instead (table creation, fixtures?). Some of > > these it's not clear (contenttypes, permissions). > > > 7. Additional functionality overlapping with "Django Cheeseshop" > > discussion thread: > > * media > > * dependencies > > * versioning > > > --- > > > See: > > [1]http://code.djangoproject.com/wiki/InstalledAppsRevisionhttp://code.d.. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RFC: django.template refactoring (#7806)
I don't know if anyone's noticed, but the templating language seems
(at least from a usage standpoint) to be a lot like a Lisp
interpreter.
I know that sounds completely weird and random, but it's true. It's
like a very small subset of Scheme or something (the small subset
thing is necessary because you're not trying to put too much logic in
the template). I suppose the main difference is that blocks are
started and ended with explicit {% sometag %} and {% endsometag %}
statements instead of opening and closing parentheses.
If you need to refactor any of it, you might want to look at some
implementations of Lisp and steal some ideas.
Just a thought from a Lisper :)
Regards,
Zack
On Sep 18, 12:52 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Wed, 2008-09-17 at 14:42 +0100, Ben Ford wrote:
> > I take it that most are aware of:
>
> >http://lucumr.pocoo.org/cogitations/2008/09/16/why-jinja-is-not-djang...
>
> > It seems like a very well thought out and thorough write up.
>
> Um .. welll. :-(
>
> Parts of it are very well thought out and if it had been a post on "how
> Jinja works" it would have been excellent. Other parts are completely
> unconstrained by facts or acknowledgement that Django's standard
> templates and Jinja's ones have different goals (which is important,
> since this isn't an apples to apples comparison at all). So that the
> flip side is on the record, here's my single contribution to it:
>
> The good news is that, as far as I can see, all the actual bugs he notes
> are already in tickets. I went through and checked quickly yesterday and
> found all but one, which I'm pretty sure is in there, so I'll look again
> today.
>
> Whilst reading that, keep in mind that Armin apparently misunderstands
> (or possibly just omits to clearly state) what a template object
> instance is in Django. It's a state machine for rendering templates and
> includes the current state as well as the transitions. This isn't an
> invalid or particularly novel approach to executing a domain specific
> language. In fact, it makes a lot of sense if you want to write
> self-contained node-based state instances. Jinja and Django templates
> have different compilation strategies and return different types of
> objects and the difference is a vital distinction in any discussion of
> appropriate usage. The blog post appears to imply that it would be
> natural for any random data structure to be used as a global variable
> (by extrapolation, since he doesn't establish that a Template instance
> -- not a class, the instance of a compiled template -- is special in any
> sense, so it must be somehow "normal") and that those structures will
> work beautifully when multiple threads cause its internal state to be
> modified.
>
> This has two problems: (1) it's pretty much false by default (Python !=
> Haskell, Erlang, etc and mutable objects are very normal in Python), and
> (2) it would imply that using lots of globals to store stuff in
> multi-threaded programs is a good idea that people should be doing more
> often.
>
> There's a name for that sort of programming style and it's not
> "Excellent, Maintainable Code". :-)
>
> Using the same logic, Python is not thread-safe at all and shouldn't be
> used, since lists, dictionaries, sets, and pretty much any random
> instance of a class object contain state in the instance that will
> change upon use. Tuples and strings are specially noted to be immutable
> and so are usable in those situations without extra locking, but they're
> special-cases, not the norm, in a pass-by-reference language. Using
> module-level globals sparingly is something we certainly encourage.
>
> Fortunately, this isn't a real issue, since there's nowhere that we
> suggest the assumption of immutability would be valid (and, really, a
> decent programmer is going to know that any arbitrary data structures
> have the same behaviour unless it's noted as immutable; minimal
> experience says that making assumptions contrary to that always leads to
> trouble). You create the template object as part of a view and render it
> and things are (mostly -- see next para) fine. There's no real need to
> put template instances into globals.
>
> The "mostly" bit is because we do have some reset-ability issues with
> things like the cycle tag -- so rendering it multiple times in the same
> thread of execution, such as creating mass mail, will lead to differing
> results.
>
> Also, so that it's on the record: Armin denigrating Eric Holscher for
> ticket #7501 was a low-blow for multiple reasons. One being that Armin
> either misunderstood or ignored the type of object that a Template
> instance is, as noted above. Another being that nominally avoiding
> mentioning specifics whilst giving enough information that somebody
> could easily find it out anyway is simply sleazy. It devalues Eric's
> work for that part of the audience who don't know the history and makes
> the author of the piece just look small. To fill in
Re: RFC: django.template refactoring (#7806)
I guess so, but also from the overall *feel* of using it; I find
myself switching into Lisp mode when I use it. That probably makes no
sense, but it's just this feeling I had. I guess it feels as though
there's some big eval/apply machine behind it all. And the fact that
templates are compiled to a Template object reminds me of the fact
that all lisp programs are really just data structures. Template
Contexts also feel like frame stacks (in fact, they're near as dammit
an implementation of frame stacks).
On Sep 18, 2:18 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> If I follow you are saying that it is lispy in that flow control
> statements and functions are handled just the same way(meaning you can
> define your own statements if you like)?
>
> On Sep 17, 8:02 pm, zvoase <[EMAIL PROTECTED]> wrote:
>
> > I don't know if anyone's noticed, but the templating language seems
> > (at least from a usage standpoint) to be a lot like a Lisp
> > interpreter.
> > I know that sounds completely weird and random, but it's true. It's
> > like a very small subset of Scheme or something (the small subset
> > thing is necessary because you're not trying to put too much logic in
> > the template). I suppose the main difference is that blocks are
> > started and ended with explicit {% sometag %} and {% endsometag %}
> > statements instead of opening and closing parentheses.
> > If you need to refactor any of it, you might want to look at some
> > implementations of Lisp and steal some ideas.
>
> > Just a thought from a Lisper :)
>
> > Regards,
> > Zack
>
> > On Sep 18, 12:52 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
> > wrote:
>
> > > On Wed, 2008-09-17 at 14:42 +0100, Ben Ford wrote:
> > > > I take it that most are aware of:
>
> > > >http://lucumr.pocoo.org/cogitations/2008/09/16/why-jinja-is-not-djang...
>
> > > > It seems like a very well thought out and thorough write up.
>
> > > Um .. welll. :-(
>
> > > Parts of it are very well thought out and if it had been a post on "how
> > > Jinja works" it would have been excellent. Other parts are completely
> > > unconstrained by facts or acknowledgement that Django's standard
> > > templates and Jinja's ones have different goals (which is important,
> > > since this isn't an apples to apples comparison at all). So that the
> > > flip side is on the record, here's my single contribution to it:
>
> > > The good news is that, as far as I can see, all the actual bugs he notes
> > > are already in tickets. I went through and checked quickly yesterday and
> > > found all but one, which I'm pretty sure is in there, so I'll look again
> > > today.
>
> > > Whilst reading that, keep in mind that Armin apparently misunderstands
> > > (or possibly just omits to clearly state) what a template object
> > > instance is in Django. It's a state machine for rendering templates and
> > > includes the current state as well as the transitions. This isn't an
> > > invalid or particularly novel approach to executing a domain specific
> > > language. In fact, it makes a lot of sense if you want to write
> > > self-contained node-based state instances. Jinja and Django templates
> > > have different compilation strategies and return different types of
> > > objects and the difference is a vital distinction in any discussion of
> > > appropriate usage. The blog post appears to imply that it would be
> > > natural for any random data structure to be used as a global variable
> > > (by extrapolation, since he doesn't establish that a Template instance
> > > -- not a class, the instance of a compiled template -- is special in any
> > > sense, so it must be somehow "normal") and that those structures will
> > > work beautifully when multiple threads cause its internal state to be
> > > modified.
>
> > > This has two problems: (1) it's pretty much false by default (Python !=
> > > Haskell, Erlang, etc and mutable objects are very normal in Python), and
> > > (2) it would imply that using lots of globals to store stuff in
> > > multi-threaded programs is a good idea that people should be doing more
> > > often.
>
> > > There's a name for that sort of programming style and it's not
> > > "Excellent, Maintainable Code". :-)
>
> > > Using the same logic, Python is not thread-safe at all and shouldn't be
> > > used, since list
Re: RFC: Raise an Exception to return a Response
Thanks a lot, I understand what you're saying completely. I was thinking more along the lines of errors which can occur which wouldn't necessarily warrant 404s, but that's probably only a niche - mainly for things like REST and places where a client really does care what status code is returned. Anyway, thanks for your time, Regards, Zack On Sep 18, 2:12 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Wed, 2008-09-17 at 16:29 -0700, zvoase wrote: > > Yeah, that's it, process_exception is *definitely* what I need :) > > But as for the idea, how do you feel about it? > > It's trying to use exceptions for regular flow control instead of very > exceptional cases. That's neither particularly Lisp-ish nor > Pythonic. :-) > > My experience has been that scattering output-specific information, like > the actual HttpResponse and content over multiple functions tends to > backfire. It tends to be more robust to pass around proper Python > objects that encapsulate the "what" not the "how" and turn it into "how > it shall be displayed to the user" at the last moment. For example, if > you need to also include a JSON output style in addition to XML, you > have to change 57 different functions, instead of just the couple of > places that might be otherwise responsible for the converting from > output-format agnostic Python objects to the particular output format. > > Still, if it suits your style, I think the middleware approach is sound. > But it doesn't need to go into core and, for the reasons above, I > wouldn't particularly be in favour because it doesn't encourage a > particularly robust programming style. There are lots of little > stylistic variations people have in their code and that's great because > we should all use whatever makes things fastest for our own particular > needs (taking into account the needs of the people we now or will work > with, of course). However, we can't include "just a few lines" for each > one in Django, since that rapidly becomes a lot of extra lines of code > to maintain and they're so easy to manage externally and take only a few > minutes to write the first time. > > Regards, > Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Concrete django.template Suggestions
Probably the best thing to do, if anything, is to make something new
and get it working alongside the old system, much like "oldforms" and
"newforms" in 0.96. That way you keep backwards compatibility but
people can also leverage new features in their code.
Regards,
Zack
On Sep 20, 3:48 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Fri, 2008-09-19 at 09:08 -0700, Armin Ronacher wrote:
>
> [...]
>
> > Where are threading bugs?
>
> We're all going to find this easier if the right words are used.
> Template class instances are mutable objects that hold their current
> state. This is a design choice, not a bug. When something is done
> intentionally and works as intended, that's a design choice, not a bug.
> The distinction is important, as it leads to discussions being made as
> to the differences in opinions about the decision, not an all-or-nothing
> bug fix. It's for the same reason we don't refer to dictionaries, lists,
> sets and other mutable Python objects as having thread bugs.
>
> > Everywhere, where a tag render method
> > somehow modifies the node object. Where does this happen? From what
> > I've seen so far it's done in "block", "ifchanged", "cycle" and
> > "extends". Now, of course the attribute assignments happen for a
> > reason: they are necessary, at least for cycle and ifchanged. Block
> > and extends look like accidents, they could be solved a lot cleaner
> > (block would put a reference to a hypothetical SuperBlock into the
> > context, rather than a reference to itself) and extends doesn't have
> > to store the evaluated value on the node at all, a local variable is
> > just fine.
>
> That would change the rendering behaviour, however. Whether they were
> accidents originally or not isn't really a concern right this moment.
> Backwards compatibility is. The approach is certainly worth considering
> (we have to do something like this for reset-ability of cycling, for
> example), but the backwards-incompatible effects needs to be itemised
> and addressed as well.
>
> [...]
>
> > This used in all core tags makes the `Template` object thread safe,
> > but not the `Context` which is perfectly okay because it doesn't
> > happen (or should not happen) that a context object is shared between
> > threads. At least I don't see a situation where this is useful.
>
> All that leaves is the thousands of third-party tags. Again, trying to
> reach for some guarantee that instances can be shared between threads
> has quite an extensive set of secondary effects. It might be preferable
> to say that our current situation of being a mutable object holding
> state is not that bad, rather than causing massive disruptions to the
> userbase, since the current code still meets the "fast enough" criteria
> for a very large group of uses.
>
> > What's harder to fix is how the i18n integration translates filter
> > arguments or gettext constants (those _("foo") thingies). Currently
> > that happens very often at node/object creation rather than node/
> > object evaluation. A good example for that problem is
> > FilterExpression.__init__. The translation would have to be moved to
> > the resolve method in that case. When would a language change between
> > template compilation and rendering? If the language changes each
> > request which is a very common case on multilingual websites.
>
> That's actually a known. From memory, it's buried in a ticket talking
> about something else, but I know it's been on my list of things to
> address for a while now and pre-1.1 is probably the time frame where I'm
> goign to be doing a lot of i18n work.
>
> A quite reasonable goal is that template instances should be cacheable
> right after they've been loaded (we already know that rendering changes
> state, but right after loading they're always in the same state). That
> means being pickle-able and, later, unpickle-able in a different view
> with, as you note, a different active locale.
>
> There are actually a whole swathe of problems with the various i18n
> template tags that need to be cleaned up. They're in line behind sorting
> some of the thing like making Variable() consistent and stuff like that
> so that we can reuse the common support stuff. That will come out of
> merging the work Johannes Dollinger is proposing with the existing code.
> So there's an ordering of fixes going on there, but it's certainly on my
> personal radar.
>
>
>
>
>
> > Changing the parser to a more advanced system or making the template
> > engine more consistent is not so important for the time being, but I
> > want to raise a few situations I encountered where the behaviour is
> > confusing:
>
> > - cycle arguments are delimited by spaces and each item can be an
> > expression (however if there is a comma involved somewhere, it
> > seems like the tag is interpreted as comma separated list of
> > strings
> > which makes the 'cycle "foo", "bar", "baz"' yield unexpected
> > results.
>
> > - On the other hand
Re: Concrete django.template Suggestions
Oh, and by the way, with regards to thread safety, changes should be
made in the context, not the node. I'm currently working on a refactor
of the template system at the moment, something will be done within a
couple of days. If it's really necessary (I mean, I'm just doing it
for fun, but it might be useful).
Regards,
Zack
On Sep 20, 11:31 am, zvoase <[EMAIL PROTECTED]> wrote:
> Probably the best thing to do, if anything, is to make something new
> and get it working alongside the old system, much like "oldforms" and
> "newforms" in 0.96. That way you keep backwards compatibility but
> people can also leverage new features in their code.
>
> Regards,
> Zack
>
> On Sep 20, 3:48 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
>
> > On Fri, 2008-09-19 at 09:08 -0700, Armin Ronacher wrote:
>
> > [...]
>
> > > Where are threading bugs?
>
> > We're all going to find this easier if the right words are used.
> > Template class instances are mutable objects that hold their current
> > state. This is a design choice, not a bug. When something is done
> > intentionally and works as intended, that's a design choice, not a bug.
> > The distinction is important, as it leads to discussions being made as
> > to the differences in opinions about the decision, not an all-or-nothing
> > bug fix. It's for the same reason we don't refer to dictionaries, lists,
> > sets and other mutable Python objects as having thread bugs.
>
> > > Everywhere, where a tag render method
> > > somehow modifies the node object. Where does this happen? From what
> > > I've seen so far it's done in "block", "ifchanged", "cycle" and
> > > "extends". Now, of course the attribute assignments happen for a
> > > reason: they are necessary, at least for cycle and ifchanged. Block
> > > and extends look like accidents, they could be solved a lot cleaner
> > > (block would put a reference to a hypothetical SuperBlock into the
> > > context, rather than a reference to itself) and extends doesn't have
> > > to store the evaluated value on the node at all, a local variable is
> > > just fine.
>
> > That would change the rendering behaviour, however. Whether they were
> > accidents originally or not isn't really a concern right this moment.
> > Backwards compatibility is. The approach is certainly worth considering
> > (we have to do something like this for reset-ability of cycling, for
> > example), but the backwards-incompatible effects needs to be itemised
> > and addressed as well.
>
> > [...]
>
> > > This used in all core tags makes the `Template` object thread safe,
> > > but not the `Context` which is perfectly okay because it doesn't
> > > happen (or should not happen) that a context object is shared between
> > > threads. At least I don't see a situation where this is useful.
>
> > All that leaves is the thousands of third-party tags. Again, trying to
> > reach for some guarantee that instances can be shared between threads
> > has quite an extensive set of secondary effects. It might be preferable
> > to say that our current situation of being a mutable object holding
> > state is not that bad, rather than causing massive disruptions to the
> > userbase, since the current code still meets the "fast enough" criteria
> > for a very large group of uses.
>
> > > What's harder to fix is how the i18n integration translates filter
> > > arguments or gettext constants (those _("foo") thingies). Currently
> > > that happens very often at node/object creation rather than node/
> > > object evaluation. A good example for that problem is
> > > FilterExpression.__init__. The translation would have to be moved to
> > > the resolve method in that case. When would a language change between
> > > template compilation and rendering? If the language changes each
> > > request which is a very common case on multilingual websites.
>
> > That's actually a known. From memory, it's buried in a ticket talking
> > about something else, but I know it's been on my list of things to
> > address for a while now and pre-1.1 is probably the time frame where I'm
> > goign to be doing a lot of i18n work.
>
> > A quite reasonable goal is that template instances should be cacheable
> > right after they've been loaded (we already know that rendering changes
> > state, but right after loading they're always in the same state)
Re: Iteration over lines in uploaded files only supports `\n` line endings.
This is an issue with Python, not Django in particular, although something could be done in Django to remedy this issue. I've already encountered this problem before, and I developed a solution which may (or may not) be optimal. I implemented the solution in two parts: * The first part was a generator function which, given a file-like object, would yield lines in the file, splitting on all 3 types. It used an internal buffer and the 'str.splitlines' method. * I then wrote a file-like wrapper on top of this generator which implemented all of the necessary syntax and semantics of a readable file, fixing the issue with line endings. I'm going to be releasing this code soon as part of a larger library. I'll send you an email as soon as I've done a release. Regards, Zack On Sep 25, 2:16 am, Tai Lee <[EMAIL PROTECTED]> wrote: > In #8149 [1] I reported that `UploadedFile` uses `StringIO` to iterate > through uploaded files line-by-line, but `StringIO` only treats `\n` > as a line ending, at least in the current version. > > This effectively means we can't use line-by-line iteration over > uploaded files because we don't know what format users (who could be > using Windows, Linux, Mac, etc) will upload files. The problem is > further compounded by the fact that uploaded files may or may not > exist entirely in memory in a temporary file on the file system, > depending on the file size, which makes a work-around a little more > complicated. > > The alternatives that I see for developers using django and needing to > iterate through uploaded files are: > > 1) Save a real file on the file system, open it and then iterate > through it. > 2) Load the entire (non-chunked) content of the uploaded file into > memory and use `splitlines`. > 3) Monkey patch `File` and re-write `__iter__` in a way that supports > other line ending formats. > > #1 and #2 seem to negate the benefits that come with using > `File.__iter__`. > > The ticket was marked wontfix, but the explanation doesn't quite make > sense to me. The discussion from django-dev can be found on [2] at > 19:50 and 21:31, where it seems that the biggest objection was a gross > regular expression (and I assume the 1.0 deadline), in which case I > think it should have been marked accepted, with "patch needs > improvement". > > Although Malcolm didn't have much time to discuss the issue that day, > he did agree that because we must account for the lowest common > denominator and it's *possible* to upload files with `\r\n` and `\r` > line endings, we probably can't count on use line-by-line iteration > over uploaded files. > > Now that everyone is not so busy with 1.0, I'd like to re-open this > ticket, or at least gain a better understanding of the reasoning > behind the wontfix, because to me it seems like the opposite is true. > The reason we should support this is because we can't know the format > of uploaded files, not the other way around. > > Cheers. > Tai. > > [1]http://code.djangoproject.com/ticket/8149 > [2]http://oebfare.com/logger/django-dev/2008/08/28/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Status report on CPython 2.6
Hi, Just wondering if I could ask how compatible Django is with CPython 2.6. I know that it should work fine anyway, but I thought it a good idea just to check. Has anyone looked into this? Regards, Zack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Declarative syntax for widgets in ModelForm
I understand the motivation for this, and support the idea, but I
think the implementation is a little repetitive:
class MyForm(forms.ModelForm):
class Meta:
fields = # LIST OF FIELDS
widgets = # DICT OF FIELD NAMES : WIDGETS
Why not do something like this:
class MyForm(forms.ModelForm):
class Meta:
fields = {
'text': forms.CharField(widget=forms.Textarea(), ...),
'other_field': None,
}
Where the 'None' indicates "do the default". This way you could
completely redefine the behaviour of the model form. Putting in a list
or tuple would just do what it's always done.
Regards,
Zack
On Sep 29, 11:07 am, SmileyChris <[EMAIL PROTECTED]> wrote:
> Bah, it was just prototype code but point taken ;)
>
> I do feel like it leads to slippery slope though. LikeMichael said,
> "why stop at widgets?" I often need to change labels and help text
> too.
>
> On Sep 29, 8:56 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
>
> > SmileyChris wrote:
> > > I've always just done this by doing:
>
> > > MyForm(ModelForm)
> > > model = MyModel
> > > def __init__(self, *args, **kwargs):
> > > self.fields['name'].widget = Textarea() # or whatever
>
> > You've forgot to call `super` :-). I know that it's only an example but
> > it adds another line and also shows that such things can easily be
> > forgotten in real code.
>
> > > Do we really need another way of doing this? Or am I overlooking
> > > something that this new method introduces?
>
> > I've addressed this exact thing my first email on subject, so quoting
> > myself:
>
> > > Here the problem is that it has enough boilerplate code to be, shall we
> > > say, not beautiful. And also it defeats nice declarative nature of a
> > > ModelForm.
>
> > So, yes, it's not the end of the world but it's the same convenience as
> > `fields` or `exclude` that all could be simulated in __init__.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: HttpResponse and file-like objects
Streaming/iterable HttpResponse instances are kind of an issue which
needs sorting out. I've had problems in the past with the current
implementation. Maybe a closer look is actually necessary.
Regards,
Zack
On Oct 1, 3:41 am, David Cramer <[EMAIL PROTECTED]> wrote:
> Thanks Graham, I'll check that out.
>
> I was going to file a ticket for this, but it seems streaming isn't
> really "supported" anyways, so I had to change the approach.
>
> On Sep 30, 8:19 pm, Graham Dumpleton <[EMAIL PROTECTED]>
> wrote:
>
> > On Oct 1, 11:06 am, David Cramer <[EMAIL PROTECTED]> wrote:
>
> > > I'm running into an issue when trying to pass a file-like object to
> > > HttpResponse and telling it to label it as "application/xml"
>
> > > def sitemap(request, sitemaps, section):
> > > page = request.GET.get('p', 1)
> > > fpath = os.path.join(settings.BASE_PATH + '/', 'cache/sitemap-%s-
> > > %s.xml' % (section, page))
> > > if not os.path.exists(fpath):
> > > raise Http404
>
> > > return HttpResponse(open(fpath, 'r'), mimetype='application/xml')
>
> > > When added the mimetype, nothing gets sent to the browser. Removing it
> > > solves the issue, but then it has an invalid content type.
>
> > Nothing to do with your specific problem, but knowing how you always
> > want things to run as well as possible and how big your sitemap file
> > apparently is, may interest you to look at wsgi.file_wrapper
> > references in:
>
> > http://code.djangoproject.com/wiki/Version1.1Features
>
> > One of the tickets (7894) has patch to allow static files to be
> > returned using more optimal means provided by mod_wsgi/mod_python,
> > ie., using sendfile() or other memory mapping techniques.
>
> > Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
RFC: block_append Template tag
Dear devs,
I'd like to add a feature proposal for the 1.1 release. Basically,
at the moment the 'block' tag allows you only to override the block
you point it to, and I'd like to increase this functionality by adding
a 'block_append' tag which would allow you to append text to a block.
An example might be something like this:
# FILENAME: somefile.html
{% block css %}
{% endblock %}
some HTML code
In this case, I create a block to store all the CSS files I want to
link to in my HTML file. In a template which inherits from this, I may
want to add an additional CSS file. In order to do that now, I would
have to do this:
{% inherit "somefile.html" %}
{% block css %}
{% endblock %}
So you can see that I'm duplicating my CSS link code here. This
violates DRY in no small way; if I rename "/css/somefile.css", I have
to change every template which inherits from the old. My suggestion is
to be able to do this:
{% inherit "somefile.html" %}
{% block_append css %}
{% endblock %}
So you can see that this might be useful for CSS and JavaScript
includes in HTML, as well as some other applications in other formats
(yet to be explored). If there is some support for this idea, I'll
open up a ticket, but I wanted to run it by everyone first.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Signal Connection Decorators
I just wanted to check if there was a consensus on this; it would be nice to get it into the Django 1.1 featureset. Regards, Zack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Remove "old docs" message from Django docs
Hi, I think I might be speaking for a few people here who have kinda seen enough of the "olddocs" warning/message/admonition thing every time we search on the Django docs. It's been 2 and a half months since Django 1.0 was released, so if people are still following links from the old documentation then they probably know about it by now. It's not a pony - maybe just a "my little pony". Alternatively, cause the olddocs warning to appear only when the referrer URL is from an old docs page. That should be do-able (at the moment it's done via a GET parameter). Regards, Zack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RequestContext rarely used (branched from Feature reviews for 1.1)
I have an idea which may solve the issue of render_to_response using a
RequestContext.
Why not have render_to_response as a shortcut in django.shortcuts (as
it is now), and then add a 'render' method to the request instance
which would do render_to_response but with a RequestContext instead.
That seems logical to me, so that views could do something like this:
# Using RequestContext
def myview(request, *args):
# some code here...
request.render('template_name.html', {...})
# Using normal Context
from django.shortcuts import render_to_response
def myview(request, *args):
# some code here...
render_to_response('template_name.html', .)
That just seems logical to me. Rather than (potentially) break
backwards compatibility, let things be as they are right now and just
add a method to the request.
Regards,
Zack
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: RequestContext rarely used (branched from Feature reviews for 1.1)
I understand about the loose coupling, but I think there is some
misunderstanding about the very nature of 'loosely coupled'. Coupling
has to do with *dependency*, not just utility. Adding a decoupled
method to the request is not a restrictive assumption, it is what it
is - a shortcut. No-one is 'forcing' a user to call the method, and
nothing will depend on the coupling given by render_to_response. Tight
coupling is only ever a problem when there are dependencies on the
coupling; then it gets messy.
Indeed, we could argue that the admin interface is disgustingly
coupled - the template layer, the database layer, the URLconf and the
views are all so very intricately coupled, but the thing is, no-one is
*depending* on the admin app to be loosely coupled (and permit the
interchange of ORMs, etc.), so it's not an issue. Likewise for a
proposed request.render method. It's just an issue of what namespace
it is in, and putting it under request will be a quick way of saving
verbosity, time and money. No death or injury will occur in the
process, I assure you.
On Nov 21, 5:25 am, "Waylan Limberg" <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 20, 2008 at 10:23 PM, Yuri Baburov <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Nov 20, 2008 at 9:47 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
> >> On Thu, Nov 20, 2008 at 6:19 AM, zvoase <[EMAIL PROTECTED]> wrote:
> >> ...
> >>> # Using RequestContext
> >>> def myview(request, *args):
> >>># some code here...
> >>>request.render('template_name.html', {...})
> >> ...
>
> >>> That just seems logical to me. Rather than (potentially) break
> >>> backwards compatibility, let things be as they are right now and just
> >>> add a method to the request.
>
> >> Except that it couples request and response objects to templates.
>
> > But render_to_response also does that?
> > You want request and response to be loosely coupled? Does it make
> > sense? Aren't they coupled in render_to_response and response
> > processing code anyway?
>
> > Please explain your point a bit more.
>
> render_to_response is a "shortcut" that makes a few assumptions to
> cover a common use case and helps keep your views DRY. If you changed
> your template system or various other pluggable components, you would
> either need to write your own version of render_to_repsonse or repeat
> yourself often in your views. However, by making render a method of
> the request, we are now taking those assumptions another level and
> forcing them on the request object itself. That's bad.
>
> You see, anyone can use Django any way they want and don't have to use
> any of the "shortcut" helper functions. However, everyone has to use
> the request and response objects, so the code needs to make as few
> restrictive assumptions as possible in those objects. And yes, making
> it easy for someone to use a different template system is a feature
> that we want to keep.
>
> --
>
> Waylan Limberg
> [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Dropping Python 2.3 compatibility for Django 1.1
+1 For me, too. If people want to use the cutting-edge Django release then they can at least update Python to 2.4 (which is now 4 years old anyway). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: deprecate and remove django.utils.simplejson
I think a better approach would be to have django.utils.simplejson as a sort of alias package (which is easy using Python's introspection). What would happen is this: A user imports either django.utils.simplejson, or something from inside it. We look for the 'json' package on the path (Python 2.6 stdlib). If found, use this. We look for the 'simplejson' package on the path. If found, and with a more recent version than the bundled version, use this. Otherwise, we have a bundled version which gets used. That way, we can be relatively sure of the stability of the simplejson we're shipping, but if a user wants the bleeding edge library then they can just keep doing things the same way but install simplejson (or use Python 2.6). Don't forget that the bug-fixing of simplejson will probably grind to a near-halt now it's part of the stdlib, only being updated every release of Python. This means that we can bundle a recent version and be relatively secure that no major changes will be made. I don't think this is nearly as big a problem as it's made out to be, and I for one like the security of knowing I can always just import django.utils.simplejson as a "guaranteed to be there" JSON library. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Nipping projects in the butt
By the way, the saying is "Nipping (X) in the bud." It has to do with cutting a flower before it's grown past the bud stage. No butts I'm afraid ;-). On Dec 10, 12:09 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On Tue, Dec 9, 2008 at 9:24 PM, Christopher Allan Webber > > > > <[EMAIL PROTECTED]> wrote: > > > So, by now the primary problem with Django is not the lack of good > > applications. There are tons of good applications. The primary problem > > is that almost none of them work together. There are a few reasons for > > this... some of it has to do with templating, some of it has to do with > > people not using url reversal, and some of it has to do with the fact > > that most large django applications want to install some non-models > > related administrative ability to the django admin, so most of them > > override the admin templates in ways that make them incompatible. But > > by far the biggest problem (and which encourages these other problems > > even more) is projects. > > > Projects! > > > I probably don't need to go into detail about *why* projects are bad. > > That's been discussed plenty before: > >http://groups.google.com/group/django-developers/browse_thread/thread... > > > But it's such a shame... we know that we're teaching bad habits from the > > very beginning. We know that tying applications to a specific project > > make those applications either unusable or very difficult to use with > > installations outside that project. And yet we still teach it! And the > > vast majority of users still follow these bad teachings. Some of the > > best, most high profile django projects follow these bad practices, like > > Review Board. And it isn't their fault! > > > If there was a cancer that was rapidly spreading through sexual contact, > > but which was preventable by being vaccinated early on, what would the > > best thing to do be? Sure, it's worth our time to treat the victims, > > but it's much less costly if we just stop the problem upfront by > > vaccinating. In fact, it's even worse. It's like we're handing our > > users a bottle of lube known to be contaminated with the stuff and > > saying, "Here you go guys, apply liberally." > > > Okay, that analogy starts to break down when you think about it too > > much. But the point is, it's easier to prevent by teaching good > > practices from the get-go. > > > So, django's documentation is already suggesting that we want users to > > do the right thing: > > > Philosophy > > > Django apps are "pluggable": You can use an app in multiple projects, > > and you can distribute apps, because they don't have to be tied to a > > given Django installation. > > > Unfortunately, this is telling users that right after telling them how > > to set up their site structure with "startproject". And there is no > > mention, here or later, that there is a better way of doing things, and > > a pointer to whatever kind of document would help describe that way. > > > In the previous discussion, James Bennett listed two solutions to this: > > > 1. Expand the default application skeleton, or differentiate somehow > > between a minimal, "traditional" app skeleton and a more robust one > > which includes files and directories oriented at a distributable > > application. > > > 2. Spend a lot more time documenting best practices of application > > development, possibly even mentioning in the tutorial that the > > "apps inside project" model it uses is followed for convenience and > > not because it's the best/only way to work. > > > People seemed to be in favour of number two, which is "Teach the bad > > habits with an emphasis that these habits are bad, and that there is > > documentation to do things right." I think this is fine (teachers and > > professors do this all the time with their intro students)... we just > > need to do it. > > > I am more than happy to help with writing up documentation, whatever. I > > just want to see django applications work together as a big, happy, > > pluggable family. > > Then what are you waiting for? Start writing. It's easy to tell others > what needs to be done. It's a lot harder to actually do the work. > > We are only too happy to accept any offer of help to improve our > documentation. However, that help needs to come in the form of a patch > to documentation, not as a "hey guys, you know what you should do" > post on a mailing list. We already know that our documentation could > be better. There are any number of new tutorials, howtos and guides > that could be written that would be of benefit to the Django > community. What we don't have is an infinite supply of time to turn > these ideas into reality. > > If you want to help out, we're only to happy to provide feedback or > advice during the drafting process. However, the only meaningful > feedback we can provide on a concept is "Sounds great, show us a > draft". > > So Sounds great! Show us a draft! :-) > > Als
Re: Django Migrations
To begin with, my first impressions are that it's a really good solution, and I'm interested to see how it shapes up in production apps :) I'm slightly concerned with having to link to it from django.contrib. This is generally regarded as a bad idea, mainly because it makes it difficult to get up and running. I think the general consensus is that you should have it installed at the top level as 'migrations' (the name is available on pypi–reserve it quickly!), so that people can just do easy_install migrations or pip install migrations, etc. Also, this introduces a difficulty when people are using eggs, or may not necessarily know how to get to their site-packages directory (you'd be surprised how many Django users are Python novices). Regardless, I'm looking forward to using this migrations app in the future - It looks really good. Thanks a lot for your work! Regards, Zack On Jan 3, 7:13 am, "Brantley Harris" wrote: > Yeah, the tutorial is right > here:http://www.bitbucket.org/DeadWisdom/migratory/wiki/Tutorial > > On Fri, Jan 2, 2009 at 6:57 PM, Yuri Baburov wrote: > > > Could you please write some tutorial on your page, how does the > > migration process looks like with your app? > > > On Sat, Jan 3, 2009 at 2:29 AM, Brantley Harris > > wrote: > > >> Having not been content with the state of Django migrations systems, > >> I've created one of my own: > > >>http://www.bitbucket.org/DeadWisdom/migratory/ > > >> The idea is a database migration system that: > >> * Is simple. > >> * Doesn't make you use sql. This is an orm, we shouldn't have to use > >> sql. > >> * Can be automatic. Predicts the migration script for you so you > >> don't have to think about what has changed. > >> * Works well in a version control system, or even distributed > >> ones. Because damnit. > >> * During the migration process, *allows you to use the state of > >> your previous models as if they were still there*. This is key, and is > >> not done anywhere else, as far as I know. > > >> Currently it's tested on mysql, postgresql_psycopg2, and sqlite3. > > >> Thanks. > > > -- > > Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, > > MSN: bu...@live.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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 -~--~~~~--~~--~--~---
RFC: Asynchronous Signal Receivers
Hi Developers, Basically, I wanted to ask for some devel's opinions on something. When using the Django signals framework (which, by the way, is a very good way of decoupling reusable apps whilst allowing for deep integration), I sometimes find that a signal receiver does not need to be called in synchronicity with the rest of the receivers. To demonstrate, I'm going to explain a common scenario when it might be useful to have *asynchronous* signal receivers, and why I feel there should be a special provision made for them in the signals framework. Let's suppose I have a comments app, and I write a signal which is 'fired' when a new comment is posted. Now let's assume I also write a mail notification app which listens for this signal. When a comment is posted on an object, the owner of the object is notified via e-mail. For argument's sake, let's also assume that this app is *not* using a mail queue which is flushed several times a day via a cron job - the owner should be notified as soon as possible after the publication of the comment. This means that the mail notifier's receiver function must send the e-mail when called. This raises the issue that e-mail may take a while (i.e. from a few seconds to a couple of minutes) to send; it is after all operating over a network connection. This is unacceptable, as we would ideally like to minimise latency in the HTTP response. At the moment, the Signal class processes receivers in serial; one must finish execution before the next may begin. It is not, however, *critical* that this e-mail is sent before the next receiver is processed; it may be put into the background in another thread, and finish within a reasonable amount of time. An obvious solution to this problem is to use threading or forking, thus placing the sending of the e-mail into the background. From my receiver function I can do this by creating a new thread and starting it, then returning after starting the thread without ensuring that the sending of the e-mail has been completed. However, we run into a snag whereby a thread is being created, started and left alone, without any conceivable way of 'reigning it back in'. This could result in major memory leaks or undetected infinite loops, and there is no obvious way of creating a thread from within the receiver function *without* this problem. So, taking the idea of threading but reworking it slightly, there is another way to deal with the problem. If the Signal object were aware that a particular receiver function (or a collection thereof) were to be run in the background, then it could essentially start all of these tasks in tandem and also create a controller, which could be passed back to the sender of the signal. This controller will contain all the thread instances, and might have a 'join' method which would wait until they had all finished executing; an infinite loop or memory leak would therefore be controllable, or at least detectable, as the threads would be referenced within the scope of the sender. Applying this solution to the problem of e-mail sending, I would write a function as before that sent an e-mail in the usual way. I would then use the typical 'signal.connect' method to connect my receiver to the signal, but pass in an 'async=True' keyword argument. Then, when a comment is posted, a new e-mail-sending thread is created, along with a thread controller (itself probably just a subclass of list with a 'join' method, or something along those lines). This would send the e- mail and finish execution, without holding up my view function where I've added the comment. I hope I've made my rationale for this feature clear. I've sent it to the mailing list first because I think it's something which could be debated (at a good length). The inclusion of asynchronous signal receivers will help Django's signals framework in becoming a mature message-queueing solution, and I think that the use of signals is invaluable to properly decoupling functionality whilst maintaining a state of integration between a diverse sets of Django applications. Regards, Zack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: RFC: Asynchronous Signal Receivers
First, I'll address Alex's concerns. Basically, an async decorator would work fine for some things, but it helps to be able to co- ordinate the threads. Look at it this way; when something uses TCP, for example, it's going to take a certain finite amount of time for the TCP request to occur. Without asynchronicity, that time is going to be spent by the interpreter doing nothing, meaning other computations which might take some time and *could* be going on now, aren't. So even though you're waiting for them all to complete at the end, you're still saving time. Even if there was a simple decorator which could be used, maybe it's a good idea to include that decorator in Django; I could see it being useful to some people. Now on to Eric's comment: > If you ask me, a message queue sits quite firmly outside the realm of > what a web framework should be responsible for providing. I think you > are also underestimating the amount of effort and thought that goes > into writing a robust and scalable message queue. There is already at least one other web framework I know of (http:// appcelerator.org/) which provides message queuing functionality as an important part of the framework itself; I think that we're going to start seeing a lot more of this sort of thing in web frameworks over the next few years. Message passing is, as you say, a consideration when trying to scale. I'm also not saying that Django should try to re- implement something like Apache ActiveMQ, etc., but that a system which tried to encapsulate some of these concepts wouldn't do the framework any harm. > For one simple example: what if Apache decides to kill or restart the Django > process > after a certain amount of requests have been processed (and I know > that many people have their servers set to do this)? The threads > which were are running asynchronous tasks would be killed as well, > losing any tasks which hadn't yet been completed. To be honest, I hadn't thought about that; that indeed would make it difficult to implement async signals. However, the aggregated 'join' method could be called after the receivers have all finished, as Apache will not terminate the Django process until all requests have been handled; so there are probably ways around this. Also, I didn't know about engine, thanks for telling me about it. The concept looks quite good, and I'm very intrigued to find out more now... Thanks for your feedback so far. This is why I sent it to the mailing list in the first place :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: RFC: Asynchronous Signal Receivers
On Jan 4, 11:10 am, Graham Dumpleton wrote: > Not true, Apache doesn't necessarily wait for all current requests to > complete before shutting down child worker processes. For a non > graceful restart or shutdown, Apache will give the process about 3-4 > seconds to exit and if it doesn't exit then it will kill it. Thus if > there were active requests which take longer than that to complete, > then they will be interrupted. > > There is a bit more to it than this but exact details depend on which > hosting mechanism you are using in conjunction with Apache. > > Graham But if we're doing a non-graceful restart, then we can say goodbye to *any* hopes of things finishing nicely. In this case, Apache is forcefully terminating a process; ideally a set-up where processes were being killed in the middle of their execution is not going to use asynchronous *anything*, and also will want to have all DB work going on in transactions; having an Apache which just keeps killing stuff is going to be dangerous for code no matter what. And it shouldn't be taking 4 seconds for the user to receive a request, so by the end of that time all work should be done. If something *needs* to be done asynchronously that's going to take more than several seconds, then it should probably be delegated to a daemon running separately from the web server. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: RFC: Asynchronous Signal Receivers
On Jan 4, 10:27 am, "alex.gay...@gmail.com" wrote: > Ok, but you're original concern was that what happens if say you go to > send an email and "raises the issue that e-mail may take a while (i.e. > from a few seconds to a couple of minutes) to send;", ultimately if > you join on that thread than you've reduce the overhead insofar as the > new length of the request is now length(sending the email) - amount of > the time the rest of the stuff you do before you join() takes, but if > it's taking 30 seconds to send the email, you're still ultimately > going to be taking a minimum of 30 seconds to serve that request. That's true, but then if e-mail is taking 30s to send you're probably going to need to fix that as a bottleneck; this might be a nice solution to a problem, but it won't be able to fix *everything*. Not to mention that if it's taking 30s for 1 email, a batch system is going to take ages to flush the e-mail queue. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: RFC: Asynchronous Signal Receivers
On Jan 5, 12:54 am, Malcolm Tredinnick wrote: > On Sun, 2009-01-04 at 06:19 -0800, zvoase wrote: > > On Jan 4, 11:10 am, Graham Dumpleton > > wrote: > > > Not true, Apache doesn't necessarily wait for all current requests to > > > complete before shutting down child worker processes. For a non > > > graceful restart or shutdown, Apache will give the process about 3-4 > > > seconds to exit and if it doesn't exit then it will kill it. Thus if > > > there were active requests which take longer than that to complete, > > > then they will be interrupted. > > > > There is a bit more to it than this but exact details depend on which > > > hosting mechanism you are using in conjunction with Apache. > > > > Graham > > > But if we're doing a non-graceful restart, then we can say goodbye to > > *any* hopes of things finishing nicely. In this case, Apache is > > forcefully terminating a process; ideally a set-up where processes > > were being killed in the middle of their execution is not going to use > > asynchronous *anything*, and also will want to have all DB work going > > on in transactions; having an Apache which just keeps killing stuff is > > going to be dangerous for code no matter what. And it shouldn't be > > taking 4 seconds for the user to receive a request, so by the end of > > that time all work should be done. If something *needs* to be done > > asynchronously that's going to take more than several seconds, then it > > should probably be delegated to a daemon running separately from the > > web server. > > Your response here and in a couple of earlier mails are pointing you in > the right direction. You've arrived at the point where asynchronous > signals are not a good idea. The approach is to synchronously set up an > entry in your external queue system to process anything that is going to > take a long time. The signal processing is thus very short and the > long-term operations are in no way tied to webserver process lifecycles > or client wait times or anything. It's directly analogous to top-half / > bottom-half interrupt handlers in operating systems, for example. > > I don't see the requirement for extra signal infrastructure complexity > in anything you've written in this thread. All your examples seem much > better handled by dispatching to an external processing queue. > > Malcolm Yeah, I suppose so :) Well thanks a lot everyone, you've helped make things a bit more clear, and this thread is also probably going to be useful for future reference for anyone who's thinking of bloating the signals framework ;-) Regards, Zack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: #3566 Aggregations: Call for testing
Just a question - how, if at all, is aggregation going to be supported or worked around on custom field types? On Jan 6, 8:14 am, "Ian Kelly" wrote: > On Mon, Jan 5, 2009 at 9:21 AM, Alex Gaynor wrote: > > The one's that are a result of Oracle not returning a Decimal can be solved > > be inserting "..." before and after the number, in placeess of explicitly > > saying Decimal(unless of course this is actually a typecasting issue in > > Django itself, in which case that should be fixed) this is done a few other > > places in aggregates regress. > > The Decimal conversion might fail to happen if the corresponding field > passed to resolve_columns is not a DecimalField. This happens for > instance when using extra selects, where no field object is available. > My guess is that the fields for the aggregate columns are getting > excluded or misaligned somehow. This could also be the cause of the > datetime/time issue. > > > The SQL command not properly ended appears to be the result of an annotate > > call followed by a call to aggregate(). I don't have a clue what causes > > that as I've used Oracle in my life :) . > > I'll take a look at the queries tomorrow and see if I can straighten them out. > > Ian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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: pychecker catches IndexError exception while importing /django/db/models/base.py
I think I might be able to spot where the problem is. Try running
pychecker on your app folder, rather than models.py.
Let's assume your app is called myapp, so you have a directory
structure something like this:
myapp/
-- __init__.py
-- models.py
-- views.py
-- tests.py
(et cetera)
If pychecker were doing 'import myapp', then the models module would
be accessible from 'myapp.models'. Therefore, models_module's __name__
attribute would be 'myapp.models', and the code would run fine;
'myapp.models'.split('.') would return ['myapp', 'models'], and the
[-2] index of that list would be 'myapp'.
However, because you're running pychecker directly on the models.py
file, its __name__ attribute is just 'models', which raises an error
in the Django code because 'models'.split('.') returns ['models'] --
this has no [-2] index, hence the exception.
Just try running pychecker on the 'myapp/' folder (if possible), and
see if that fixes the problem.
On Jan 22, 10:22 pm, ivan wrote:
> Hi all,
>
> I'm attempting to run pychecker on my django code (an application's
> models.py file) and get the following output:
>
> $ pychecker models.py
> Processing models...
> Caught exception importing module models:
> File "/var/lib/python-support/python2.5/pychecker/checker.py",
> line 619, in setupMainCode()
> File "models.py", line 538, in ()
> File "/usr/lib/python2.5/site-packages/django/db/models/base.py",
> line 51, in __new__()
> IndexError: list index out of range
>
> Warnings...
>
> models:1: NOT PROCESSED UNABLE TO IMPORT
>
> My django version is '1.0.2 final'.
>
> The IndexError happens on the final line of code extract below:
>
> # Figure out the app_label by looking one level up.
> # For 'django.contrib.sites.models', this would be 'sites'.
> model_module = sys.modules[new_class.__module__]
> kwargs = {"app_label": model_module.__name__.split('.')[-2]}
>
> I added a 'print model_module.__name__' above this line and I get the
> following output before the exception:
> django.contrib.contenttypes.models
> django.contrib.auth.models
> django.contrib.auth.models
> django.contrib.auth.models
> django.contrib.auth.models
> models
>
> Not sure if the last models that triggers the exception is the models
> file I ran pychecker on or another file? I have all my django env
> variables set up correctly and can do runserver, dbshell ,etc.
>
> Any ideas as to why pychecker on my models file would throw this
> exception in the base django models file?
>
> thanks,
> ivan.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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
-~--~~~~--~~--~--~---
RFC: Settings 'modes' or 'flavors'
Hi all, Recently I wrote a blog post (http://bit.ly/HM3hC) on my project conventions; it began by talking about how I like to maintain different settings 'modes' for debugging, staging and production, and the ways in which I do this. I've had quite a few responses from Djangonauts on how they all do this, and it seems that this really is a pattern. In keeping with Django's DRYness principle, it would probably be better to factor some of this out into the Django codebase. There are several advantages to be had from this prospective feature. Firstly, and most obviously, there's the benefit that it would ease the administration and deployment of large-scale projects across multiple machines. Secondly, it would provide open-source projects (for example, Pinax; see http://pinaxproject.org) a way to distribute sensible defaults with their source code, yet also allow continuously- integrated deployments to use custom (and potentially sensitive) settings, such as database authentication parameters. Thirdly, it would mean reducing a lot of commonly-rewritten code - a lot of the commentors (or should that be 'commenters') on my aforementioned blog post have their own way of doing it, which they've clearly put effort into thinking up and working on. There are probably a couple more advantages, but these are just the ones I can think of. There seem to be several ways of doing this; if we could decide on the best (or at least the easiest for Djangonauts to work with), then we might be able to take a step towards one of two things: 1) Core support for this feature. 2) A contrib app implementing this feature. Again, each probably has its own advantages; I thought it best to start this discussion here so that the community could work out what the best route to take is. There was something of a commversation (comment conversation) occurring on my blog post; a list discussion is no doubt a better way of handling this issue. So what do you think? Regards, Zack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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 -~--~~~~--~~--~--~---
