Re: Automatic prefetching in querysets

[Sean Brant]

I wonder if a solution similar to [1] from the rails world would satisfy
this request. Rather then doing anything 'magical' we instead log when we
detect things like accessing a related model that has not been pre-fetched.

[1] https://github.com/flyerhzm/bullet

On Tue, Aug 15, 2017 at 5:14 PM, Luke Plant  wrote:

> I agree with Marc here that the proposed optimizations are 'magical'. I
> think when it comes to optimizations like these you simply cannot know in
> advance whether doing extra queries is going to a be an optimization or a
> pessimization. If I can come up with a single example where it would
> significantly decrease performance (either memory usage or speed) compared
> to the default (and I'm sure I can), then I would be strongly opposed to it
> ever being default behaviour.
>
> Concerning implementing it as an additional  QuerySet method like
> `auto_prefetch()` - I'm not sure what I think, I feel like it could get
> icky (i.e. increase our technical debt), due to the way it couples things
> together. I can't imagine ever wanting to use it, though, I would always
> prefer the manual option.
>
> Luke
>
>
>
> On 15/08/17 21:02, Marc Tamlyn wrote:
>
> Hi Gordon,
>
> Thanks for the suggestion.
>
> I'm not a fan of adding a layer that tries to be this clever. How would
> possible prefetches be identified? What happens when an initial loop in a
> view requires one prefetch, but a subsequent loop in a template requires
> some other prefetch? What about nested loops resulting in nested
> prefetches? Code like this is almost guaranteed to break unexpectedly in
> multiple ways. Personally, I would argue that correctly setting up and
> maintaining appropriate prefetches and selects is a necessary part of
> working with an ORM.
>
> Do you know of any other ORMs which attempt similar magical optimisations?
> How do they go about identifying the cases where it is necessary?
>
> On 15 August 2017 at 10:44, Gordon Wrigley 
> wrote:
>
>> I'd like to discuss automatic prefetching in querysets. Specifically
>> automatically doing prefetch_related where needed without the user having
>> to request it.
>>
>> For context consider these three snippets using the Question & Choice
>> models from the tutorial
>>  
>> when
>> there are 100 questions each with 5 choices for a total of 500 choices.
>>
>> Default
>> for choice in Choice.objects.all():
>> print(choice.question.question_text, ':', choice.choice_text)
>> 501 db queries, fetches 500 choice rows and 500 question rows from the DB
>>
>> Prefetch_related
>> for choice in Choice.objects.prefetch_related('question'):
>> print(choice.question.question_text, ':', choice.choice_text)
>> 2 db queries, fetches 500 choice rows and 100 question rows from the DB
>>
>> Select_related
>> for choice in Choice.objects.select_related('question'):
>> print(choice.question.question_text, ':', choice.choice_text)
>> 1 db query, fetches 500 choice rows and 500 question rows from the DB
>>
>> I've included select_related for completeness, I'm not going to propose
>> changing anything about it's use. There are places where it is the best
>> choice and in those places it will still be up to the user to request it. I
>> will note that anywhere select_related is optimal prefetch_related is still
>> better than the default and leave it at that.
>>
>> The 'Default' example above is a classic example of the N+1 query
>> problem, a problem that is widespread in Django apps.
>> This pattern of queries is what new users produce because they don't know
>> enough about the database and / or ORM to do otherwise.
>> Experieced users will also often produce this because it's not always
>> obvious what fields will and won't be used and subsequently what should be
>> prefetched.
>> Additionally that list will change over time. A small change to a
>> template to display an extra field can result in a denial of service on
>> your DB due to a missing prefetch.
>> Identifying missing prefetches is fiddly, time consuming and error prone.
>> Tools like django-perf-rec 
>> (which I was involved in creating) and nplusone
>>  exist in part to flag missing
>> prefetches introduced by changed code.
>> Finally libraries like Django Rest Framework and the Admin will also
>> produce queries like this because it's very difficult for them to know what
>> needs prefetching without being explicitly told by an experienced user.
>>
>> As hinted at the top I'd like to propose changing Django so the default
>> code behaves like the prefetch_related code.
>> Longer term I think this should be the default behaviour but obviously it
>> needs to be proved first so for now I'd suggest a new queryset function
>> that enables this behaviour.
>>
>> I have a proof of concept of this mechanism that I've used 

Re: CITextField base class

[Sean Brant]

Does it make sense to add a CICharField for these cases or you can just
override the form/admin.

On Wed, Feb 8, 2017 at 10:29 AM, Jon Dufresne <jon.dufre...@gmail.com>
wrote:

> I believe this will also change the default form widget from  type="text"> to . Is that also desired? IME, I most often use
> citext with short text inputs, such as email.
>
> On Wed, Feb 8, 2017 at 7:11 AM, Tim Graham <timogra...@gmail.com> wrote:
>
>> Since that's a release blocker for a feature that hasn't been released
>> yet, it's fine to reference/reopen the original ticket rather than create a
>> new one. I've created a PR, https://github.com/django/django/pull/8034.
>>
>> On Wednesday, February 8, 2017 at 7:40:02 AM UTC-5, Adam Johnson wrote:
>>>
>>> Pretty sure this is a new ticket since it's effectively a bug report
>>>
>>> On 8 February 2017 at 11:00, Mads Jensen <m...@inducks.org> wrote:
>>>
>>>>
>>>>
>>>> On Wednesday, February 8, 2017 at 11:32:22 AM UTC+1, Adam Johnson wrote:
>>>>>
>>>>> Sounds legit, make a ticket
>>>>>
>>>>
>>>> Shouldn't https://code.djangoproject.com/ticket/26610 just be reopened?
>>>>
>>>>
>>>>> On 8 February 2017 at 00:37, Sean Brant <brant...@gmail.com> wrote:
>>>>>
>>>>>> I noticed the new postgres citext[1] field is a subclass of
>>>>>> CharField. Wouldn't it be more correct to subclass TextField?
>>>>>> Subclassing CharField means we need to add a max_length which is ignored 
>>>>>> in
>>>>>> the db.
>>>>>>
>>>>>> [1] https://github.com/django/django/blob/master/django/cont
>>>>>> rib/postgres/fields/citext.py
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "Django developers (Contributions to Django itself)" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to django-develop...@googlegroups.com.
>>>>>> To post to this group, send email to django-d...@googlegroups.com.
>>>>>> Visit this group at https://groups.google.com/group/django-developers
>>>>>> .
>>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/d/msgid/django-developers/0e50eae1
>>>>>> -8806-47fc-b223-9cac7152bf1e%40googlegroups.com
>>>>>> <https://groups.google.com/d/msgid/django-developers/0e50eae1-8806-47fc-b223-9cac7152bf1e%40googlegroups.com?utm_medium=email_source=footer>
>>>>>> .
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Adam
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Django developers (Contributions to Django itself)" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to django-develop...@googlegroups.com.
>>>> To post to this group, send email to django-d...@googlegroups.com.
>>>> Visit this group at https://groups.google.com/group/django-developers.
>>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>>> gid/django-developers/e2be5fd6-3fc0-44d5-8d07-da713eb58db4%4
>>>> 0googlegroups.com
>>>> <https://groups.google.com/d/msgid/django-developers/e2be5fd6-3fc0-44d5-8d07-da713eb58db4%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>>
>>> --
>>> Adam
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/django-developers/cac9ac5f-cdcd-

Re: CITextField base class

[Sean Brant]

Thanks Tim. I re-opened the ticket.

On Wed, Feb 8, 2017 at 9:11 AM, Tim Graham <timogra...@gmail.com> wrote:

> Since that's a release blocker for a feature that hasn't been released
> yet, it's fine to reference/reopen the original ticket rather than create a
> new one. I've created a PR, https://github.com/django/django/pull/8034.
>
> On Wednesday, February 8, 2017 at 7:40:02 AM UTC-5, Adam Johnson wrote:
>>
>> Pretty sure this is a new ticket since it's effectively a bug report
>>
>> On 8 February 2017 at 11:00, Mads Jensen <m...@inducks.org> wrote:
>>
>>>
>>>
>>> On Wednesday, February 8, 2017 at 11:32:22 AM UTC+1, Adam Johnson wrote:
>>>>
>>>> Sounds legit, make a ticket
>>>>
>>>
>>> Shouldn't https://code.djangoproject.com/ticket/26610 just be reopened?
>>>
>>>
>>>> On 8 February 2017 at 00:37, Sean Brant <brant...@gmail.com> wrote:
>>>>
>>>>> I noticed the new postgres citext[1] field is a subclass of CharField.
>>>>> Wouldn't it be more correct to subclass TextField? Subclassing CharField
>>>>> means we need to add a max_length which is ignored in the db.
>>>>>
>>>>> [1] https://github.com/django/django/blob/master/django/cont
>>>>> rib/postgres/fields/citext.py
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Django developers (Contributions to Django itself)" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to django-develop...@googlegroups.com.
>>>>> To post to this group, send email to django-d...@googlegroups.com.
>>>>> Visit this group at https://groups.google.com/group/django-developers.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/django-developers/0e50eae1
>>>>> -8806-47fc-b223-9cac7152bf1e%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/django-developers/0e50eae1-8806-47fc-b223-9cac7152bf1e%40googlegroups.com?utm_medium=email_source=footer>
>>>>> .
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Adam
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/django-developers/e2be5fd6-3fc0-44d5-8d07-da713eb58db4%
>>> 40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/e2be5fd6-3fc0-44d5-8d07-da713eb58db4%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Adam
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/cac9ac5f-cdcd-4e33-bba3-
> b1a9de700365%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/cac9ac5f-cdcd-4e33-bba3-b1a9de700365%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAPNuhQyW9MRynUkC6ZJGxUw5BGOXebdWZHjROcFaPQ%3DvFG4vug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

CITextField base class

[Sean Brant]

I noticed the new postgres citext[1] field is a subclass of CharField. 
Wouldn't it be more correct to subclass TextField? Subclassing CharField 
means we need to add a max_length which is ignored in the db.

[1] 
https://github.com/django/django/blob/master/django/contrib/postgres/fields/citext.py

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0e50eae1-8806-47fc-b223-9cac7152bf1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making Django more PaaS-friendly

[Sean Brant]

https://github.com/joke2k/django-environ has helpers for loading most of
the backends from urls. We use it with a docker based deployment at the
moment.

On Mon, Apr 11, 2016 at 8:46 AM, Ryan Hiebert  wrote:

> I'd love to see better support for PaaS configuration, especially
> 12-factor. We use Heroku, and I've been directly exposed to the challenges
> and had to come up with some of my own solutions. Here's some thoughts I
> have on the matter, in no particular order.
>
>
> The SECRET_KEY needs to _not_ be required for the `collectstatic` command.
> I haven't tracked down why it currently _is_ required, but it means that I
> have added this line to my project, solely so that my project can be built
> on Heroku.
>
> SECRET_KEY = os.environ.get('SECRET_KEY', 'not-so-secret')
>
> SECRET_KEY is effectively optional (though I'm careful to make sure it's
> set), and I don't see a good reason that should be. Note that environment
> variables aren't normally available during slug build, since changing
> environment variables doesn't re-build the project.
>
>
> I believe that the biggest current impediment to finding a great solution
> to loading Django settings is that the settings are based on a Module.
> Django-Configurations has done an excellent job of making that into a
> class-based API instead, which allows for mixins and inheritance. Having
> built-in support for this would be an excellent way to allow 3rd party
> solutions to build up settings programatically. In the case we are
> discussing, from the environment.
>
> I believe this would make it far easier for projects like Kristian's
> django-12factor and dj-email-url to work well. dj-email-url is a good idea
> (put all the settings in 1 variable, like dj-database-url), except that all
> the settings are split up at the top-level of the module, making what's
> conceptually one multi-facted setting a multi-line pain.
>
> One possibility would be extending `DJANGO_SETTINGS_MODULE` with an
> optional class, separated with a colon, so to get a django-configurations
> style class you'd use
> `DJANGO_SETTINGS_MODULE=myproject.settings:MySettings`. Or we could change
> the variable name `DJANGO_SETTINGS`, which would allow us to avoid the
> colon: `DJANGO_SETTINGS=myproject.settings.MySettings`. Or paint the
> bikeshed some other color.
>
>
> I'd love to see some of the support for environment configurations brought
> into Django, but IMO moving away from a module based settings API is a more
> pressing concern that would enable 3rd party libraries to come up with
> elegant solutions.
>
>
> On Apr 11, 2016, at 4:32 AM, Kristian Glass <
> googleto...@doismellburning.co.uk> wrote:
>
> I wrote django12factor to do something similar. One of the things I like
> least about it is the process of actually using it from your settings.py -
> there's things in there I'd love to see in the generated default.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/2D66F14E-DD71-41B6-A84D-A0C679FD72F5%40ryanhiebert.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAPNuhQxbRKX%3D2FrCd-jg6MJCnO%2BuBC6HbTOpPUdQJAjQjyMDSw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feedback on Django Channels

[Sean Brant]

How does the new channels model handle requests with sensitive information?
Say you have a login view and the user is submitting a username/password.
Does the password get serialized into the message queue as plain text? If
so is that a security concern users should be aware of?

Sean

On Mon, Mar 21, 2016 at 7:55 AM, David Evans  wrote:

> On the static files question, I'm about to release v3 of WhiteNoise (
> http://whitenoise.evans.io/en/latest/changelog.html) which provides the
> option to integrate via Django middlware, rather than wsgi middleware. (It
> uses the FileResponse class, which didn't exist when I first wrote
> WhiteNoise.) I'm hoping (though I haven't tested it yet) that this will
> work out of the box with Channels, as it's only using standard Django APIs.
>
> Dave
>
>
> On Thursday, 17 March 2016 16:42:05 UTC, Jacob Kaplan-Moss wrote:
>>
>> Hi folks (and especially Andrew):
>>
>> I've just completed writing an example Channels app [1] for an article
>> about Channels [2]. Overall it was a super-pleasant experience: Channels
>> seems pretty solid, the APIs make sense to me, and I couldn't be more
>> excited about the new things this'll let me do!
>>
>> In the interests of making this thing as solid as possible before we
>> merge it into Django, I do have some feedback on some of the hiccups I
>> encountered. Roughly in order of severity (as I perceive it), they are:
>>
>> 1. Debugging errors:
>>
>> I found debugging errors that happen in a consumer to be *really*
>> difficult -- errors mostly presented as things just silently not working.
>> It took a ton of messing around with logging setups before I could get
>> anything of use dumped to the console. This isn't strictly a Channels issue
>> (I've noted similar problems with AJAX views and errors in Celery tasks),
>> but I think Channels sorta brings the issue to a head.
>>
>> I think we need some better defaults, and simple, clear documentation, to
>> make sure that exceptions go somewhere useful.
>>
>> 2. Static files:
>>
>> I had trouble getting static files served. I'm used to using Whitenoise (
>> http://whitenoise.evans.io/en/stable/) for small-to-medium-ish sites
>> that don't need a proper static server, but of course it doesn't work with
>> Channels since Channels doesn't use WSGI! I found the (undocumented)
>> StaticFilesConsumer (
>> https://github.com/jacobian/channels-example/blob/master/chat/routing.py#L5-L8),
>> but that feels less than ideal.
>>
>> I think this might be an opportunity, however. If Daphne learns how to
>> serve static files (perhaps via optional integration with Whitenoise?),
>> this would actually make static media in Django a bit easier by default.
>>
>> [I would be happy to work on this if I get a thumbsup.]
>>
>> 3. WebSocket routing:
>>
>> Channels routes all WebSocket connections to a single set of consumers
>> (the `websocket.*` consumers). This means that if you want multiple
>> WebSocket URLs in a single app you need to manually parse the path. And, to
>> make things more complicated, you only get the WebSocket path passed in the
>> connection message, so you have to also use a channel session to keep track.
>>
>> This feels like a distinct step back from the URL routing we already have
>> in Django, and it was surprising to me to have to do this by hand. It
>> definitely felt like Channels is missing some sort of WebSocket URL router.
>>
>> I had a brief chat with Andrew, who indicates that he'd planned for this
>> to be a post-1.0 feature. I'm not sure I agree - it feels pretty
>> fundamental - but I'd like to hear other thoughts.
>>
>> [This is another thing I'd be interested in working on, assuming a
>> thumbs.]
>>
>> ---
>>
>> Has anyone else here played with Channels? Are there other things I'm
>> missing that might need to be included before we merge this?
>>
>> Jacob
>>
>> [1] https://github.com/jacobian/channels-example
>>
>> [2]
>> https://blog.heroku.com/archives/2016/3/17/in_deep_with_django_channels_the_future_of_real_time_apps_in_django
>> ?
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/ba29cc7a-90fc-4cf2-a65d-da782e83b3ca%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To 

Re: PostGres 9.5 Upsert

[Sean Brant]

> On Jan 10, 2016, at 2:09 AM, Anssi Kääriäinen  wrote:
> 
> If I recall correctly, MySQL doesn't offer a way to specify on which index 
> you want to do the conflict resolution. This leads to problems - the upsert 
> might affect the wrong row if there are multiple unique indexes on the table.
> 
> PostgreSQL's version of upsert has a problem, too. It doesn't offer a direct 
> way to know if the result of the upsert was an insert or update, but Django 
> needs that knowledge, at least for save(). Maybe there is a way (the oid 
> return value seems promising).
> 
> For get_or_create and update_or_create the problem is that the user is free 
> to offer any condition to be used for matching, but PostgreSQL limits the 
> upsert matching to columns in unique index. So, we can use upsert only for 
> unique index cases.

I've always considered this a bug waiting to happen. I have seen many errors 
with the get operation failing because it returned more then one value. Usually 
you don't notice the error until you hit production. I always suggest the 
lookup use fields that have unique indexes.

Changing that would be backwards incompatible so maybe it's a docs issue.

> 
> The save() operation matches the semantics of upsert exactly - maybe we could 
> use upsert there?
> 
>  - Anssi
> 
>> On Sunday, January 10, 2016, Cristiano Coelho  
>> wrote:
>> I agree! Also, does this already happen for the MySQL backend? MySQL has the 
>> insert on conflict update, that could work the same way.
>> However, if I'm not wrong, the docs states that the above methods have a 
>> race condition (obvious since right now it does two operations), but if the 
>> code would actually use native database operations, the race conditions 
>> might be gone for those cases, so that should probably be documented as well.
>> 
>> El viernes, 8 de enero de 2016, 21:13:26 (UTC-3), bliy...@rentlytics.com 
>> escribió:
>>> 
>>> Hey Guys,
>>> 
>>> Postgres 9.5 has added the functionality for UPSERT aka update or insert.  
>>> Any interest in aligning UPSERT on the db layer with the get_or_create or 
>>> update_or_create functionality in django?  Sounds like my company would be 
>>> interested in doing the work if the PR will get the traction.
>>> 
>>> -Ben
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/ae38ba8e-3e79-47fb-92b9-dd305176c58e%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CALMtK1Gub-uL3AdgFSxQkdUNNe_Q47%3D7O%3DZ4qsW3Exwjhkd4ZA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/A53126E5-B9D8-4A5A-A56E-B58B77500E94%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Provide a way to pass kwargs when initializing the storage class

[Sean Brant]

+1 to these ideas. This will make injecting dependancies much cleaner. I’ve 
pointed my BACKEND settings to factory functions in the past.


def storage_factory():
return SomeStorage(some_de)


DEFAULT_STORAGE_BACKEND = ‘path.to.storage_factory'


> On Nov 7, 2015, at 7:10 AM, Shai Berger  wrote:
> 
> On Saturday 07 November 2015 14:55:20 Aymeric Augustin wrote:
>> 
>> Essentially your proposal means reformatting the current file-related
>> settings to this structure:
>> 
>> FILE_STORAGES = {
>>‘media’: {
>>‘BACKEND’: settings.DEFAULT_FILE_STORAGE,
>>‘OPTIONS’: {
>> ‘location’: settings.MEDIA_ROOT,
>> ‘base_url’: settings.MEDIA_URL,
>> # possible override of settings.FILE_CHARSET
>>},
>>},
>>‘static’: {
>>‘BACKEND’: settings.STATICFILES_STORAGE,
>>‘OPTIONS’: {
>> ‘location’: settings.STATIC_ROOT,
>> ‘base_url’: settings.STATIC_URL,
>> # replacement for STATICFILES_FINDERS and STATICFILES_DIRS
>> that would look a lot like template loaders # possible override of
>> settings.FILE_CHARSET
>>},
>> 
>>}
>> }
>> 
>> 
>> How do people feel about this alternative proposal?
>> 
> 
> This, in general, seems like the right thing to do. The only reservation I 
> have is that the 'OPTIONS' key seems superfluous -- why not put the options 
> in 
> the same dictionary as the backend?
> 
> On a related point -- I wouldn't put base_url in there. It is related to 
> files, 
> but not to their storage.
> 
> My 2KB,
>   Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/06F33052-6FEB-48E0-821F-95E34893B30A%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: upgrading the choices machinery for Django

[Sean Brant]

I agree we don't really gain anything from including this in core.
Django model utils[1] has a pretty solid implementation of a choice
abstraction.

[1] https://github.com/carljm/django-model-utils

On Wed, Apr 4, 2012 at 11:41 AM, Adrian Holovaty  wrote:
> 2012/4/3 Łukasz Langa :
>> Explicit choice values::
>>
>>  GENDER_MALE = 0
>>  GENDER_FEMALE = 1
>>  GENDER_NOT_SPECIFIED = 2
>>
>>  GENDER_CHOICES = (
>>      (GENDER_MALE, _('male')),
>>      (GENDER_FEMALE, _('female')),
>>      (GENDER_NOT_SPECIFIED, _('not specified')),
>>  )
>>
>>  class User(models.Model):
>>      gender = models.IntegerField(choices=GENDER_CHOICES,
>>              default=GENDER_NOT_SPECIFIED)
>>
>>      def greet(self):
>>          if self.gender == GENDER_MALE:
>>              return 'Hi, boy.'
>>          elif self.gender == GENDER_NOT_SPECIFIED:
>>              return 'Hello, girl.'
>>          else: return 'Hey there, user!'
>>
>> This is a saner way but starts getting overly verbose and redundant. You can
>> improve encapsulation by moving the choices into the ``User`` class but that 
>> on
>> the other hand beats reusability.
>
> I don't see the immediate need for Yet Another Sub-framework, as
> described in this proposal. This is what I normally do, and it works
> fine:
>
> class User(models.Model):
>    MALE = 0
>    FEMALE = 1
>    GENDERS = [(MALE, 'Male'), (FEMALE, 'Female')]
>    gender = models.IntegerField(choices=GENDERS)
>
>    def greet(self):
>        return {MALE: 'Hi, boy', FEMALE: 'Hi, girl.'}[self.gender]
>
> If people aren't understanding that, we should improve our documentation.
>
> Also, the fact that we *don't* have a sub-framework for this lets
> people do whatever they want -- including using the dj.choices module.
> So I am -1 on including this in Django proper.
>
> Adrian
>
> --
> 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.
>

-- 
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: start using less (and bootstrap!)

[Sean Brant]

On Thu, Feb 2, 2012 at 4:17 PM, Alex Gaynor <alex.gay...@gmail.com> wrote:
>
>
> On Thu, Feb 2, 2012 at 5:01 PM, Adrian Holovaty <adr...@holovaty.com> wrote:
>>
>> On Thu, Feb 2, 2012 at 2:49 PM, Sean Brant <brant.s...@gmail.com> wrote:
>> > Is this up somewhere public? I've been fighting the urge to do this as
>> > well. Using django-compressor with less on Heroku is a non-starter
>> > since you can't install node. Having this as a Python module would be
>> > handy.
>>
>> Not yet, alas, but hopefully soon.
>>
>> Adrian
>>
>> --
>> 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.
>>
>
> Perhaps this is too far in the future looking.  But at a certain point the
> admin must become a separate project.  One of the major goals of
> newforms-admin ('lo those years ago) was to demote the admin from special
> status, with hooks inside core left and right, to "just an app".  Let's
> carry that to the logical conclusion: just an app *outside of Django*.
>
> That gives the maintainers the freedom to reinvent it, and use tools like
> less or bootstrap without it needing to be an issue of policy for all of
> Django.  Because when I first read saw this thread my thought was, "Hmm,
> what unholy mess of requirements am I going to need if I want to just run
> the test suite.  Will I still be able to write new features in forms without
> needing to learn what the hell less or compass is?".  Several years ago, I
> opposed using jQuery in the admin, on the principle that Django should be
> completely free of entangling alliances.  I made that argument more or less
> out of habit, just because I felt it was an argument that ought to be made,
> but really I was pretty happy to get to use jQuery.  Now I'm saying, it's
> pretty clear that admin 2.0 (or 3.0, or 4.0, anyone counting?) is going to
> be a beast that far outstrips almost anything else in Djanog (besides the
> ORM ;)) in complexity, with more dependencies, more associated tooling, and
> more usecases (i.e. it's not just a tool for developers to use, it's also
> something for end users of *our* users' apps to use).  Keeping that in
> Django itself is going to stunt it's growth, and it's going to suck for new
> developers to Django who, like many of us (or at least myself), were and
> still are, Python developers at heart, who can write some HTML, badly.
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing 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.

+1

Given how flexible the admin is doing somethings is still pretty
annoying. I feel like if it was a external project with its own
release schedule more progress could be made. FWIW i'm experimenting
with an admin interface that relies heavily on class based views. So
far I like it. CBVs seem to have more useful hooks then the admin
currently has. At the very least I think the new admin needs to not be
backwards compatible with the current admin.

So my vote is for django-admin2 as an external project.

-- 
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: start using less (and bootstrap!)

[Sean Brant]

On Thu, Feb 2, 2012 at 2:36 PM, Adrian Holovaty  wrote:
> On Thu, Feb 2, 2012 at 2:07 PM, Idan Gazit  wrote:
>> * less.js has the distinct advantage of being easier to develop for than
>> sass for our purposes.If we go with a less.js solution (like bootstrap), we
>> might not need to require that all edits to admin "source" stylesheets
>> (less/scss) come with the recompiled CSS. This lowers the barrier to
>> contribution significantly, at the cost of a bit of site performance as less
>> gets compiled client-side. That being said, the admin isn't supposed to be
>> used as a a high-traffic site (or shouldn't be, I can't say how people abuse
>> it).
>
> Two points:
>
> * If we decide to change the admin site to use LESS, we should ship
> compiled CSS. No need to introduce the less.js overhead.
>
> * I have been working on a Python LESS compiler in my spare time, and
> there could be a use for it in here.


Is this up somewhere public? I've been fighting the urge to do this as
well. Using django-compressor with less on Heroku is a non-starter
since you can't install node. Having this as a Python module would be
handy.


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

-- 
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: jQuery.tmpl() and Django

[Sean Brant]

2011/5/27 Gábor Farkas :
> On Fri, May 27, 2011 at 7:04 AM, Sean O'Connor  wrote:
>> A better approach would for Django to provide some tools and documentation
>> to help people work around the conflict.  One easy solution would be to
>> provide a verbatim tag like what ericflo wrote
>> at https://gist.github.com/629508.  Another would be to provide
>> documentation on tools that make it easy to load jquery style templates via
>> ajax like icanhaz.js.
>
> (technically, there is an open jquery-templating ticket about making
> the template-tag format customizable:
> https://github.com/jquery/jquery-tmpl/issues/74)
>
> i had the same problem in the past (btw. mustache.js also uses the
> two-curly-braces notation :-),
> and unfortunately the verbatim tag did not solve the problem, because
> sometimes you need
> to use the django-templating INSIDE the jquery template
> .
> for example:
> """
> .
> .
> 
> Are you sure to delete {{ name_of_thing }}?
> {% trans "YES"%}
> {% trans "NO"%}
> 
> """
>
> here i want the {{ name_of_thing }} to be handled by
> jquery-templating, but the translation
> should happen using the django-tags.
>
> so either i have to use the {% verbatim %} tag only around the places
> where i have javascript-variables
> (and not around the whole jquery-template), or i have to do the
> translation in python,
> and send them in as variables in javascript. both seem to be impractical.
>
> the approach i chose was to use a different variable-syntax
> (instead of "{{ thing }}", i use "[[ thing ]]"), and before using the 
> template,
> i simply replace those with the correct values. it's not nice, but
> still the most practical solution i could find.
>
> gabor

I wonder if verbatim as a filter makes more sense, for example::


Are you sure to delete {{ "{{ name_of_thing }}"|verbatim }}?
{% trans "YES"%}
{% trans "NO"%}


The filter would then just return {{ name_of_thing }} back to the
template. If you wanted to use a template variable as the name of the
jQuery variable this approach would still fail.

Now that I think about it maybe the replace tokens approach is the
most flexible.

{% verbatim "[[" "]]" %}

Are you sure to delete [[ name_of_thing ]]?
{% trans "YES"%}
{% trans "NO"%}

{% endverbatim %}

You you could then choose the tokens that get replaced.

- Sean

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

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

Caching model choice fields in admin inlines.

[Sean Brant]

If you have ever used a inline in the admin for a model that contained
a model choice field you have probably noticed it has to query the
database for each row to fill the select drop-down. This results in n+
identical queries.

I though it might be useful to have a way to tell a admin inline to
cache the choices of fields. Here is some rough code that gets the job
done::


from django.forms.models import BaseInlineFormSet


class CachedInlineFormSet(BaseInlineFormSet):
cached_fields = []

def _construct_form(self, i, **kwargs):
form = super(CachedInlineFormSet, self)._construct_form(i,
**kwargs)
for cache_field in self.cached_fields:
field = form.fields[cache_field]
field.cache_choices = True
choices = getattr(self, '_cached_%s_choices' %
cache_field, None)
if choices is None:
choices = list(field.choices)
setattr(self, '_cached_%s_choices' % cache_field,
choices)
field.choice_cache = choices
return form


class CachedTabularInline(admin.TabularInline):
cached_fields = []

def get_formset(self, request, obj=None, **kwargs):
formset = super(CachedTabularInline,
self).get_formset(request, obj=None, **kwargs)
formset.cached_fields = self.cached_fields
return formset


class MyInline(CachedTabularInline):
model = MyModel
cache_fields = ['myfk']


Im not super big on how this patches the classes in various places so
i'm open to better suggestions. Is this something that the admin could
benefit from or is this better kept as a 3rd party tool?

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

r15580 breaks change list result template overwrites

[Sean Brant]

Looks like r15580 modified the way change list rows are returned. The
template used to just iterate over {{ result }} but now requires
iteration over {{ result.row }}.  This will breaking anyones templates
that happen to overwrite admin/change_list_results.html. Does
overwriting admin templates fall into public api territory?

-- 
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: Changing settings per test

[Sean Brant]

On Nov 4, 4:26 pm, Alex Gaynor  wrote:
> 2010/11/4 Łukasz Rekucki :
>
>
>
>
>
> > Funny, I had exactly the same problem today at work while refactoring
> > my application's tests suite :).
>
> > Currently, I'm using a pair of save/restore functions: save() monkey
> > patches the settings module and returns a dictionary of old values,
> > restore() puts back the old values based on the dictionary. I usually
> > put this in setUp/tearDown so I don't have to repeat in every test. I
> > was about to propose that
> > Django's TestCase should do something similar by default.
>
> > Both the decorator and context processor are very useful, but having
> > something to set values for the whole test case instead of a single
> > test or a block of code would be great too. I was thinking about
> > something in line of:
>
> >    class EmailTestCase(TestCase):
> >        settings = dict(DEFAULT_FROM_EMAIL="webmas...@example.com")
>
> > On 4 November 2010 21:11, David Cramer  wrote:
> >> With a decorator approach here's what I whipped up:
>
> >> (This is dry code)
>
> >> def with_settings(**overrides):
> >>    """Allows you to define settings that are required for this
> >> function to work"""
> >>    NotDefined = object()
> >>    def wrapped(func):
> >>       �...@wraps(func)
> >>        def _with_settings(*args, **kwargs):
> >>            _orig = {}
> >>            for k, v in overrides.iteritems():
> >>                _orig[k] = getattr(settings, k, NotDefined)
>
> >>            try:
> >>                func(*args, **kwargs)
> >>            finally:
> >>                for k, v in _orig.iteritems():
> >>                    if v is NotDefined:
> >>                        delattr(settings, k)
> >>                    else:
> >>                        setattr(settings, k, v)
> >>        return _with_settings
> >>    return wrapped
>
> >> I'm not familiar with the context managers, but I imagine those would
> >> solve things like adjusting CONTEXT_PROCESSORS.
>
> >> On Thu, Nov 4, 2010 at 1:06 PM, Dan Fairs  wrote:
>
>  Let me start with an example test:
>
>  def test_with_awesome_setting(self):
>     _orig = getattr(settings, 'AWESOME', None)
>     settings.AWESOME = True
>
>     # do my test
>     ...
>
>     settings.AWESOME = _orig
>
> >>> Pedant: there's a small bug above which has bitten me before doing a 
> >>> similar thing - settings.AWESOME  ends up set to None after the test has 
> >>> run if it didn't exist before.
>
>  Anyways, I'd love to hear how others have dealt with this and any
>  other possible solutions.
>
> >>> I've used Michael Foord's Mock library to patch a setting for the 
> >>> duration of a test case. Chris Withers' testfixtures library also has 
> >>> some sugar to provide a context manager approach, though I haven't used 
> >>> that in a little while.
>
> >>> Cheers,
> >>> Dan
>
> >>> --
> >>> Dan Fairs | dan.fa...@gmail.com |www.fezconsulting.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-develop...@googlegroups.com.
> >>> To unsubscribe from this group, send email to 
> >>> django-developers+unsubscr...@googlegroups.com.
> >>> For more options, visit this group 
> >>> athttp://groups.google.com/group/django-developers?hl=en.
>
> >> --
> >> You received this message because you are subscribed to the Google Groups 
> >> "Django developers" group.
> >> To post to this group, send email to django-develop...@googlegroups.com.
> >> To unsubscribe from this group, send email to 
> >> django-developers+unsubscr...@googlegroups.com.
> >> For more options, visit this group 
> >> athttp://groups.google.com/group/django-developers?hl=en.
>
> > --
> > Łukasz Rekucki
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Django developers" group.
> > To post to this group, send email to django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-developers?hl=en.
>
> Well, there's no reason the decorator couldn't be used as a class
> decorator (on 2.6 and above).  I'll admit that the settings attribute
> on TestCase is more consistant with how we've handled other things
> (urls, fixtures), however, for whatever reason I'm not a fan, as it
> forces you to split up tests that should logically be grouped on a
> single class.
>
> Alex
>
> --
> "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
> "Code can always be simpler than you think, but never as simple as you
> want" -- Me

What if it worked like self.client. So self.settings would be the
current settings with 

Re: Bump/question for #13956

[Sean Brant]

Has supporting kwargs along with args been mentioned? I would find
having both very helpful. Maybe we can lean on the work happening for
the include and with tags.


On Wed, Nov 3, 2010 at 10:06 AM, Stephen Burrows
 wrote:
> As far as I know, the only thing still missing from the ticket is a
> decision as to whether there need to be documentation changes for
> simple tags and inclusion tags... if there need to be changes, I could
> try working on them. I would just need to know.
> Best,
> Stephen
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

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

Re: variable view name in url tag

[Sean Brant]

On Oct 3, 8:08 pm, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Mon, Oct 4, 2010 at 8:56 AM, Sean Brant <brant.s...@gmail.com> wrote:
>
> > On Oct 3, 2010, at 7:37 PM, Russell Keith-Magee wrote:
>
> >> On Mon, Oct 4, 2010 at 4:53 AM, Sean Brant <brant.s...@gmail.com> wrote:
> >>> I know this has come up over the last few years[1] and people are
> >>> mixed on the action that should be taken. I would like to bring it up
> >>> again as it has bitten me a few time lately.
>
> >>> I seems the biggest concern is backwards compatibility of the syntax.
> >>> I feel that should not stop us from fixing something that is an
> >>> annoying wart and also keeping the syntax in line with how other tags
> >>> work.
>
> >>> In this thread[2] Malcolm suggested introducing a new tag and
> >>> depreciating the old one which could be done by bringing something
> >>> like[3] into core. Im not huge on the idea of have 2 tags that do the
> >>> same thing only with slightly different syntax, but if that is the
> >>> cleanest upgrade I'm +1.
>
> >>> I think this can still be done in a backwards compatible way[4],
> >>> unless I'm missing something.
>
> >> This isn't backwards compatible in every case. Consider:
>
> >> {% url foo %}
>
> >> foo could be:
> >> - A URL pattern name
> >> - A variable in the context
> >> - A variable in the context *and* a URL pattern name
>
> >> It's the third case where your proposal has problems. Under the
> >> current implementation, it's *always* interpreted as a URL pattern
> >> name. Under your proposal, the context variable would take precedence
> >> in the third case.
>
> >> It's also backwards incompatible in the second case (though not in a
> >> way that matters as much): if you have an existing template that
> >> raises an error, but you have a context variable that matches the name
> >> you've used, your implementation *won't* raise an error.
>
> >> However, there is another way (an alternative to adding a parallel tag) :-)
>
> >> An interesting quirk/feature of Django's template language: if you
> >> register template tags with the same name, the last registered name
> >> wins.
>
> >> This means we can define a "future_url" template tag library that
> >> registers a {% url %} template tag. Then, in your code, you can say:
>
> >> {% load future_url %}
> >> {% url "url-name" foo=bar %}
>
> >> and get the new behavior. Then, we can put PendingDeprecationWarnings
> >> in the old {% url %} tag definition, upgraded to DeprecationWarnings
> >> in 1.4. Then, in 1.5, we switch the behavior over and start
> >> deprecating the future_url tag library.
>
> >> I'm completely in favor of making this change; the behavior of the url
> >> tag has always been an annoying wart, and it would be good to clean it
> >> up.
>
> >> Yours,
> >> Russ Magee %-)
>
> > Thanks for the feedback Russ. I know it couldn't be that straight forward. 
> > I'll work on a patch this week that
> > implements what you mentioned. Would it be best to start a new ticket or 
> > re-open the old ticket?
>
> Open a new ticket. #7917 proposes fixing the existing tag; this is a
> complete new approach to the problem. However, make sure you reference
> the old ticket and discussions so we have a point of reference. Feel
> free to accept the new ticket for the 1.3 milestone.

Okay I created a new ticket with patch for this.
http://code.djangoproject.com/ticket/14389

> Yours,
> Russ Magee %-)

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

Re: variable view name in url tag

[Sean Brant]

On Oct 3, 2010, at 7:37 PM, Russell Keith-Magee wrote:

> On Mon, Oct 4, 2010 at 4:53 AM, Sean Brant <brant.s...@gmail.com> wrote:
>> I know this has come up over the last few years[1] and people are
>> mixed on the action that should be taken. I would like to bring it up
>> again as it has bitten me a few time lately.
>> 
>> I seems the biggest concern is backwards compatibility of the syntax.
>> I feel that should not stop us from fixing something that is an
>> annoying wart and also keeping the syntax in line with how other tags
>> work.
>> 
>> In this thread[2] Malcolm suggested introducing a new tag and
>> depreciating the old one which could be done by bringing something
>> like[3] into core. Im not huge on the idea of have 2 tags that do the
>> same thing only with slightly different syntax, but if that is the
>> cleanest upgrade I'm +1.
>> 
>> I think this can still be done in a backwards compatible way[4],
>> unless I'm missing something.
> 
> This isn't backwards compatible in every case. Consider:
> 
> {% url foo %}
> 
> foo could be:
> - A URL pattern name
> - A variable in the context
> - A variable in the context *and* a URL pattern name
> 
> It's the third case where your proposal has problems. Under the
> current implementation, it's *always* interpreted as a URL pattern
> name. Under your proposal, the context variable would take precedence
> in the third case.
> 
> It's also backwards incompatible in the second case (though not in a
> way that matters as much): if you have an existing template that
> raises an error, but you have a context variable that matches the name
> you've used, your implementation *won't* raise an error.
> 
> However, there is another way (an alternative to adding a parallel tag) :-)
> 
> An interesting quirk/feature of Django's template language: if you
> register template tags with the same name, the last registered name
> wins.
> 
> This means we can define a "future_url" template tag library that
> registers a {% url %} template tag. Then, in your code, you can say:
> 
> {% load future_url %}
> {% url "url-name" foo=bar %}
> 
> and get the new behavior. Then, we can put PendingDeprecationWarnings
> in the old {% url %} tag definition, upgraded to DeprecationWarnings
> in 1.4. Then, in 1.5, we switch the behavior over and start
> deprecating the future_url tag library.
> 
> I'm completely in favor of making this change; the behavior of the url
> tag has always been an annoying wart, and it would be good to clean it
> up.
> 
> Yours,
> Russ Magee %-)

Thanks for the feedback Russ. I know it couldn't be that straight forward. I'll 
work on a patch this week that
implements what you mentioned. Would it be best to start a new ticket or 
re-open the old ticket?

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

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

variable view name in url tag

[Sean Brant]

I know this has come up over the last few years[1] and people are
mixed on the action that should be taken. I would like to bring it up
again as it has bitten me a few time lately.

I seems the biggest concern is backwards compatibility of the syntax.
I feel that should not stop us from fixing something that is an
annoying wart and also keeping the syntax in line with how other tags
work.

In this thread[2] Malcolm suggested introducing a new tag and
depreciating the old one which could be done by bringing something
like[3] into core. Im not huge on the idea of have 2 tags that do the
same thing only with slightly different syntax, but if that is the
cleanest upgrade I'm +1.

I think this can still be done in a backwards compatible way[4],
unless I'm missing something.

I hope this doesn't turn into a shed planing session, thanks!

[1] http://code.djangoproject.com/ticket/7917
[2]
http://groups.google.com/group/django-developers/browse_thread/thread/ac2b1ea4555c0a62/21cf9b1aed6d11e0?lnk=gst=url+tag+viewname#21cf9b1aed6d11e0
[3] http://github.com/ulope/django-reversetag
[4] http://pastebin.com/FhZSFQdn

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

logialogin_required does not check User.is_active

[Sean Brant]

A co-worker of mine noticed this bug today 
http://code.djangoproject.com/ticket/13125.
Should it be marked for 1.2 or punt it until after the release
candidate? It looks to be a bug so it could probably go in at anytime.
Let me know your thoughts.

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

Re: Possible bug in messages framework?

[Sean Brant]

On Jan 22, 2010, at 7:04 PM, Luke Plant wrote:

> Well, it depends on what you call the 'spec'.  What spec says that 
> commas in values is invalid?
> 
> The 'spec' linked to on that WebKit bug is a preliminary Netscape 
> document, which, as far as I can tell, eventually turned into RFC 
> 2109, which surely has got to be regarded as more authoritative.  RFC 
> 2965 (which proposes Set-Cookie2) supposedly obsoletes RFC 2109, but I 
> don't know think it is really used much. [1]
> 
> As I noted on the bug [2], RFC 2109 allows values to be quoted, in 
> which case Django is behaving correctly, and it is some browsers that 
> are not.
> 
> Our implementation of this is in fact done entirely by Python's 
> standard library Cookie module [3]. It handles everything I can throw 
> at it (newlines, UTF8, throws exceptions with illegal cookie names 
> etc.).  It's kind of unlikely that we've found a bug in it.
> 
> Of course, it doesn't mean we shouldn't fix things to avoid this bug.  
> But to do so would require some kind of encoding, which is almost 
> certainly going to cause breakage of some kind with existing cookies.  
> Turbogears' solution would be backwards compatible in most cases, but 
> not all.
> 
> (BTW, if we implemented this change, the nicer way to do is to 
> subclass Cookie and override Cookie.value_encode() and value_decode(), 
> rather than the way that Turbogears does it)
> 
> Personally, I favour fixing our messages implementation so that it 
> isn't an issue (which is easy, it seems, see details on #12470), and 
> possibly just putting a note into our cookie documentation that some 
> old WebKit based browsers have a bug that means they do not correctly 
> handle a cookie value containing a comma followed by a space.
> 
> An argument in favour of this lazy approach is that this issue, for 
> both ourselves and Turbogears, has only ever come up in the context of 
> using cookies for messages.  Presumably that means that developers are 
> rarely storing extended human readable text strings in cookies outside 
> of this kind of usage, so outside of the messages app it is probably 
> not something we need to worry about.
> 
> Luke


Whats the downside of fixing this at the core cookie handling level? I agree 
with Luke and only ran across this bug when the new messaging framework 
dropped. However if we are going to fix the problem, and I do think it's a 
problem even if its a browser bug, should we just fix it at the core level and 
handle all cookies down the road? Would previously stored cookies that are not 
url quoted even fail when trying to unquote? Maybe I'm wrong but this seems 
pretty backwards compatible.

Sean

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

Re: Possible bug in messages framework?

[Sean Brant]

I wonder if this is related?
http://groups.google.com/group/django-developers/browse_thread/thread/5613e9a03d92c902/738a3b81e405dc78#738a3b81e405dc78

On Jan 21, 2010, at 10:55 PM, j...@jeffcroft.com wrote:

> After a little more playing around, I've discovered that this is not
> an issue if I use the session storage -- so it seems to be related to
> cookie storage.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
> 

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

django.contrib.messages failing silently in safari when comma is used in message

[Sean Brant]

If you try and send a message with new messaging app that contains a
comma in the message it does not work in Safari.

I'm not really sure why the json encoded message is not working in the
Safari browser, but I fixed it by adding a base64 encode and decode
step that encodes/decodes the message string.

def _encode(self, messages, encode_empty=False):
...
if messages or encode_empty:
for message in messages:
message.message = base64.b64encode(message.message)
encoder = MessageEncoder(separators=(',', ':'))
...

def _decode(self, data):
...
messages = json.loads(value, cls=MessageDecoder)
for message in messages:
message.message = base64.b64decode
(message.message)
return messages
except ValueError:
pass
 ...

--

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

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

[Sean Brant]

The last thing that needs to happen is bulling this into core. It's no
good for the community and that could be part of the perceived
perceptions problem. Just because enough people bitch does not mean
that its a good thing. With that said the reason behind the ticket
being closed no longer seems valid.

A template filter for shortening a string seems like a logical
addition to truncatewords. At the very least reassessing the ticket
status might be a good start.

--

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

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

[Sean Brant]

On Dec 30, 2009, at 6:06 AM, Russell Keith-Magee wrote:
> Firstly, as James points out, slice already exists, and the ellipsis
> difference between slice and truncate can be easily overcome with
> additional code.

In the past I have had the need for a filter that works not just on the end of 
the string but sometimes in the middle. For example truncating a long filename, 
you might want to show the first bit and the last it.

myfilewithasuperlong...thisnameisreallylong.jpg

Doing this in the template is not a good idea, but with a template filter you 
can do it with an extra argument.

+1

--

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

Re: Possible bug with multi-db changes

[Sean Brant]

> Thanks for the report. I'll try and take a look at this today and work
> out what is going on. In the meantime - if you could open this as a
> ticket, I'd be much obliged.

Russ

I created a ticket for you http://code.djangoproject.com/ticket/12453.

Thanks for looking into this.
- Sean

--

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

Possible bug with multi-db changes

[Sean Brant]

I just upgraded to the latest trunk today and the admin now throws an
exception http://dpaste.com/138130/ when I try and save to a
ImageField. I messed with it a bit to make sure that it was not
something else in my code that could be causing the error. It looks
like the error only occurs when I have inlines defined on my
ModelAdmin and I try and save an image. He is the simplest thing that
fails for me. I only tested this on sqlite.

# admin.py
from django.contrib import admin
from django.contrib.auth.models import User

from models import Account, Membership

class MembershipInline(admin.TabularInline):
model = Membership

class AccountAdmin(admin.ModelAdmin):
model = Account
inlines = [
MembershipInline,
]

admin.site.register(Account, AccountAdmin)


# models.py
from django.contrib.auth.models import User
from django.db import models

class Account(models.Model):
name = models.CharField(max_length=100)
logo = models.ImageField(upload_to='logo')
users = models.ManyToManyField(User, through='Membership')

class Membership(models.Model):
user = models.ForeignKey(User)
account = models.ForeignKey(Account)

--

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

Re: Running unit tests when you can't create a new database

[Sean Brant]

This might help you out
http://ericholscher.com/projects/django-test-utils/keep_database_runner.html.
Or at least give you some pointers.

- Sean

On Wed, Dec 9, 2009 at 2:16 PM, Martin Omander  wrote:
> Russ,
>
> The method you describe sounds like the preferred way. It's cleaner to
> add a new test runner module than to modify existing Django code. I
> really like it.
>
> But as you say, it's not obvious how to do this. I'd like to do a
> write-up of how this is done, for the common use case where you don't
> have database creation privileges.
>
> Before I dig in and try to figure this out by myself, has anyone out
> there written a test runner you could share with me?
>
> /Martin
>
>
>
> On Dec 9, 4:50 am, Russell Keith-Magee  wrote:
>> On Wed, Dec 9, 2009 at 7:22 PM,   wrote:
>> >> Django allows you to define a custom test runner. Copy
>> >> django.tests.simple.run_tests() into your own code, removing the calls
>> >> to create and destroy the test database. Then set TEST_RUNNER in your
>> >> settings file to point at the new runner.
>> > Hello!
>> > I see many similar bugreports and wishes which was closed with this
>> > proposal.
>>
>> > Unfortunately this will not work with recent django versions.
>> > Errors like AttributeError: 'Settings' object has no attribute
>> > 'DATABASE_SUPPORTS_TRANSACTIONS'
>>
>> Ok - I oversimplified slightly. You can't just delete the call to
>> create the test database. You need to replicate some of the logic that
>> the backend that establishes the extent of transaction support on your
>> database of choice.
>>
>> My point still stands - Django ships with an ability to control and
>> customize the testing process. You just need to pick the
>> customizations that are required by your particular deployment
>> scenario.
>>
>> Yours,
>> Russ Magee %-)
>
> --
>
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>
>

--

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

Re: Django needs for normal sequence of handlers for request processing

[Sean Brant]

Oh, forgot there are also signals that might help.
http://docs.djangoproject.com/en/dev/ref/signals/#module-django.core.signals

:)

--

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

Re: Django needs for normal sequence of handlers for request processing

[Sean Brant]

Not sure if this would solve the problem, but have a look at
django.utils.ddecorators.decorator_from_middleware.

"""
Given a middleware class (not an instance), returns a view decorator. This
lets you use middleware functionality on a per-view basis.
"""

This also might be best discussed on django-users for now.

--

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

template or is it template_name

[Sean Brant]

Stop me if you have heard this one before. Anyone else find it
annoying that direct_to_template takes the kwarg "template" and most
other generic views take "template_name". Smells a little like php to
me.

Is this something that should be / can be fixed?

Sean

--~--~-~--~~~---~--~~
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: Regularly-scheduled Django sprints, first December 11 - 13

[Sean Brant]

> Sure that'd be great, I guess we don't really need to start planning
> until it gets a little closer, but if we want to have any discussions
> about the local things let's try to revive the django-chicago mailing
> list :)
>
> Alex

Yeah, I agree. If you need admin access to that list I think Tom can
help with that.

Sean

--~--~-~--~~~---~--~~
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: Regularly-scheduled Django sprints, first December 11 - 13

[Sean Brant]

Alex, I can help you out in Chicago if you need it.

Sean

--~--~-~--~~~---~--~~
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: CSRF changes - backwards incompatible

[Sean Brant]

Interesting note. A co-worker of my has been working with the poll
tutorial for a couple days now and just got to part 3 which now
contains the {% csrf_token %} tag. He could not figure out how why he
was getting an error that the csrf_token tag could not be loaded.

I'm not sure how wide spread this will become, but I think for new
users it could be a problem. When asked what version of the doc he was
using he replied the one for trunk. He is running trunk but he did not
svn up for a few days hence his trunk falling behind.

Im not sure the best way to combat this problem, it was easily spotted
by me but only because I follow this list. Maybe the problem is people
that are learning should not be learning on trunk, which probably goes
without saying.

Anyways just thought I'd drop a real life user story seeing how this
feature just landed.

- Sean

--~--~-~--~~~---~--~~
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: shortcut proposal

[Sean Brant]

>
I agree with Russ that why I hinted this might be better left for  
domain code. In my decorator I do check for an instance of  
HttpResponse and pass that thru unchanged. So of you want to return a  
HttpResponseRedirect inside if a if statment it will still work. My  
only problem is the boiler plate code required to check accept headers  
and returning the correct response format. Say you want to create an  
API were the same view function returns multiple response formats. I'm  
cool with anything that make it so we don't have use RequestContext it  
seems like doing so is always the defualt anyways

If anyone is interested I can produce sample code.
>

--~--~-~--~~~---~--~~
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: shortcut proposal

[Sean Brant]

Using a decorator allows you to do cool things like

@provides_html('myapp/mypage.html')
@provides_json(optional_serialize_callback_can_go_here)
def my_view(request):
return {'foo': 'bar')

Then your provides_* could check the accept-header and know how to
response. Html renders a template and json would serialize the dict.

With that said this probably falls into the domain specific use case
and is probably not needed by enough people to be added to core,
however doing ajax apps are a breeze.

sean

--~--~-~--~~~---~--~~
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: Proposal: Tutorial Refresh

[Sean Brant]

+1 Simon's idea of a conference site. Adding some features like
http://hello.carsonified.com/ would be cool to have, though it might
be to advance for this kind of tutorial.

Sean

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

set_urlconf/get_urlconf patch

[Sean Brant]

I have updated the patch on this ticket (http://code.djangoproject.com/
ticket/5034) that SmileyChris wrote a while back. I ensured that the
new patch works against rev:11590.

In talking to SmileyChris about this on the IRC channels he noticed
that not clearing the _urlconfs dict after each request could cause a
memory leak. I added a finally statement in
handlers.base.BaseHandler.get_response which will ensure that urlconf
gets reset after each requets/response.

I'm not sure what to do from here, it would be nice if some of the
core could chime in on this. It doesn't change to much with how stuff
works currently. Although we would probably have to take the warning
out until 1.3.

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