form action="."
Chapter 7 of The Django Book says this: The action="." means “Submit the form to the same URL as the current page.” I'm not sure this is standard or not, but it doesn't do what's expected at least on Firefox 3.0.6 (Iceweasel of Debian 5.0 stable): the form is simply submitted to an emtpy URL "/", which Django's web- server logs on the console: [08/Mar/2009 14:26:07] "GET /search HTTP/1.1" 200 205 [08/Mar/2009 14:26:10] "GET /?q= HTTP/1.1" 200 17 i.e. the first line shows me opening the form, and the next one logs form submission, i.e. no HTTP-level redirects are ever done. my urlpatterns looks like this: ... (r'^search/*$', search), ... that is, the trailing slash is optional. Very interestingly, the "." action submits correctly to itself only if I open the form as "http:// example.com/search/", not as "http://example.com/search"; in the first place, as the Django Book recommends. So it would be more correct to say that "action="." submits the form to the same URL up to and including the trailing slash, ignoring everything after it". --~--~-~--~~~---~--~~ 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: form action="."
On Sun, 2009-03-08 at 03:37 -0700, rihad wrote: > Chapter 7 of The Django Book says this: When the updated version of Chapter 7 of the django boook is released online, if the same description persists, it would be worth making a comment over there. Although the book is written by two of the primary authors of Django and being updated by one of them (Adrian), this list isn't the place to report bugs, since we have nothing to do with the content of that book. Basically, though, any relative URL is going to relative to the portion of the URL prior to (and including) the final slash. It behaves identically to relative paths in filesystems in that respect. That's one of the reasons why ending most URLs that don't request a particular static file with a trailing slash isn't a bad idea. It makes relative URLs a little easier to control: you don't have to know the name of the current page to submit a form back to itself. 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Declarative fixtures for django
Hey Ben, I don't have a lot (well, any) time to really give this the attention it deserves at the moment. But a couple of quick thoughts so that you don't think it's been entirely overlooked. I agree with the general thrust of what you're talking about and it's good to see questions about keeping it external for now. On Fri, 2009-03-06 at 12:48 +, Ben Ford wrote: [...] > A fixture would look like: > > from fixture import DataSet > class app__Author(DataSet): > class frank_herbert: > first_name = "Frank" > last_name = "Herbert" > class guido: > first_name = "Guido" > last_name = "Van rossum" This is one of those cases where I have to ask why you're using a class instead of a dictionary. You're mapping keys (initialisation parameters) to values (the values to set the parameters to). Using a map object seems like the way to go. It doesn't carry the necessary indentation requirements with it, for a start. > [...] > > So I have a few questions on where to go next... > 1. What's the best way to integrate with django's test framework > (Transactions, the test client etc). Subclass django's > TestCase or something else? I'd look at that approach first. Looks like you'd need to override the _pre_setup() method. This seems like a very easy question to answer. Why isn't the "yes" just the obvious answer? Is there some hidden shoal in there? > 1. I've written some validation code, I'd appreciate it if > someone could have a look through this module particularly the > field_is_required function and the _check_schema method and > tell me if there's a better way to do it. This is one of those things I'm going to have to postpone for a while until I have more time. You're on the boundary of repeating a bunch of internal code (particularly from django.db.models.base.Model) by the looks of it, without constructing models. I'd be looking at closely whether you can reuse more of the existing stuff. One general observation: The existing fixtures code, for all its edge-case fragility, doesn't seem to have any real design constraints stemming from the requirement that it creates Model instances and saves them (calling Model.save_base(raw=True)). Any particular reason you're not going down that path? You'd get all the error checking for free. You also don't avoid the problems such as MySQL + InnoDB not having deferrable constraint checking: none of that is a restriction of the Model layer. > 1. At the moment you can only specify a relationship from the > direction that the field is defined. i.e as we have Book -> fk > -> Author you can't write a dataset the does: > class app__Author(DataSet): > class auth1: > ... > books = [app__Book.book1, ...] > > I made it work this way to simplify development, but I'm wondering if > it's the right decisoin. Is this desirable behaviour? Try to implement the reverse direction as well, but don't lose sleep if you can't, I'd suggest. :-) When you have access to the models, you know the names Django uses to refer to them, so you can use the same names in the fixture descriptions. For example, If Child -> Parent, exists, then the Parent fixture could define stuff for "child_set" (or the right related name). In the past (not Django, but in general coding), I've found it beneficial to write unit tests for third-party code to ensure it doesn't change some piece of behaviour we were relying on (or that our patched version didn't forget to be patched). Being able to specify fixtures for all related models in those cases could be useful. It's a question of how strictly you want to define the word "unit" in "unittest" (and Django takes a pretty liberal position there, which isn't necesasarily a bad thing). You've currently said that people can test an app and everything it refers to. But not test things that depend on that app. That's not a horrible restriction: facing only in the direction of upstream dependencies. But if you can make it worth both ways, why not? 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Request Signals
Hi, I've been looking at ways to add more dynamic logging to my applications and naturally looked to the django signals as a way to do it. I'm unsure of the logic behind the request handler class being returned in the request_finished and request_started signals, rather than the actual instance. I was wondering if some more enlightened developer could explain the logic behind such a decision - one of the lines of code in question is in core.handlers.wsgi line 246: signals.request_finished.send(sender=self.__class__) I'm pondering why the instance itself is not sent, as this would contain lots of pertinent information. I'm speculating it could be for a few reasons - to ensure that the handler is garbage collected after each request - if loads of pointers are floating about, then a badly written signal handler could cause some sort of memory leak? Or perhaps to avoid a signal handler mutating the request handler? Either way - it'd be useful to actually have the instance available - I'm interested to whether I guessed the reasons right? Thanks, Peter (I deliberated whether this was a django-users question, but as I'm more interested in the motivation of the decision rather than a fix, I figured this was the right 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 -~--~~~~--~~--~--~---
testclass
hi, I'm having a working django application. I want to see the values of my variables when I'm executing my code. something like JUnits containertest for java. I'm tried to test a method in my views.py code. The method is called generate_html( ). when i write a test class like: -- import views generate_html(123) - (the number 123 is just a number i want to display. ) I want to put a breakpoint at the generate_html i get and run my test but: Traceback (most recent call last): File "/Users/eenpint/Documents/workspace/projects/probis/offerte/ tomtestclass.py", line 2, in import views File "/Users/eenpint/Documents/workspace/projects/probis/offerte/ views.py", line 4, in from django.http import HttpResponse ImportError: No module named django.http so he doesn't know the django.http import that i use in the views class. Why does he knows this when i run my server with the "python manage.py runserver" -command. but he does not know it when i try to run my test. so i have two questions: - how can i let my test work - perhaps somebody knows a better way to test my application thanks in advance, tom --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-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: Request Signals
Hello Peter, I believe you can catch the instance in a middleware class. I'm sure a better developer or someone on the core team can explain better than me. Jamie Rumbelow -Original Message- From: django-developers@googlegroups.com [mailto:django-develop...@googlegroups.com] On Behalf Of PB Sent: 08 March 2009 12:54 To: Django developers Subject: Request Signals Hi, I've been looking at ways to add more dynamic logging to my applications and naturally looked to the django signals as a way to do it. I'm unsure of the logic behind the request handler class being returned in the request_finished and request_started signals, rather than the actual instance. I was wondering if some more enlightened developer could explain the logic behind such a decision - one of the lines of code in question is in core.handlers.wsgi line 246: signals.request_finished.send(sender=self.__class__) I'm pondering why the instance itself is not sent, as this would contain lots of pertinent information. I'm speculating it could be for a few reasons - to ensure that the handler is garbage collected after each request - if loads of pointers are floating about, then a badly written signal handler could cause some sort of memory leak? Or perhaps to avoid a signal handler mutating the request handler? Either way - it'd be useful to actually have the instance available - I'm interested to whether I guessed the reasons right? Thanks, Peter (I deliberated whether this was a django-users question, but as I'm more interested in the motivation of the decision rather than a fix, I figured this was the right place) No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database: 270.11.9/1989 - Release Date: 03/07/09 18:43:00 --~--~-~--~~~---~--~~ 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: testclass
On Mar 8, 2009, at 12:06, nenduvel wrote: > so i have two questions: > > - how can i let my test work > - perhaps somebody knows a better way to test my application This is a "how do I?" sort of question. The best place to ask those is the django-users mailing list. This list is for the internal development of Django itself. - 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: testclass
sorry about that. i will post it there. On 8 mrt, 15:23, Ludvig Ericson wrote: > On Mar 8, 2009, at 12:06, nenduvel wrote: > > > so i have two questions: > > > - how can i let my test work > > - perhaps somebody knows a better way to test my application > > This is a "how do I?" sort of question. The best place to ask those > is the django-users mailing list. This list is for the internal > development of Django itself. > > - 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: 'week_day' starting with sunday as first day of a week need to be fixed
> Would it be possible to use cron's weekday numbering? Would that make > anyone happy? > > 0-7, with both 0 and 7 representing Sunday. That would at least avoid > the %7 part of the workaround (from the user's perspective, anyway). I think that would be a very good compromise. I'll happily work on a patch if the consensus is to accept 0 and 7 as numbers for Sunday. Best, Jannis --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
sessions are not lazily created
Memcached-backed sessions seemed to be created, even when the session is not written to. This is what I'm finding when I look at my memcache after hitting a page that does not use sessions. Thus, if an app uses sessions (but not much), memcache will fill up with empty sessions. (the same thing might happen with database-backed sessions, but I did not check that). Just wondering if there is a reason why session creation is not lazy and only created when needed. --~--~-~--~~~---~--~~ 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: Declarative fixtures for django
Hi Malcolm This is one of those cases where I have to ask why you're using a class > instead of a dictionary. You're mapping keys (initialisation parameters) > to values (the values to set the parameters to). Using a map object > seems like the way to go. It doesn't carry the necessary indentation > requirements with it, for a start. > This is just the way fixture does it, I found it a bit of a paradigm shift at first, but I actually really like it now, for one thing it allows you to do: class app__Model(DataSet): class generic_instance: field_one = ... lots of other generic fields here class another_instance(generic_instance): different_field = ... other_overridden_field = ... In this instance you can define fields on generic_instance that will be present unless overridden in another_instance. I also allows for the mechanism of referring between DataSets. See http://code.google.com/p/fixture/source/browse/trunk/presentations/ for more of that back story, usage and motivation behind fixture. > > > I'd look at that approach first. Looks like you'd need to override the > _pre_setup() method. This seems like a very easy question to answer. Why > isn't the "yes" just the obvious answer? Is there some hidden shoal in > there? The testing landscape has changed a bit since I looked in detail, and DataSets are loaded in a transaction as well so I guess the waters are potentially a bit cloudy WRT transactions and fixture loading. Fixture also provides some niceties for loading fixtures so it may come down to a choice of a fairly vanilla subclass of unittest's TestCase as opposed to a subclass of django's overriding _pre_setup() > > This is one of those things I'm going to have to postpone for a while > until I have more time. You're on the boundary of repeating a bunch of > internal code (particularly from django.db.models.base.Model) by the > looks of it, without constructing models. I'd be looking at closely > whether you can reuse more of the existing stuff. Yes this was what I was getting at really, it's been some time since I played around with the internals of django models, (pre qsrf) so things have changed a bit. I'd much rather do this with existing django code the roll my own stuff which is overly familiar with django's privates so to speak! > > One general observation: The existing fixtures code, for all its > edge-case fragility, doesn't seem to have any real design constraints > stemming from the requirement that it creates Model instances and saves > them (calling Model.save_base(raw=True)). Any particular reason you're > not going down that path? You'd get all the error checking for free. This was what I was after... I wasn't going down that path because I didn't know about it, thanks for the steer! :-) > > > You also don't avoid the problems such as MySQL + InnoDB not having > deferrable constraint checking: none of that is a restriction of the > Model layer. Sound far preferable to the way I've done it then. > > Try to implement the reverse direction as well, but don't lose sleep if > you can't, I'd suggest. :-) > > When you have access to the models, you know the names Django uses to > refer to them, so you can use the same names in the fixture > descriptions. For example, If Child -> Parent, exists, then the Parent > fixture could define stuff for "child_set" (or the right related name). That's pretty much what I thought. I started off this way to constrain what I would have to cater for, but it would seem reasonable and more flexible to let people so it either way. The one case where it might not work would be a non-nullable ForeignKey. I will investigate, I have a suspicion that fixture might have catered for this already. > > In the past (not Django, but in general coding), I've found it > beneficial to write unit tests for third-party code to ensure it doesn't > change some piece of behaviour we were relying on (or that our patched > version didn't forget to be patched). Being able to specify fixtures for > all related models in those cases could be useful. It's a question of > how strictly you want to define the word "unit" in "unittest" (and > Django takes a pretty liberal position there, which isn't necesasarily a > bad thing). You've currently said that people can test an app and > everything it refers to. But not test things that depend on that app. > That's not a horrible restriction: facing only in the direction of > upstream dependencies. But if you can make it worth both ways, why not? Yep, this would be quite a nice aim, if an upstream app already had tests and was using fixture, then you could use those fixtures to provide the data where your models are referring to the existing ones. Thanks for your time on this Malcolm, it's certainly given me an idea of what to look at next and where I might be reinventing the wheel! Cheers, Ben -- Regards, Ben Ford ben.for...@gmail.com +447792598685 --~--~-~--~
Re: form action="."
> When the updated version of Chapter 7 of the django boook is released > online, if the same description persists, it would be worth making a > comment over there. Well, I'd hate sounding mean, but the wording was already taken from v2.0: http://www.djangobook.com/en/2.0/chapter07/ > Although the book is written by two of the primary > authors of Django and being updated by one of them (Adrian), this list > isn't the place to report bugs, since we have nothing to do with the > content of that book. Good idea, thanks. I can't use the comment system, though: nothing happens according to the docs at http://www.djangobook.com/about/comments/ --~--~-~--~~~---~--~~ 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: sessions are not lazily created
Are you using the auth middleware? If so it will be hitting the session each query, even if your stuff doesn'tm Alex On 3/8/09, Dennis wrote: > > Memcached-backed sessions seemed to be created, even when the session > is not written to. > > This is what I'm finding when I look at my memcache after hitting a > page that does not use sessions. > Thus, if an app uses sessions (but not much), memcache will fill up > with empty sessions. > (the same thing might happen with database-backed sessions, but I did > not check that). > > Just wondering if there is a reason why session creation is not lazy > and only created when needed. > > > > -- "I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ 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: Declarative fixtures for django
On Mar 8, 2009, at 19:01, Ben Ford wrote: > class app__Model(DataSet): > class generic_instance: > field_one = ... > lots of other generic fields here > > class another_instance(generic_instance): > different_field = ... > other_overridden_field = ... class app__Model(DataSet): generic = dict(field_one=foo, field_two=quux) another = dict(generic, field_one=bar) - 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Milestones and roadmap cleanup - thanks!
Jacob, thanks for the great work on Trac cleanup! This makes the devs intentions and goals so much more transparent. I especially like that we have a somewhat official ticket-set-based roadmap now (http:// code.djangoproject.com/roadmap ) instead of the manual one (http:// code.djangoproject.com/wiki/Version1.1Features ). Everybody, let's grow the green on http://code.djangoproject.com/milestone/1.1 ! Thanks and praises! --~--~-~--~~~---~--~~ 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: Work on #9964
On Sunday 08 March 2009, Malcolm Tredinnick wrote: > On Sat, 2009-03-07 at 21:24 +0200, Shai Berger wrote: > > Hi list, Malcolm, > > > > If I start working on a patch for #9664 (Transaction middleware closes > > the transaction only when it's marked as dirty; marked for milestone > > 1.1), will I be duplicating effort? > > > > Have you read Jeremy's latest comment on the ticket? In fact, before I sent my earlier mail to the list I hadn't. I spent some time over the weekend looking at svn and web-searched for this ticket, and managed to miss the ticket itself. But... > That indicates what > the next step is: some sensible timing runs to work out the effect of > removing the "dirty" flag. > ...I've added some preliminary results to the ticket now. > Either solution to this problem is fairly acceptable at the moment (sans > timing information): we either essentially get rid of the "dirty" > concept and always commit or always rollback (we know when to do each > one) and we point people who are heavily select-based and care about the > slight extra time and are willing to audit their code for manual > transaction safeness to use "autocommit" mode for PostgreSQL in 1.1 > (available after #3460 lands). However, that doesn't accomodate other > database backends. Alternatively, we document that if you're doing > manual SQL operations that change the transaction state, you have to > also set the dirty flag. > > At the moment I have a very slight lean towards the latter case because > it's least intrusive and most portable. To go the other route, we need > supporting evidence. Once that's in, there's really nothing to do on the > ticket: it's a three line change. > It's a three-line change, if we are willing to accept one of the choices you outlined above. I think we can make a change that is not much more complex, will make new projects start with a safer behavior (always close transactions), and will not hurt performance for existing users. Thanks for your time and attention, Shai. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
1.1: Ticket #3569 (Enhanced Atom Support)
Hey all, I have talked to James Tauber about ticket #3569 which is about adding better support for Atom to the syndication feeds framework. He has suggested that if we want to include something along these lines in 1.1 that we should put it in Django along-side the current Atom support. He has a glue layer that maps the old API to his new (and improved) API[0], but it hasn't been well tested. I know a lot of people (myself included) use his atom.py[1] file instead of Django's atom feed framework. If we wanted to get better atom support in 1.1, I'm curious what people think of shipping two versions of a syndication feed API in this release. Jacob has marked the ticket as 1.1beta, so I'm assuming this means that it will be going into 1.1. So the question now becomes, what do we about the old syndication feed API. I know in the past it has been mentioned that it should be replaced by something better. It seems that #3569 is indeed something better. Should we also include the translation layer (that lets you use the old API with the new atom code), or just let people switch to the new API when ready? I think that including the new code in a place like django.contrib.atom would also be an option, for in the future there might be more support added for Atompub. There are also some questions about what happens to RSS in this setup, since it is not currently implemented in this new code. Curious what people think about these changes. There is no patch attached to the ticket, so trimming the code, adding docs, and perhaps adding a bit more testing[2] would be in order to have it included. I know James' has said that he would be willing to write it as a patch to Django, and I would also be willing to help do some legwork to get it committed. [0] http://code.google.com/p/django-atompub/source/browse/trunk/atompub/atom.py#475 [1] http://code.google.com/p/django-atompub/source/browse/trunk/atompub/atom.py [2] http://code.google.com/p/django-atompub/source/browse/trunk/atompub/test_validation.py Cheers, Eric --~--~-~--~~~---~--~~ 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: sessions are not lazily created
Nope, I did not enable the auth middleware. Here are my 3 middleware components: 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.locale.LocaleMiddleware', On Mar 9, 3:07 am, Alex Gaynor wrote: > Are you using the auth middleware? If so it will be hitting the > session each query, even if your stuff doesn'tm > > Alex > > On 3/8/09, Dennis wrote: > > > > > > > > > Memcached-backed sessions seemed to be created, even when the session > > is not written to. > > > This is what I'm finding when I look at my memcache after hitting a > > page that does not use sessions. > > Thus, if an app uses sessions (but not much), memcache will fill up > > with empty sessions. > > (the same thing might happen with database-backed sessions, but I did > > not check that). > > > Just wondering if there is a reason why session creation is not lazy > > and only created when needed. > > -- > "I disapprove of what you say, but I will defend to the death your > right to say it." --Voltaire > "The people's good is the highest law."--Cicero- Hide quoted text - > > - Show quoted text - --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
