get_random_secret_key not documented!?

[Sam]

In the DigitalOcean documentation 

 
I just found that they use
`from django.core.management.utils import get_random_secret_key`
to generate a new, unique secret key.

I didn't know that there was such a function.
and the get_random_secret_key function seems to be not documented so far 
.

Is this the recommended way to generate secret keys for Django apps?
If that's the case wouldn't it make sense to write a piece of documentation 
for that?

Kind regards,
Samuel✌

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c6e885bc-b595-4833-a2c2-651e3b677b6cn%40googlegroups.com.

DATABASE_URL not documented?

[Sam]

Hi!
While reading* Getting Started on Heroku with Python 
<https://devcenter.heroku.com/articles/getting-started-with-python#provision-a-database>
 
(Provision a database)*, they are talking about *DATABASE_URL* as if it was 
something which is implemented in Django by default.
As far as I know the *DATABASE_URL *is some kind of alias to access the 
*default 
*of *DATABASES *(?). 

However I don't find any documentation about it.
When I search for *site:djangoproject.com "database_url"* 
<https://duckduckgo.com/?q=site%3Adjangoproject.com+%22database_url%22&t=h_&ia=web>*,
 
*I mostly find forum posts discussing issues where DATABASE_URL is included.
I found ticket #28236 <https://code.djangoproject.com/ticket/28236> which 
suggests integrating dj-database-url into Django, which talks about the 
"DATABASE_URL environment variable".
The ticket is not solved after five years.

As you see, I am quite confused what *DATABASE_URL* actually is, since it 
seems considered common sense (or at least common use).
And therefore I'd suggest to mention it somewhere in the Django Docs.
Does it make sense?

I've expected to find it somewhere in the settings reference 
<https://docs.djangoproject.com/en/4.0/ref/settings/>.

Kind regards,
Sam

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3b05c53f-b3a6-4220-aa84-182cd5cea97bn%40googlegroups.com.

Re: DATABASE_URL not documented?

[Sam]

Thank you for the quick response.

Adam Johnson schrieb am Donnerstag, 3. März 2022 um 14:44:01 UTC+1:

> No it's not built in to Django, it's only supported via dj-database-url. 
> The Heroku docs could be improved. They seem to make a passing mention 
> here: 
> https://devcenter.heroku.com/articles/python-concurrency-and-database-connections
>  
> .
>
> On Thu, Mar 3, 2022 at 8:07 AM Sam  wrote:
>
>> Hi!
>> While reading* Getting Started on Heroku with Python 
>> <https://devcenter.heroku.com/articles/getting-started-with-python#provision-a-database>
>>  
>> (Provision a database)*, they are talking about *DATABASE_URL* as if it 
>> was something which is implemented in Django by default.
>> As far as I know the *DATABASE_URL *is some kind of alias to access the 
>> *default 
>> *of *DATABASES *(?). 
>>
>> However I don't find any documentation about it.
>> When I search for *site:djangoproject.com "database_url"* 
>> <https://duckduckgo.com/?q=site%3Adjangoproject.com+%22database_url%22&t=h_&ia=web>*,
>>  
>> *I mostly find forum posts discussing issues where DATABASE_URL is 
>> included.
>> I found ticket #28236 <https://code.djangoproject.com/ticket/28236> which 
>> suggests integrating dj-database-url into Django, which talks about the 
>> "DATABASE_URL environment variable".
>> The ticket is not solved after five years.
>>
>> As you see, I am quite confused what *DATABASE_URL* actually is, since 
>> it seems considered common sense (or at least common use).
>> And therefore I'd suggest to mention it somewhere in the Django Docs.
>> Does it make sense?
>>
>> I've expected to find it somewhere in the settings reference 
>> <https://docs.djangoproject.com/en/4.0/ref/settings/>.
>>
>> Kind regards,
>> Sam
>>
>> -- 
>> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/3b05c53f-b3a6-4220-aa84-182cd5cea97bn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/3b05c53f-b3a6-4220-aa84-182cd5cea97bn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bb655416-c552-4fad-a71b-5fc6c6f2068cn%40googlegroups.com.

Re: Student Proposal for Google Summer of Code 2012

[Sam Lai]

On 5 February 2012 20:16, j4nu5  wrote:
> Hi,
>
> Google Summer of Code 2012 has been announced.
> http://google-opensource.blogspot.com/2012/02/google-summer-of-code-2012-is-on.html
>
> I want to work on extending Django's database migration capabilities,
> as a student.
>
> Database migrations have always been a pain in Django and most people
> rely on third party apps like South or Nashvegas for migrations. I
> feel migration capabilities should be made part of the main codebase.
>
> Specifically, adding a new field to an existing model and issuing
> 'manage.py syncdb' has no effect since manage.py does not issue ALTER
> TABLE commands. Adding such functionality might be difficult to
> implement but will be a boon to new users (especially those migrating
> from Rails who are used to out of the box migration support).
>
> Is this project worthy of being taken up for this year's Summer of
> Code?

Disclaimer: I'm not in any way involved with Django's GSoC participation.

A schema alteration API was one of the accepted projects last year,
which unfortunately, was not successfully completed[1]. So I'd say
it's definitely worthy. Might be worth having a look at the code that
was completed in last year's attempt to see if it is worth including
in your proposal.

Last year's ideas are here [2], and if that page's history is any
indication, this year's ideas should be up fairly soon.


[1] 
http://groups.google.com/group/django-developers/browse_thread/thread/a52202349049472f
[2] https://code.djangoproject.com/wiki/SummerOfCode2011

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

startproject template context

[Sam Simmons]

For app/project 
templatesI
 found the docs a little misleading when they say 'Any 
option passed to the startapp command' will be added to the context. This 
got me thinking I could add arbitrary options to the command and pass them 
in to the context, which would make for some highly configurable 
app/project boilerplates. But, from looking at the 
source
 I 
gather by 'any options' they meant any valid options for the 
startapp/project commands.

Do you think it would be a cool feature to be able to pass any options or a 
file that defines additional context (maybe something consumable by 
ConfigParser)?

e.g.

bp-options.conf:

[options]
coffee
compass
css_dir=sass
js_dir=coffee

~/projects$ django-admin.py --template=/path/to/boilerplate 
--context=/path/to/bp-options.conf myproject

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/MZhSq2bv90sJ.
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: startproject template context

[Sam Simmons]

Ok, thanks. Will open one now.

On Tuesday, May 1, 2012 4:58:16 PM UTC-5, Ramiro Morales wrote:
>
> On Tue, May 1, 2012 at 11:04 AM, Sam Simmons  
> wrote: 
> > For app/project templates I found the docs a little misleading when they 
> say 
> > 'Any option passed to the startapp command' will be added to the 
> context. 
>
> You' ve understood the documentation correctly. This is a feature that is 
> currently (and AFAICT was DOA) not fully implemented because there is code 
> to 
> process and add the custom command line switches to the context but the 
> validation that the management commands framework performs on the command 
> line 
> options isn't allowing them to pass. 
>
> Please open a ticket in our issue tracker. 
>
> Thanks. 
>
> -- 
> Ramiro Morales 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/vptAIAgj1JAJ.
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: startproject template context

[Sam Simmons]

Here it is for future reference: https://code.djangoproject.com/ticket/18277

On Tuesday, May 1, 2012 4:58:16 PM UTC-5, Ramiro Morales wrote:
>
> On Tue, May 1, 2012 at 11:04 AM, Sam Simmons  
> wrote: 
> > For app/project templates I found the docs a little misleading when they 
> say 
> > 'Any option passed to the startapp command' will be added to the 
> context. 
>
> You' ve understood the documentation correctly. This is a feature that is 
> currently (and AFAICT was DOA) not fully implemented because there is code 
> to 
> process and add the custom command line switches to the context but the 
> validation that the management commands framework performs on the command 
> line 
> options isn't allowing them to pass. 
>
> Please open a ticket in our issue tracker. 
>
> Thanks. 
>
> -- 
> Ramiro Morales 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/3bdweBGlnZoJ.
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: startproject template context

[Sam Simmons]

Using a custom command with defined options will work quite nicely and be 
much clearer. Thanks for the suggestion!

At the very least, the existing --template option shows an interesting 
example of using the template engine to render arbitrary files.

On Friday, June 8, 2012 4:37:38 AM UTC-5, Jannis Leidel wrote:
>
>
> On 07.06.2012, at 17:32, Luke Plant wrote: 
>
> > On 01/05/12 22:58, Ramiro Morales wrote: 
> >> On Tue, May 1, 2012 at 11:04 AM, Sam Simmons  
> wrote: 
> >>> For app/project templates I found the docs a little misleading when 
> they say 
> >>> 'Any option passed to the startapp command' will be added to the 
> context. 
> >> 
> >> You' ve understood the documentation correctly. This is a feature that 
> is 
> >> currently (and AFAICT was DOA) not fully implemented because there is 
> code to 
> >> process and add the custom command line switches to the context but the 
> >> validation that the management commands framework performs on the 
> command line 
> >> options isn't allowing them to pass. 
> > 
> > This sounds like it would be a misfeature. 
> > 
> > It is a golden rule of command line apps that typos in options passed to 
> > the command are not silently ignored. 
> > 
> > If I type: 
> > 
> > django-admin.py startproject --tempate=/home/me/foo 
> > 
> > I should get an exception, not the default template rendered with 
> > "tempate=/home/me/foo". 
>
> Fully agreed, that's why you'd have to add the options to a command 
> subclass 
> in your own code base (with make_option) if you want the command to pass 
> that 
> option as a context variable. This was done intentionally to help Django 
> based apps/frameworks to extend the default startproject with their own 
> conventions. It was *not* meant to remove the base convention of editing 
> a setting file to configure a project but rather to supplement it with 
> basic 
> metadata. 
>
> > The feature given in the patch on ticket #18277, is however, much more 
> > like it - you have to pass the context using --add-context 
>
> I can see that some projects need a lot more information when being 
> created, 
> but I would prefer to  not add a key/value option to the command as it's 
> obviously 
> a horrible UX compared to the general functionality of optparse options. 
> Instead I'd be interested to see more actual use cases for running 
> startproject 
> to decide if and how we could move this feature forward. 
>
> Jannis 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/rjk9RQR6aykJ.
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: Django URL Admin (django-urls)

[Sam Solomon]

Yeah, I agree, as it is, I can't see any reason why I would use it, but I 
could see it being useful with some modifications such as:

1) Being able to create redirects (which seems to already be on the 
todo-list)
2) Being able to specify extra kwargs to pass to a view so that it would be 
possible to change the functionality of a view without adding a new model 
to store the different options (or have to change the urlconfig and push 
new code every time).

Until those things are implemented (which allow for things that could 
probably be implemented in more straightforward/non-dev-user friendly 
ways), it seems like a bad idea to store infrastructure in the database (I 
can only see it causing problems when you have developers working from a 
different urlconf than the production server is using).

On Friday, December 14, 2012 11:31:34 PM UTC-6, Amirouche B. wrote:
>
>
>
> On Friday, December 7, 2012 9:07:32 PM UTC+1, Zach Borboa wrote:
>>
>> Does something like this exist already? If not, it should.
>
>
> How this can be useful ? You still need to write the view in Python then 
> why not write the urls in Python too, like it's currently the way to go.
>
> If something in this spirit might be useful is something where the view 
> could be generated which would be something like databrowser or admin.
>
> Could you elaborate ?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/GSfX8xoF550J.
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: #14633 - organization of settings docs

[Sam Lai]

Looks good. Adds a bit more structure for browsing but doesn't
significantly change how the page is used, which is probably through
CTRL-F.

As mentioned by others in the issue, the distinction current and
deprecated settings seems very arbitrary. I think it'll be better to
sort the deprecated settings like any other setting, but include a
better visual distinction to indicate that they're deprecated (at
least bold the word deprecated I think). When someone's looking for a
setting, they're not thinking about whether or not a setting is
deprecated; they're probably looking for what it means and how it can
be configured.



On 8 January 2013 08:02, Tim Graham  wrote:
> I'd appreciate feedback on #14633 - "Organize settings reference docs". So
> far I've broken out the settings for each contrib app into their own
> sections. The one comment on the pull request suggests further breaking up
> the settings listed in the "Core settings" section, e.g. logging, caches,
> globalization (i18n/l10n), email, file uploads/media, storages, and
> security. I don't feel strongly about this proposal: it could be useful, but
> it could also be ambiguous as to which section a particular settings belongs
> in.
>
> The pull request also suggests organizing the default settings.py in a
> similar fashion.  While it may be outside of the scope of this ticket, it
> could be worthwhile to discuss that suggestion as well.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/Uku6Vo8oCvIJ.
> 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: Perception of attitude in tickets

[Sam Solomon]

As an outsider with very little data (so you can ignore this if you 
strongly disagree), I sort of agree with the notion that "WONTFIX" could be 
sending a different signal that it is being used for.

WONTFIX to me would mean, "We acknowledge that this is an annoyance for 
some people, but we're not going to fix it no matter what you or anyone 
else says".

Maybe a compromise is using a variation on the same terminology but 
softening it to "PROBABLYWONTFIX" when it's something that you don't think 
is a serious problem but could theoretically be swayed with a good proposal 
and other people stepping up to submit patches and fight for the feature.

"WONTFIX" would still be appropriate for firm "no, never, this isn't just a 
poorly stated proposal, it's either too difficult or is actually counter to 
our overall goals even though it is a valid 'issue'".

Some references of WONTFIX in the wild/in other contexts/discussions:

http://contribute.jquery.org/wont-fix/

http://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Use "WONTFIX 
is used for things that are valid requests, but that the team can't do"

http://programmers.stackexchange.com/questions/58950/defect-statuses-wont-fix-vs-cancelled




On Tuesday, May 14, 2013 3:56:26 AM UTC-7, Daniele Procida wrote:
>
> On Mon, May 13, 2013, Łukasz Rekucki > 
> wrote: 
>
> >> The status WONTFIX sounds awfully rude to me. It's like saying "That's 
> a 
> >> pony and you can't have one, ever." It implies a terminal finality 
> which 
> >> actually isn't meant in some cases, because it is possible (as we've 
> seen) 
> >> and even sometimes recommended by a core developer, for a sufficiently 
> >> determined person to push for change on the mailing list and make it 
> happen. 
> >> 
> > 
> >You can blame this on my lack of social skills, but I really don't see 
> how 
> >it's rude. 
>
> Maybe it's not rude, but it is off-putting. Perhaps there are some 
> proposals that really do deserve to have the door closed firmly in their 
> faces - that's what "WONTFIX" suggests to me, even if it's not what's 
> intended. 
>
> Daniele 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GSoC 2015: Template engine optimisation

[Sam Cooke]

I've done a couple of days of investigation into template performance
recently trying to speed up our site and my main takeaway was that there
was no silver bullet - no particular node taking up all of the time. I was
mostly trying to optimise a particularly complicated template we render a
lot in a loop so I was modifying the template, Django code and making
custom tags to see what would make a difference rather than trying to
decipher profiles. We use the cached template loader so compile time wasn't
really considered.

We tried the following things and none of them made more than a couple of
percent of difference each:

 - we made a cut down {% url %} tag that just does what we need - the built
in tag can handle a lot more at a performance cost
 - I grouped {% with %} statements together - ideally grouping into {%
include ... a=b c=d %} - to avoid extra layers of context
 - I ditched TextNodes that just contained whitespace (both by removing the
whitespace and by automatically removing the Nodes on compile) - it's easy
for these to build up when you have code like the following and every extra
node slows things down a bit (whitespace is sometimes meaningful so we
would have only implemented this for particular bits of code)

{% if whatever %}
   {{ my_var }}
{% endif %}

 - I also tried commenting out (or replacing with "return '' ") chunks of
the template engine code and our template and it just seemed that the more
I commented out, the faster it ran - no particular jumps in speed, just  a
gradual change as more was removed. Escaping was one of the first things I
commented out and it made a surprisingly small amount of difference.

I'd be very happy to be proven wrong but thought it was worth sharing my
findings since - particularly in the context of Preston's suggestion that
we might find a bottleneck - I don't think there is one particular
bottleneck.

Our "solution" for now has been to speed up the processors in our servers
and investigate switching to pypy - we'll probably be looking at Jinja2
once we upgrade to 1.8 as well.

Sam

On Thu, 12 Mar 2015 at 15:57 Preston Timmons 
wrote:

> After a while I believe layers and layers of caution have accrued, and
>> nobody is sure any more where these have overlapped excessively.
>>
>
> Do you have examples of which layers these are?
>
> Escaping seems to happen in Variable, VariableNode, FilterExpression, and
> render_value_in_context. I don't see a lot of work being done twice there.
>
> If you think the escape implementation is slow, though, it wouldn't be
> hard to simply remove that and benchmark with no escape code running. That
> would at least reveal the theoretical limit to which the escape code could
> be improved.
>
> On another note, in my benchmark I see the difference to render a somewhat
> complex template between Django and Jinja2 at 8-9 times.
>
> From one run, just grabbing the minimum time to render a template:
>
> Django: 9.08e-05
> Jinja2: 1.38e-05
>
> The big difference here is because Django uses a recursive node-based
> renderer, whereas Jinja2 just translates the template into Python. That
> means a lot less overhead when rendering happens.
>
> Optimizing Django rendering means either:
>
> 1) Identifying the nodes which are a bottleneck and reducing the work they
> do
> 2) Replacing node rendering with something that's faster.
>
> Option 2 probably has the biggest opportunity for gain, but it would
> require some real creativity to maintain backwards-compatibility with
> existing tags.
>
> Preston
>
> --
> 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/957b9840-b537-4861-9390-e7b6f44dd72c%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/957b9840-b537-4861-9390-e7b6f44dd72c%40googlegroups.com?utm_medium=email&utm_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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyx3A0Pxw1FyxWW9VqL7B6EaF3vEF7bJn%3DsWP9c7YsUZUzQFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2015: Template engine optimisation

[Sam Cooke]

Preston - I'll send the template to you directly, I'm not sure how useful
it will be so I don't want to spend time checking if it's fine for public
consumption unnecessarily.

The test template we were using to test the performance was a simple:

{% for item in item_list %}{% include "item.html" %}{% endfor %}

Where "item.html" is the complex one (for a real world example, it's the
"cards" you can see in the chart on https://www.mixcloud.com/tag/house/)
and item_list is a list of 200 items (with all of the database queries done
in the view). Averaging runs after the first run (which would include the
compile) it was taking close to 1s per render. With the non-breaking
changes (i.e. not commenting out necessary engine or template code) I
managed to get it down to just under 0.9s. In both cases there was an
overhead of around 0.2s (render time if I ran with the entire template
commented out). Running the test with pypy (after warming it up) the render
time was 0.5s. Sorry I don't have more exact numbers - this is just the
headline notes I took away from the task.

As I removed chunks of template or engine I just found that anything I
removed made a couple of percent of difference. The first thing I tried to
optimise was the include tag and it only made a small difference - I even
tried merging the "for", "include" and "with" tags into a new tag to avoid
the 2 unnecessary contexts created by the two inner tags - my rough memory
was that made a 3-4% difference in this particular case and we decided not
to use it due to the added complexity of our code.

Most of our page render times on www.mixcloud.com are proportional to the
number of cards we have on the page.

Sam

On Thu, 12 Mar 2015 at 18:07 Preston Timmons 
wrote:

> I've done a couple of days of investigation into template performance
>> recently trying to speed up our site and my main takeaway was that there
>> was no silver bullet - no particular node taking up all of the time. I was
>> mostly trying to optimise a particularly complicated template we render a
>> lot in a loop so I was modifying the template, Django code and making
>> custom tags to see what would make a difference rather than trying to
>> decipher profiles. We use the cached template loader so compile time wasn't
>> really considered.
>>
>
> Thanks, Sam. That's helpful information.
>
> I'd be interested to know the template you used, or at least one
> representative of the template you used. Templates that highlight
> real-world pain points would help to benchmark the things that matter.
>
> Did you apply all the internal Django changes you mentioned cumulatively?
> If so, what was your overall rendering time improvement? How did the
> speedups from changing nodes compare to the speedups from modifying the
> engine? It sounds like the engine changes were a factor because of multiple
> calls to the include tag.
>
> While the changes you mentioned don't sound like ones that could go into
> Django, they do shed light on what can potentially be done or not for
> optimization.
>
> Preston
>
>
>
>
>> We tried the following things and none of them made more than a couple of
>> percent of difference each:
>>
>>  - we made a cut down {% url %} tag that just does what we need - the
>> built in tag can handle a lot more at a performance cost
>>  - I grouped {% with %} statements together - ideally grouping into {%
>> include ... a=b c=d %} - to avoid extra layers of context
>>  - I ditched TextNodes that just contained whitespace (both by removing
>> the whitespace and by automatically removing the Nodes on compile) - it's
>> easy for these to build up when you have code like the following and every
>> extra node slows things down a bit (whitespace is sometimes meaningful so
>> we would have only implemented this for particular bits of code)
>>
>> {% if whatever %}
>>{{ my_var }}
>> {% endif %}
>>
>>  - I also tried commenting out (or replacing with "return '' ") chunks of
>> the template engine code and our template and it just seemed that the more
>> I commented out, the faster it ran - no particular jumps in speed, just  a
>> gradual change as more was removed. Escaping was one of the first things I
>> commented out and it made a surprisingly small amount of difference.
>>
>> I'd be very happy to be proven wrong but thought it was worth sharing my
>> findings since - particularly in the context of Preston's suggestion that
>> we might find a bottleneck - I don't think there is one particular
>> bottleneck.
>>
>> Our "solution" for now 

Re: GSoC 2015: Template engine optimisation

[Sam Cooke]

Even with the cached template loader? Before realising it was unnecessary
one of the first things I did was hack something together that took the
nodelist from the include and stuck it straight into the for loop's
nodelist at compile time and it didn't make much difference.

Sam

On Fri, 13 Mar 2015 at 21:40 Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> 2015-03-13 12:21 GMT+01:00 Sam Cooke :
>
>> The test template we were using to test the performance was a simple:
>> {% for item in item_list %}{% include "item.html" %}{% endfor %}
>>
>
> Bad luck -- including a template in a loop is one of the known pathological
> performance cases of the DTL :-(
>
> --
> Aymeric.
>
> --
> 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/CANE-7mXhB%2BgUNt_vZpvmMwBFfu1wYDBHaMWh1kx-HKg1%3DFcUGA%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CANE-7mXhB%2BgUNt_vZpvmMwBFfu1wYDBHaMWh1kx-HKg1%3DFcUGA%40mail.gmail.com?utm_medium=email&utm_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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyx3A21SKQYCCr2Zbs_e9MwkyShGtN2TCOpiARKUcjS4Q%3DijQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Setting database default values in migrations (postgres)

[Sam Baron]

Greetings, I know this is an old thread, but it's an issue I am coming up 
against and hopefully I can restart the conversation.  I do think it's 
important that we use as many native database features as possible for 
application portability, extensibility, and performance.

I have a different solution to the database default problem.  Why not 
handle it like SQLAlchemy?  There are two field properties for default - 
one applied at model instance (current Django default behavior) and one 
sent to the database.  In SQLAlchemy, it's called 'server_default', but for 
Django, I think 'db_default' would be a more appropriate name.  

So for example:
integer_column = models.IntegerField(default=0)
OR
integer_column = models.IntegerField(db_default="0")

And I agree that callables would not be included in 'db_default'.  This new 
property would only be for pushing SQL.  With this solution, I think you 
avoid user errors by keeping the two defaults behavior separate.  Only the 
advanced database folks will end up using it.

I have made the relatively minor code changes on my end.  I am in the 
process and starting a new project and will keep testing it out.  I am 
curious if this would be an acceptable solution.

Thanks,
Sam


On Saturday, November 1, 2014 at 10:17:50 AM UTC-7, Shai Berger wrote:
>
> On Friday 31 October 2014 19:16:15 Jon Dufresne wrote: 
> > On Fri, Oct 31, 2014 at 9:46 AM, Andrew Godwin  > wrote: 
> > > So, bear in mind that you can easily set these defaults yourself in a 
> > > migration with RunSQL if you need them for legacy purposes; that way 
> > > they'll get applied 
> > 
> > Absolutely. I effectively have such a system in place at the moment. 
> > 
> > But, my point is I am also making an effort to match Django's expected 
> > schema while moving away from the legacy schema. I would prefer not to 
> > drift too far from Django's expectations as the goal is move entirely 
> > to Django. This is just one more thing to keep track of and handle 
> > semi-manually. 
> > 
> > All I'm saying is that if the described feature existed, it would 
> > benefit me and others that share my use case. 
>
> So, we should be weighing the support-transition-from-legacy use-case 
> against 
> creating a situation where field defaults get a special treatment if they 
> are 
> primitive enough (callables are out, but I am really not sure about other 
> complex objects -- GIS would probably gain a new dimension of fun if it 
> were 
> to deal  with defaults, even when not callable). 
>
> I think the correct way forward for migrations is to keep as it does today 
> -- 
> requiring users to explicitly ask for db defaults (we could, as I said 
> earlier, give it a nicer API than RunSQL). 
>
> As for "Django's expectations" -- while I don't think we should generate 
> db 
> defaults unless specifically asked to, I don't see where such defaults 
> could 
> get in our way. If you ever run into a situation where Django mishandles 
> some 
> table because it has defaults, that is almost for sure a bug. 
>
> My 2 cents, 
> 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/e7d99cf6-c6a5-4d32-994c-7dd4e07ad478%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Template Components

[Sam Solomon]

So a former co-worker with some help/guidance from me developed a component 
system on top of Django that sounds sorta like what you are all talking 
about. It's very complicated and I'm still not sure whether it was 
ultimately a good idea to use or not, but it does make some things very 
simple (and we have no plans to move away from it at this point after ~2 
years of use). I'll post some snippets from our internal docs on it now and 
if people are interested, I can explain more and possibly open source it:
Background: What?

Specialized class based views and sub-views, that facilitate:

   - Split page template into components, each of which can be POSTed to 
   and/or updated via ajax.
   - View code and templates for full page view and ajax update is the same 
   code. (DRY, though more data over the wire than some of the newer 
   javascript frameworks)
   - Updating multiple parts of the page with a single request (example: 
   POSTing to one component can cause dependent components to also be updated 
   in the same request)
   - Built-in compatibility to handle no-js in most situations
   - Deferred loading of components, for performance

Background:
 
Why?
   
   - Complex site with lots of logged in user interactions where content 
   should be easy to change dynamically
   - Slow connections overseas (minimize round trips and limit full page 
   loads without sacrificing dev time too much)
   - Some may not even have JS? (Though we don't really cater to them that 
   much anymore, this was a consideration originally and still mostly 
   supported by default outside of where we use d3 and things like that for 
   rendering certain things.)


On Monday, June 1, 2015 at 12:55:08 AM UTC-7, Unai Zalakain wrote:
>
> Finally someone expressed my own feelings about it perfectly :D 
>
> On Sun, May 31, 2015 at 08:32:18PM -0500, Joe Tennies wrote: 
> >I actually think this is a great idea. In my mind it parallels Drupal's 
> >"block" idea. (This is actually what I keep hoping DjangoCMS is.) 
> > 
> >That stated, it is more of a construct. I think a great idea is to make 
> an 
> >extension module. 
> > 
> >I don't know how long you've been in this community, but Django is now 
> >quite stable and people rely on their APIs. Your bold ideas really need 
> to 
> >be tested by fire before they go into the Django proper. There's been 
> lots 
> >of discussion about a year ago to remove/reduce a lot of the contrib. 
> > 
> >Being in Django is where things go to die. Once an API is released to the 
> >public, it takes a fair amount of work to remove/change it. You don't 
> even 
> >want to know how long it took to get schema migrations into Django. South 
> >had been the defacto way for quite a few years. That stated, Andrew had 
> to 
> >make some changes to South due to design decisions that were made earlier 
> >in South. Before that, there was other projects like django-evolution 
> >(which just got an update 2 months ago). 
> > 
> >So, I followed the Drupal group for a while. The thing the Django 
> community 
> >really needs is a couple good opinionated groups of how to put together a 
> >good Django site. Drupal has Lullabot (who have quite a few core devs on 
> >staff). Django is not going to be the people telling people how to use 
> >Django. You seem like a great person to start this for Django. Note that 
> >you'll have to have a thick skin and create some pretty great sites in 
> your 
> >own right to prove out your ideas to others. You'll also need to get your 
> >ideas out via things like blog posts, tutorials, and podcasts. 
> > 
> >I would like the Caktus, DjangoCMS, FeinCMS, etc people to do the same. 
> >This would help people to see some different ideas on how to use and 
> extend 
> >Django. 
> > 
> >On Sun, May 31, 2015 at 5:26 AM, Emil Stenström  > wrote: 
> > 
> >> On Sunday, 31 May 2015 11:36:51 UTC+2, riccardo.magliocchetti wrote: 
> >>> 
> >>> Il 31/05/2015 11:00, Emil Stenström ha scritto: 
> >>> > On Sunday, 31 May 2015 10:27:24 UTC+2, riccardo.magliocchetti wrote: 
> >>> > Il 30/05/2015 18:52, Emil Stenström ha scritto: 
> >>> > But your proposal keeps html and js separated. I think you are 
> >>> solving a 
> >>> > problem 
> >>> > for the one that just want to use a component but you are not 
> >>> solving the 
> >>> > problem for the one that is writing components. At least not in 
> the 
> >>> react.js 
> >>> > way, especially from such a bold premise :) 
> >>> > 
> >>> > I agree that I don't quite do it the same way as React. But that's 
> not 
> >>> the point 
> >>> > here either, to somehow bundle Reacts ideas inside Django. My point 
> is 
> >>> that 
> >>> > keeping the four parts that make a component closely together in the 
> >>> project 
> >>> > source, would make for a better structure. They only idea that comes 
> >>> from React 
>

Re: Feature: Template Components

[Sam Solomon]

If someone actually wants to use it I can set aside some time within the
next week or two to actually open source the whole thing (docs + source on
github/pypi).

Here is an example of some of the basic functionality though:

*What the following code does:*
Creates a page for taking attendance of something that has 2 components, a
listing component that lists existing attendees and a entry component that
adds new people to the list.

We have javascript that disables the default form action and on form submit
submits via ajax. If there are errors, the form is displayed again with any
errors showing (over ajax), if there aren't errors, it resets the form and
also updates the listing component over ajax in a format like this (note,
though we haven't extended ourselves, it was made so that you could send
payloads other than "new_html" and make a custom handler for
"framework_example_attendance_entry" that could do something other than
simply dump new_html into the given div):
{
"actions": {
"framework_example_attendance_entry": {
"component_key": "framework_example_attendance_entry",
"new_html": "



Name:





",
"version": 1,
"js_failure_mode": "no_warn_no_update"
},
"framework_example_listing": {
"component_key": "framework_example_listing",
"new_html": "
George - Aug. 12, 2014, 1:46 p.m.
Smith - Aug. 12, 2014, 1:46 p.m.
Joseph - Aug. 12, 2014, 1:23 p.m. 
Steve - Aug. 12, 2014, 1:22 p.m.
John - Aug. 12, 2014, 1:22 p.m.
Andy - Aug. 12, 2014, 12:09 p.m.
Sam - Aug. 12, 2014, 11:13 a.m.
",
"version": 1,
"js_failure_mode": "no_warn_no_update"
}
}
}

*views.py:*

class AttendanceMixin(object):
# We encourage using Mixins that contain @obj_cache decorated methods
# that will (or in some cases may) be used by multiple components.
@obj_cache
def attendance_list(self):
return list(AttendanceRecord.objects.order_by('-id'))

@obj_cache
def num_attendees(self):
# This is free IFF we already need a list of attendees in the
# request, otherwise  we should be using
# `AttendanceRecord.objects.count()`

# Also note that it is fine to chain @obj_cache decorated methods.
return len(self.attendance_list)

class AttendanceEntryComponent(AttendanceMixin, Component):
template_name = "framework_example/entry_component.html"

def init(self):
self.ctx.this_form_url = self.this_url()

if not self.is_post():
self.ctx.attendance_form = AttendanceRecordForm(
**self.form_init())

def handler(self, request):
self.ctx.attendance_form = AttendanceRecordForm(request.POST,
**self.form_init())
if self.ctx.attendance_form.is_valid():
self.ctx.attendance_form.save()
self.ctx.attendance_form = AttendanceRecordForm(
**self.form_init())
self.add_dependent_component(AttendanceListingComponent)
return True

def final(self):
# The @obj_cache decorator turns methods into properties so note
# that this isn't `self.num_attendees()`
self.ctx.num_attendees = self.num_attendees

class AttendanceListingComponent(AttendanceMixin, Component):
template_name = "framework_example/listing_component.html"

def init(self):
self.ctx.attendance_list = self.attendance_list

class AttendancePage(Page):
template_name = "framework_example/attendance_page.html"

def set_components(self):
self.add_component(AttendanceListingComponent)

*urls.py:*
component_url(r'^attendance_listing/$',
  ComponentClass=AttendanceListingComponent,
  name="framework_example_listing"),
component_url(r'^$',
  ComponentClass=AttendanceEntryComponent,
  name="framework_example_attendance_entry",
  PageClass=AttendancePage),


*templates/framework_example/entry_component.html:*

Add a new attendee (Currently {{ num_attendees }} attending)


{% csrf_token %}
{{ attendance_form.as

Re: Feature: Template Components

[Sam Solomon]

Speaking only for myself and the component framework we built here, I don't 
think I would expect it to ever be rolled into Django itself.

However, the framework we made does work without any modifications to 
Django and works just fine alongside existing function and classed based 
views. This means no changes to existing codebases would be necessary 
(unless you wanted to buy into the concept completely and switch existing 
stuff over rather than just use it for new features, in which case it would 
require a lot of work to split up your views/templates into components 
(though if you already split up the code in your views in a logical way and 
use template includes rather than really long template files and stuff like 
that, it may not be that bad)).

On Tuesday, June 9, 2015 at 4:21:27 AM UTC-7, Yoong Kang Lim wrote:
>
> This seems like a huge change. If you were to include this feature in 
> Django, would it be straightforward for users to migrate from previous 
> versions?
>
>
>
> On Sunday, May 31, 2015 at 2:52:37 AM UTC+10, Emil Stenström wrote:
>>
>> Hi, 
>>
>> This is the first feature proposal as part of my general drive for 
>> getting Django to work better for javascript heavy sites. 
>>
>> Template Components 
>> --- 
>>
>> React.js popularized the notion that in front-end development, code 
>> organization should be based on interface components, not split up into 
>> HTML, Javascript and CSS. Here's the original presentation and the 
>> rationale behind organizing around components: 
>> https://www.youtube.com/watch?v=x7cQ3mrcKaY&t=2m7s 
>>
>> In Django, adding a Javascript calendar to you site requires changes to 
>> four different locations in your project: 
>>
>> - /app/templatetags/calendar_tags.py <- A custom inclusion template tag 
>> - /app/templates/calendar.html <- Some HTML in the template dir 
>> - /static/css/style.css <- Add some CSS to style.css 
>> - /static/js/script.js <- Add some JS to scipt.js 
>>
>> There is no connection within Django between HTML and the CSS + JS. 
>> Django does not help you, or even suggest a structure for you, like it 
>> does with all Python code. 
>>
>> On the other hand, we have Form Assets: 
>> https://docs.djangoproject.com/en/1.8/topics/forms/media/ 
>>
>> Example: 
>>
>> from django import forms 
>> class CalendarWidget(forms.TextInput): 
>>  class Media: 
>>  css = {'all': ('calendar.css',)} 
>>  js = ('calendar.js',) 
>>
>> >>> w = CalendarWidget() 
>> >>> print(w.media) 
>>  
>>  
>>
>> ... which define a kind of component, but one that is tied to a form 
>> field. My suggestion is a new package: django.template.component, that 
>> builds on the Media class from Form Assets, and allows you to define 
>> your components like this: 
>>
>> from django.template import component 
>> class Calendar(component.Component): 
>>  def context(self, date): 
>>  return {"date": date} 
>>  class Media: 
>>  template = "app/components/calendar/calendar.html" 
>>  css = {'all': ('app/components/calendar/calendar.css',)} 
>>  js = ('app/components/calendar/calendar.js',) 
>>
>> component.register(name="calendar", component=Calendar) 
>>
>> ... and later in your template: 
>>
>> {% load components %} 
>> {% block extra_media %}{% component_dependencies %}{% endblock %} 
>> {% block main %} 
>>  {% component "calendar" date=custom_date %} 
>> {% endblock %} 
>>
>> --- 
>>
>> Advantages: 
>> - You to keep the python, html, css, and javascript in one location, and 
>> explicitly define the dependencies between them. 
>> - All  and 

Re: Future of the development server's auto-reloading

[Sam Cooke]

Hi all,

I've had experience playing around with watchdog[1] before - I've only ever
used it on OS X but it should work cross platform. I've thrown together a
rough proof of concept[2] for runserver that uses watchdog to watch for
changes/additions/deletions to python files recursively in the same
directory as manage.py and restarts the server accordingly. It could easily
be extended to handle translations.

To avoid changing a lot of code I've just set it up to use watchdog if
available and fall back to the current method silently if not.

I'd be happy to turn this into a more complete solution if people think
it's the right route to go. We can choose to:
 - make watchdog required - it's a simple pip install
 - make watchdog required if you want runserver to autoreload
 - fall back to the current implementation if watchdog is not on the python
path (and potentially tell the user about watchdog)

Do you think it's worth carrying on down this path?

Sam

[1] https://pythonhosted.org/watchdog/
[2] https://github.com/django/django/compare/master...sdcooke:watchdog
(ignore the code quality - it was thrown together quickly!)

On Sun, 9 Aug 2015 at 22:22 Daniel Moisset  wrote:

> The idea sounds awesome. A couple of corner cases that should be taken in
> consideration:
>
>  - I think it is common for small simple projects (and people doing the
> tutorial) to have the sqlite db file in the same project directory. If
> we're watching for writes in every file in the project directory, every
> save() could trigger a reload
>  - It is also usual to have the media/ directory based on filesystem
> storage inside the project dir. So any project with file uploads could
> trigger a reload on each file upload.
>
> Possibly some exclusion rules with sane defaults could help here
>
> Regards,
>
> D.
>
>
>
> On Sat, Aug 8, 2015 at 6:53 PM, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> Hello,
>>
>> While writing some horrific code [1] related to the development server’s
>> auto-reloading, I realized that its design is fundamentally flawed and I
>> think that we should reconsider it.
>>
>> The current implementation walks through the list of all imported Python
>> modules, attempts to figure out which file they come from and builds a list
>> of these files. Then it watches all these files for changes by checking if
>> their mtime changed every second or, since 1.7, with inotify on Linux. I
>> tried to do it with kqueue on BSD (read: OS X) but I failed. This stuff is
>> hard.
>>
>> In addition to the source of imported Python modules, the autoreloader
>> watches .mo files in order to catch translation changes and source files
>> for modules that failed to import — it extracts them from exception
>> tracebacks. This shows the limits of basing the list on imported Python
>> modules. Even with such hacks, the auto-reloader will never handle all
>> cases. Two examples:
>>
>> - It doesn’t survive a syntax error in the settings module. I have
>> reasons to believe that this would be extremely messy to fix.
>> - If a module reads a configuration file on disk at startup and caches
>> it, the auto-reloader doesn’t detect changes to that file.
>>
>> So we’re stuck with cases where the development server doesn’t reload. I
>> can’t say they’re edge cases; who never made a typo in a settings file?
>> People who run tutorials report that it’s a very common cause of
>> frustration for beginners.
>>
>> It's also wasteful. There’s little need to watch every file of every
>> dependency in the virtualenv for changes.
>>
>> I think it would be much better to remove the auto-reloading logic from
>> Django and have an external process watch the current working directory for
>> changes. (When virtualenv is considered appropriate for people with exactly
>> 0 days of Django experience under their belt, I think we can require a
>> dependency for the development server’s auto-reloading.)
>>
>> The behavior would be much easier to describe: if you change something in
>> your source tree, it reloads automatically; if you change something
>> somewhere else, you must reload manually. It would also be quite easy to
>> customize with a standard include / exclude mechanism to select which files
>> should be watched.
>>
>> We aren’t in the business of writing production web servers, neither are
>> we in the business of writing a filesystem watcher :-) Watchman [2] appears
>> to be a robust solution. However I would prefer a pure-Python
>> implementation that could easily be installed in a virtualenv. Does someone
>> have

Re: Django Admin New Look

[Sam Cooke]

For jQuery support in older browsers it's pretty simple to include jQuery
1.11 in old IE using conditional comments - that way we retain support with
just an extra line of code, don't leave IE8 behind, and get the performance
boost of jQuery 2 in modern browsers. As far as I'm aware they are still
API compatible.

On Wed, 19 Aug 2015 at 08:23 Josh Smeaton  wrote:

> I agree with Shai. There are certain companies that have bought extended
> support for WinXP/IE8 for extravagant amounts of money. That means
> Microsoft is taking on the burden of support (security) for those systems.
> They are EOL as far as we're concerned. We shouldn't intentionally cripple
> support unless there is a reason to do so though. For example, unless we
> need jQuery2 for some purpose, maybe it's best we just leave it at it's
> current version for the moment. As for font/svg icons - alt text is fine
> for an old browser out of support.
>
>
> On Wednesday, 19 August 2015 09:25:38 UTC+10, Shai Berger wrote:
>>
>> On Tuesday 18 August 2015 14:29:15 Marc Tamlyn wrote:
>> > I don't know about schedule, but caniuse reports IE8 browser usage at
>> 1.5%,
>> > more than IE9 or IE10.
>> >
>> > There's an argument we shouldn't be "enabling" people still using XP
>> who
>> > are stuck on IE8, and this is a decreasing problem, but I don't think
>> we
>> > can tie ourselves to Microsoft's support dates.
>> >
>>
>> Sure we can, in the same sense that we "tie ourselves" to the support
>> dates of
>> PostgreSQL, MySQL and Oracle.
>>
>> 1.9 is the release following an LTS -- the perfect time for changes such
>> as
>> JQuery 2 and dropping support for old browsers. If developers need to
>> support
>> the legacy IE8, they can use Django 1.8.
>>
>> The suggestion to add a notice for IE8 users seems reasonable to me, but
>> I
>> don't think we should hold back progress just to keep the admin usable on
>> it.
>>
>> 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/4c5a22ab-ee67-46d3-a82b-18f6ebea3c39%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyx3A30C60U5B%2BfJRm%3D_VPYoEN1j2uAMCW8BjftHtio7DcaeQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Sam Cooke]

I meant jQuery 2 and 1.11 are API compatible - you're right though, the
latest versions of jQuery might have deprecated things that are currently
used in Django.

On Wed, 19 Aug 2015 at 10:39 elky  wrote:

>
> On Wednesday, 19 August 2015 14:27:53 UTC+5, sdcooke wrote:
>>
>> and get the performance boost of jQuery 2 in modern browsers. As far as
>> I'm aware they are still API compatible.
>>
>
> We should carefully check jQuery change log. I remember they removed
> toggle method in one of the latest versions, so some apps may broke because
> of that.
>
> --
> 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/446e9038-0b45-4a67-8b14-8cb402722f4b%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyx3A2AME-W_Dga6My2aea-s9r-af4nPGUWtARviWg79E4nLA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Channels integration plan, first draft

[Sam Willis]

Hi,

To support file uploads or a large message body the http.request message 
could have an file_channel or body_channel (much like its reply_channel)? 
These would be something like http.request.file.Dj3Hd9J and would stream 
chunked file or body content in the same way as the http.response message 
with a more_content attribute.

Sam

On Thursday, December 17, 2015 at 9:48:31 PM UTC, Andrew Godwin wrote:
>
> Yes, that is the idea. While it obviously adds overhead (a millisecond or 
> two in my first tests), it also adds natural load balancing between workers 
> and then lets us have the same architecture for websockets and normal HTTP.
>
> (The interface server does do all the HTTP parsing, so what gets sent over 
> is slightly less verbose than normal HTTP and needs less work to use, but 
> it's not a big saving)
>
> Andrew
>
> On Thu, Dec 17, 2015 at 9:01 PM, Anssi Kääriäinen  > wrote:
>
>> Is the idea a large site using classic request-response architecture 
>> would get the requests at interface servers, these would then push the HTTP 
>> requests through channels to worker processes, which process the message 
>> and push the response through the channel backend back to the interface 
>> server and from there back to the client?
>>
>>  - Anssi
>>
>> On Thursday, December 17, 2015, Andrew Godwin > > wrote:
>>
>>> To address the points so far:
>>>
>>>  - I'm not yet sure whether "traditional" WSGI mode would actually run 
>>> through the in memory backend or just be plugged in directly to the 
>>> existing code path; it really depends on how much code would need to be 
>>> moved around in either case. I'm pretty keen on keeping a raw-WSGI path 
>>> around for performance/compatability reasons, and so we can hard fail if 
>>> you try *any* channels use (right now the failure mode for trying to use 
>>> channels with the wsgi emulation is silent failure)
>>>
>>> - Streaming HTTP responses are already in the channels spec as chunked 
>>> messages; you just keep sending response-style messages with a flag saying 
>>> "there's more".
>>>
>>> - File uploads are more difficult, due to the nature of the worker model 
>>> (you can't guarantee all the messages will go to the same worker). My 
>>> current plan here is to revise the message spec to allow infinite size 
>>> messages and make the channel backend handle chunking in the best way 
>>> (write to shared disk, use lots of keys, etc), but if there are other 
>>> suggestions I'm open. This would also let people return large http 
>>> responses without having to worry about size limits.
>>>
>>> - Alternative serialisation formats will be looked into; it's up to the 
>>> channel backend what to use, I just chose JSON as our previous research 
>>> into this at work showed that it was actually the fastest overall due to 
>>> the fact it has a pure C implementation, but that's a year or two old. 
>>> Whatever is chosen needs large support and forwards compatability, however. 
>>> The message format is deliberately specified as JSON-capable structures 
>>> (dicts, lists, strings) as it's assumed any serialisation format can handle 
>>> this, and so it can be portable across backends.
>>>
>>> - I thought SCRIPT_NAME was basically unused by anyone these days, but 
>>> hey, happy to be proved wrong. Do we have any usage numbers on it to know 
>>> if we'd need it for a new standalone server to implement? It's really not 
>>> hard to add it into the request format, just thought it was one of those 
>>> CGI remnants we might finally be able to kill.
>>>
>>> Andrew
>>>
>>> On Thu, Dec 17, 2015 at 6:32 PM, Anssi Kääriäinen  
>>> wrote:
>>>
>>>> On Thursday, December 17, 2015, Carl Meyer  wrote:
>>>>
>>>>> Hi Andrew,
>>>>
>>>>
>>>>> - I share Mark's concern about the performance (latency, specifically)
>>>>> implications for projects that want to keep deploying old-style, given
>>>>> all the new serialization that would now be in the request path. I 
>>>>> think
>>>>> some further discussion of this, with real benchmark numbers to refer
>>>>> to, is a prerequisite to considering Channels as a candidate for Django
>>>>> 1.10. To take a parallel from Python, Guido has always said that he
>>>>> won't consider removing the GIL unless

making URL resolving/reversing gradually more flexible

[Sam Lai]

[First timer participating in the Django dev process, so apologies if
I have missed some protocol etc.]

First up, this is not about adding an alternate URL
resolution/reversal method to the core; I've noticed a fair bit of
resistance to that.

PROBLEM:
I want to make my website available via an API with URLs like this -
http://example.com/newitems/ => returns HTML
http://example.com/newitems.xml => returns XML
http://example.com/newitems.json => returns JSON.

To represent this in urls.py, I have to either:
a) write a separate url entry for each one
b) write 2 url entries, one for newitems/ and another for
newitems\.(?P\w+). This is the better option, but still
annoying. Plus it forces my view to validate whether or not the format
value is acceptable (e.g. is either xml or json).

I have to do this for every URL I wish to make available via an API,
bloating out my urls.py file. (I'm aware I can use the HTTP-ACCEPT
header instead, but there is a need to be able to force the response
format in the URL for certain uses.)

MY DESIRED SOLUTION:
Subclass RegexURLPattern, and override the resolve method so that it
will replace a placeholder, e.g. (?#format), with the appropriate
regexps (/|\.xml|\.json). Effectively it will perform something
similar to this regexp instead -
^newitems(/|(?P(\.xml|\.json))) where the list of accepted
formats will be defined in settings. This subclass will be returned
using an alternate url(...) call, e.g. murl(...).

So my urls.py will look like -
urlpatterns = patterns('project.app.views',
murl(r'^/(?P\d+)(?#format)$', AppView.as_view(),
name='app_view1'),
)

(For completeness, the view is a CBV, and uses the format arg to
determine which template to render, and using what MIME type to
respond.)

This is a proven way of extending the URL system, as demonstrated by
the various projects out there for alternative URL specification
syntaxes, e.g. django-easyurls.

ROADBLOCK:
The issue with this solution is that while resolving will work fine,
reversing will not. The list of possible URLs for a particular view is
determined by _populate in RegexURLResolver, and is based on the
regexp pattern alone. Django doesn't support | in regexps
(understandably), and there is no way to supplant this with additional
regexps or possibilities at the moment, even though the infrastructure
is there during reversal.

RESOLUTION - PHASE 1:
Because of the friction and work required to fully revamp the URL
resolution system, this phase is a short, simple fix that will suffice
for most cases where people want to extend the URL resolution system.

Refactor out line 218 (in trunk) in django/core/urlresolvers.py:

bits = normalize(p_pattern)

... into a separate method in RegexURLPattern:

def get_possibilities(self):
return normalize(self.regex.pattern)

... and replace line 218 in django/core/urlresolvers.py with:

bits = pattern.get_possibilities()

That's it. I'll create a patch for this later if the consensus is
positive. The above change allows subclassed RegexURLPattern classes
to alter what is returned as possible URLs from that pattern. I'm
hoping this simple change can be made in Django 1.3.

Of course, the possibilities returned still have to be regexps, which
leads to phase 2...

RESOLUTION - PHASE 2:
The ultimate goal should be a URL resolution system that allows
alternate URL spec syntaxes to be first-class citizens, allowing
regexp based URL specs and say, URI Template specs to exist
side-by-side.

My plan would be to create an abstract base class for all URLPatterns,
which RegexURLPattern will extend. The existing behaviour will mostly
stay, except the get_possibilities from phase 1 will be deprecated in
favour of a new reverse method. The reverse method will be called by
the new universal URLResolver class for matches when reversing URLs,
and if a match exists, that will be returned. During _populate(), the
new universal URLResolver class will group URLPattern objects by view
callback and name, instead of the output of
get_possibilities/normalize.

This approach requires no changes to existing urls.py; in fact, from a
dev perspective, they would only notice the difference if they choose
to use alternate URL spec syntaxes. The existing regexp system will
work as it has always worked. And it makes sense that the URLPattern
object is responsible for resolving and reversing itself, and not the
resolver.

Until this phase is reached, the API should be considered private so
devs are on notice that things will change and may break existing
custom URL resolution code.

Again, I'm happy to have a crack at making this work if the consensus
is positive.

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

Re: making URL resolving/reversing gradually more flexible

[Sam Lai]

On 12 November 2010 19:14, burc...@gmail.com  wrote:
> Ah, sorry, tl;dr happened to me in previous message.
>
> I used to do the following:
>
> alternatives = {'html': '/', 'xml': '.xml', 'json': '.json'}
> for name, alt in alternatives.iteritems():
>    urlpatterns += ('^newitems'+alt+'$', 'views.newitems', {'format':
> name}, 'newitems-'+name)

Then you're cluttering urls.py through code. You need to repeat that
for every API-enabled URL.

> You can make your own method that will do this.
> Anyway, only your code can know how to select one of the suggested
> alternatives for reverse, so your suggested approach has no
> advantages.

... and that's the point. It is the pattern's job to suggest
alternatives, not the resolver's.

>>This approach requires no changes to existing urls.py
> But you have to update all django 3rd party libraries to realize every
> url pattern they use can have get_possibilities !

How many third-party libraries out there use custom URL pattern
classes, ones that don't subclass from RegexURLPattern?

I doubt there are many. But to cater for this fact, the resolver can
simply check for the existence of get_possibilities, and if it isn't
there, revert to the existing behaviour. For example,

if hasattr(pattern, 'get_possibilities'):
bits = pattern.get_possibilities()
else:
bits = normalize(p_pattern)

> And you now can't pass secondary pattern into django libs that are not
> aware of your feature.

Not sure what you're talking about here. I can't see how my changes
will break anything, unless a library is using a URLPattern that
doesn't extend RegexURLPattern. And again, as above, a small fix can
solve that.

Just so I'm clear, this is a *backwards-compatible* change. Nothing
should break if the above change is incorporated into the original
proposal.

> So, many-to-many relation between urlpatterns entry and view name only
> complicates things.

I am not suggesting a many-to-many relationship between urlpatterns
and view names. Each urlpattern can still only match 1 view name. It
is a many-to-one relationship. Not that this case already exists if
you use ? in a regexp in a URL pattern.

> On Fri, Nov 12, 2010 at 1:56 PM, burc...@gmail.com  wrote:
>> Hi Sam,
>>
>> what's the problem with regexp = '^newitems'+SUFFIX+'$' where
>> SUFFIX='(/|\.xml|\.json)' ?
>>
>> And if you need more shortcuts, there are surlex (
>> http://codysoyland.com/2009/sep/6/introduction-surlex/ ) and
>> alternatives.
>>
>> On Fri, Nov 12, 2010 at 11:25 AM, Sam Lai  wrote:
>>> [First timer participating in the Django dev process, so apologies if
>>> I have missed some protocol etc.]
>>>
>>> First up, this is not about adding an alternate URL
>>> resolution/reversal method to the core; I've noticed a fair bit of
>>> resistance to that.
>>>
>>> PROBLEM:
>>> I want to make my website available via an API with URLs like this -
>>> http://example.com/newitems/ => returns HTML
>>> http://example.com/newitems.xml => returns XML
>>> http://example.com/newitems.json => returns JSON.
>>>
>>> To represent this in urls.py, I have to either:
>>> a) write a separate url entry for each one
>>> b) write 2 url entries, one for newitems/ and another for
>>> newitems\.(?P\w+). This is the better option, but still
>>> annoying. Plus it forces my view to validate whether or not the format
>>> value is acceptable (e.g. is either xml or json).
>>>
>>> I have to do this for every URL I wish to make available via an API,
>>> bloating out my urls.py file. (I'm aware I can use the HTTP-ACCEPT
>>> header instead, but there is a need to be able to force the response
>>> format in the URL for certain uses.)
>>>
>>> MY DESIRED SOLUTION:
>>> Subclass RegexURLPattern, and override the resolve method so that it
>>> will replace a placeholder, e.g. (?#format), with the appropriate
>>> regexps (/|\.xml|\.json). Effectively it will perform something
>>> similar to this regexp instead -
>>> ^newitems(/|(?P(\.xml|\.json))) where the list of accepted
>>> formats will be defined in settings. This subclass will be returned
>>> using an alternate url(...) call, e.g. murl(...).
>>>
>>> So my urls.py will look like -
>>> urlpatterns = patterns('project.app.views',
>>>    murl(r'^/(?P\d+)(?#format)$', AppView.as_view(),
>>> name='app_view1

Re: making URL resolving/reversing gradually more flexible

[Sam Lai]

On 12 November 2010 23:14, burc...@gmail.com  wrote:
> First I thought you're going to return some instance with reverse
> which has get_possibilities.
> And you just want RegexURLPattern to register 3 usual regexes for you
> instead of one.

Effectively. I should've been more concise when writing the initial email :)

> Could you please create a patch now -- at least someone will use it.

Will do. It'll help iron out any possible quirks in my proposal too.

> Maybe you also thought of a patch for this specific case of simple
> reversible ORs in the urls?
> Examples: (a|b|c) and (?Pa|b|c)

I have, and I'm happy to have a look at fixing that, but it'll
definitely not make release 1.3. I'm not sure how open the core devs
are to non-core devs poking around in core parts of the framework
though.

-- 
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: settings.py should have way to hide key/values even when debug set True

[Sam Lai]

On 1 February 2011 17:26, Alex Gaynor  wrote:



> How, precisely, would one apply a decorator to an assignment statement?
>  Unless there has been some change to Python's grammar I'm not aware of,
> decorators can only be used on function and class definitions.

You could wrap the value on the right of the assignment operator with
a decorator I think. For some reason I don't feel comfortable with
this though.

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

-- 
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: 5-for-1?

[Sam Bull]

Hey,

I've got a reusable app that offers the functionality you're looking for, I 
think. I just commented on the ticket, so I hope this doesn't count as 
double-posting, but you can check it out here: 
https://github.com/trapeze/fancy_tag

It's got unit tests, keyword argument support (like the new with tag), *args 
support, **kwargs support, and support for the "with " pattern.

Is this something I should convert into a patch?

Sam

On 2011-06-18, at 5:29 AM, Jannis Leidel wrote:

> On 18.06.2011, at 03:38, Stephen Burrows wrote:
> 
>> I would love it if someone could look at 13956 [1]
>> 
>> [1] http://code.djangoproject.com/ticket/13956
> 
> I'd like to repeat my concerns from the ticket that it seems odd to extend the
> helper tags with support for *args but leaving out **kwargs. If the API of
> those tags should be extended with concepts from Python we shouldn't do this
> only partially.
> 
> Fortunately there is a good (new) convention in Django how to write kwarg
> style template parameters, thanks to Chris Beaven's with/include tag refactor
> (``{% with arg1=1 arg2=2 %}{{ arg1 }}: {{ args2 }}{% endwith %}``), which
> could also be used for the tag helpers.
> 
> Jannis
> 
>> On Jun 7, 12:24 pm, Carl Meyer  wrote:
>>> Hi Stephen,
>>> 
>>> On 06/07/2011 02:37 AM, Stephen Burrows wrote:
>>> 
>>>> Hi - is the 5-for-1 deal still active on ticket reviews? [1]
>>>> If so, I've reviewed the following tickets:
>>> 
>>>> 3624
>>>> 16152
>>>> 16157
>>>> 16158
>>>> 16166
>>> 
>>>> And would love it if someone could have a look at ticket 14082 [2].
>>> 
>>>> If not, ah well. :-)
>>> 
>>> Thanks for the ticket reviews, and your work on the patch. Committed in
>>> r16334 [1]
>>> 
>>> Carl
>>> 
>>>  [1]https://code.djangoproject.com/changeset/16334
>> 
>> -- 
>> 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.
> 

-- 
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: Timezone-aware storage of DateTime

[Sam Bull]

On 2011-06-02, at 12:34 AM, Stephen Burrows wrote:

> Django actually already adds support for some capabilities to certain
> database backends, if I'm not mistaken - such as cascades through GFKs
> on delete.
> 
> In terms of time zones, could django "assume"/ensure that the datetime
> stored in the backend is UTC, then handle the conversion to the local
> timezone itself?

Isn't this a viable solution? It's the universal, cross-timezone-friendly 
datetime objects that we care about, not the timezones they were in, right?

- If the DB supports timezone-aware datetime fields, just pass the datetime 
object through as is.

- If the DB doesn't support timezone-aware datetime fields, convert to UTC and 
store the datetime as UTC

  - If the datetime has tz info, convert the time to UTC using that

  - If the datetime doesn't have tz info, convert using the default timezone 
specified in the settings

When retrieving the data from a non-timezone-aware db, convert them from UTC to 
the project's timezone.

Sam

-- 
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: Timezone-aware storage of DateTime

[Sam Bull]

I figured that for most cases you wouldn't actually care what the timezone was. 
You would either always be displaying things in a timezone relative to the 
user, or you'd use some other external information (ex. coordinates of person 
or thing attached to the datetime object) to derive a contextually appropriate 
timezone.

For cases where you do want to retain the timezone, how about allowing the 
TZ-aware DateTime field to store the TZ data to an optional secondary field? 
That field could be a regular CharField. It wouldn't be needed for any of the 
date-based sorting or filtering. There's precedent for this sort of behaviour 
with the GenericForeignKey, and I think it would be fine, especially if the 
secondary field was optional.

What do you think?

Sam

On 2011-06-28, at 9:26 AM, Stephen Burrows wrote:

> I agree that it would be nice to be able to store tz-aware datetimes -
> but if django were going to do so, it ought to store the datetimes
> with the timezone information intact, rather than converting
> everything to the project's timezone. So, if a conversion to UTC were
> to take place, there would need to be a separate field in the database
> to store the timezone.
> 
> On Jun 27, 3:12 pm, Sam Bull  wrote:
>> On 2011-06-02, at 12:34 AM, Stephen Burrows wrote:
>> 
>>> Django actually already adds support for some capabilities to certain
>>> database backends, if I'm not mistaken - such as cascades through GFKs
>>> on delete.
>> 
>>> In terms of time zones, could django "assume"/ensure that the datetime
>>> stored in the backend is UTC, then handle the conversion to the local
>>> timezone itself?
>> 
>> Isn't this a viable solution? It's the universal, cross-timezone-friendly 
>> datetime objects that we care about, not the timezones they were in, right?
>> 
>> - If the DB supports timezone-aware datetime fields, just pass the datetime 
>> object through as is.
>> 
>> - If the DB doesn't support timezone-aware datetime fields, convert to UTC 
>> and store the datetime as UTC
>> 
>>   - If the datetime has tz info, convert the time to UTC using that
>> 
>>   - If the datetime doesn't have tz info, convert using the default timezone 
>> specified in the settings
>> 
>> When retrieving the data from a non-timezone-aware db, convert them from UTC 
>> to the project's timezone.
>> 
>> Sam
> 
> -- 
> 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: Timezone-aware storage of DateTime

[Sam Bull]

On 2011-06-29, at 5:27 AM, Daniel Swarbrick wrote:

> Storing the TZ in a separate field is going to get pretty nasty for
> sorting as well, as the query will have to somehow concatenate or
> compute together the two fields before applying the sorting algorithm.

I don't see why. If the datetime data is all normalized to UTC then the 
datetime column can be used for sorting on its own and the tz data can be 
ignored.

> I think the best way to handle multi-TZ timestamps is the way that
> Unix and other multi-user, multi-timezone OSes have been doing it for
> decades (mostly wrt to filesystems) - respect the TZ of the client
> inputting the data, normalize to a common TZ (usually UTC) and store
> as such. Perform all sorting and timestamp comparison/arithmetic in
> that single, normalized TZ. Upon output, render the value in the
> client's TZ.
> 
> ...and that is essentially what Postgres does.

I think we agree here. I'm suggesting the separate tz field as a nice-to-have. 
I think Django has everything it needs to make DateTimeField timezone-aware. It 
sounds like its already doing the right thing with postgresql. It just needs a 
graceful fallback for other DBs that don't do timezones as well.

Here's my proposal for adding timezone support to DateTimeField:

1. Assume timezone-less datetimes are in the timezone specified in settings and 
convert them to timezone-aware datetimes
2. If the db bridge doesn't understand timezone data, normalize the datetimes 
to UTC before sending them through
3. When retrieving datetimes from the db, assume they are in UTC if they don't 
come with a timezone already attached
4. Convert the datetimes to the timezone specified in settings

Bonus:
5. Allow the user to specify a field in the DateTimeField declaration to be 
used for storing timezone data
6. When storing, extract the timezone and record it in this field
7. When retrieving, convert the datetime from UTC to the timezone specified in 
the field

I could put together a patch for this solution if you folks think it looks 
promising.

Sam

-- 
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: Reversing translated urls in templates

[Sam Bull]

I like this quite a bit. It's clean, and it allows for a common i18n pattern 
where the footer contains a translation link for each supported language, and 
the language names are localized to themselves (i.e. "Español | Français | 
Deutsch").

Sam

On 2011-07-04, at 5:23 AM, brocaar wrote:

> On Monday, July 4, 2011 10:04:10 AM UTC+2, Jannis Leidel wrote:
> Agreed, what about just "language", e.g.:
> 
> {% language lang_code %}
> {% trans "Register account" %}: {% url account:register %}
> {% endlanguage %}
> 
> 
> 
> I agree too that the tag name in my example is quite ugly, it was only to 
> clarify my idea ;) Just "language" sounds perfect!
> 
> Orne  
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/django-developers/-/huy6SEXMIBkJ.
> 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: Decision for ticket #6362 - Remove blank spaces with strip when validating the data

[Sam Lai]

On 5 July 2011 02:20, Jacob Kaplan-Moss  wrote:
> Doesn't do anything to change my point, though: a framework can't go
> about stripping user input. That's a user-code decision. If Django
> strips out data I wanted, there's nothing I can do to get it back.

I concur. The consensus seems to be shifting towards a 'strip' flag
though (defaulting to false), and I'm +1 on that. That would make it
explicit, minimise repetitive boilerplate code and also make it less
likely to accidentally forget to strip a field somewhere in the
process.

Maybe a revisit to this related ticket is in order?
https://code.djangoproject.com/ticket/4960

> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-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: We're a group of students at UC Berkeley looking to contribute to Django

[Sam Whitlock]

I am in the same group as Jamin. Here is some more info about the class.

Berkeley has these classes called DeCal classes. They are student-taught 
classes about all sorts of things (Starcraft to Wheelchair Basketball). More 
info at the official site .

We are enrolled in the Open Source 
Softwaredecal. It is meant to ease students 
into contributing to open source 
software. Personally, I use so much of it that I feel compelled to 'pay' for 
it with my time, not to mention all the other perks (getting better at 
coding).

The rough requirements for the course are attendance and a contribution 
(that hopefully gets accepted) to a reasonably active open source project.

There are 4 of us in the group, all undergrads. Jamin seems to be the only 
one with web framework experience, and I have done a lot of back end stuff, 
but we're all committed to working on a meaningful feature.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/eUi9zAv7lbQJ.
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: ImageField performance

[Sam Tregar]

On Fri, Jul 17, 2009 at 4:27 PM, Javier Guerra  wrote:

>
> On Fri, Jul 17, 2009 at 8:10 PM, Fredz./
> wrote:
> > I might be loading the image in memory, but it sure seems 1000x faster
> > when you reach images the size of 10 megs and more.
>
> this assumes that it would have to read the whole file anyway.  some
> formats have the size info in a header on the first few KBs.  i
> believe on those cases PIL can give the info as soon as possible.
>

Which does invite the question - what format is this monster 35MB image in?
Maybe if you choose a smarter format the size info will be in the header!

-sam

--~--~-~--~~~---~--~~
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: Unit tests error out with WinError 10013 in my Windows 7 machine with Python 3.3.2

[Sam Lai]

Do you have anything running on port 8081 (running netstat will tell you)?

I just ran Django's test suite on my machine (Windows 7, Python
3.3.2), from the trunk cloned an hour ago, and it completed mostly
without an issue (there's a UnicodeDecodeError but that's likely
because it's printing a character to stdout that isn't supported by
the Windows console codepage).

Can you move this discussion over to django-users (just post your
reply with the rest of the email chain over there)? I don't think it's
an issue with Django itself.

On 25 October 2013 02:46, Antony J  wrote:
> Hi,
>
> Good morning.
>
> Your help is needed:
>
> I am relatively new to Django. After developing a Django app, I am trying to
> write my first patch for Django.
>
> I checked out Django from github: VERSION = (1, 7, 0, 'alpha', 0).
>
> When I run the unit tests with the command "python runtests.py", I get 6
> errors and 2 failures.
> But in the Django Jenkins server, the builds are successful.
>
> The error is: OSError: [WinError 10013] An attempt was made to access a
> socket in a way forbidden by its access permissions
>
> I tried the following:
>
> 1) Ran a command prompt as administrator.
> 2) Added python.exe to firewall inbound rules.
> 3) There are some suggestions for this error in stack overflow:
> http://stackoverflow.com/questions/2778840/socket-error-errno-10013-an-attempt-was-made-to-access-a-socket-in-a-way-forb
> http://stackoverflow.com/questions/16908529/python-3-x-socket-error-errno-10013-an-attempt-was-made-to-access-a-socket-in
>
> The first suggestion seem require code changes in Django, and the second
> suggestion seem require code changes in Python http/server.py.
>
> But these suggestions do not seem right to me.
>
> I am running a Windows 7 Enterprise OS (version 6.1) with Python 3.3.2
> 32-bit version.
>
> Is this a supported config to build Django?
> Have any of you faced this error?
>
> I appreciate any help that you can provide to solve the errors and failures.
> Please find the error and failure tracebacks in the text file attached
> herewith.
>
> Thanks,
> Antony
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/8f23755c-be2b-4a24-a00e-aaaead7f78ab%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CABxbXqVcPxX6e5jrevAiPXoMJbD4%2BPv6is%3DFVtDjXjDFwynrYg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: 1.6 reverse() escapes unreserved chars in path components

[Sam Lai]

The relevant commit and issue -

https://github.com/django/django/commit/31b5275235bac150a54059db0288a19b9e0516c7
https://code.djangoproject.com/ticket/13260

On 1 March 2014 17:26, Erik van Zijst  wrote:
> Django's django.core.urlresolvers.reverse() seems to have changed its
> behavior in 1.6. It now runs the arguments through quote(), without
> specifying the safe characters for path components. As a result:
>
> on 1.4.10:
> In [2]: reverse('test', args=['foo:bar'])
> 
Out[2]: '/foo:bar'
>
> but on 1.6.2:
> In [2]: reverse('test', args=['foo:bar'])
> Out[2]: '/foo%3Abar'
>
> It would seem to me that this is a regression, as ":@-._~!$&'()*+,;=" are
> all allowed unescaped in path segments AFAIK.
>
> Cheers,
> Erik
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/064ba557-a722-484f-93bf-423048b51b14%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CABxbXqXKhcKFPS8ufmYDGmgHU_QjBuFUb%3DaFXk3FROJyzAJw5A%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: 1.6 reverse() escapes unreserved chars in path components

[Sam Lai]

I wasn't expressing an opinion either way; just adding the relevant
commit to the conversation.

Looks like RFC 3986 is the relevant RFC describing the permitted
characters in URIs, specifically section 2.2 and 2.3 -
http://tools.ietf.org/html/rfc3986#section-2.2

It seems like the fix makes it easier for 90% of the uses, but
explicitly blocks the other 10% (i.e. uses involving the use of
'reserved' characters as permitted by the RFC).

The relevant django-developers discussion is here -
https://groups.google.com/forum/#!searchin/django-developers/13260/django-developers/Gofq5y40mYA/v_4yjrBItWkJ
The final post addresses this issue, but doesn't seem to have been
taken into account when the patch was accepted.

On 2 March 2014 12:28, Erik van Zijst  wrote:
> On Sat, Mar 1, 2014 at 2:41 PM, Sam Lai  wrote:
>> The relevant commit and issue -
>>
>> https://github.com/django/django/commit/31b5275235bac150a54059db0288a19b9e0516c7
>> https://code.djangoproject.com/ticket/13260
>
> Yes I saw that, but I'm confused. I thought these characters are
> allowed unescaped in path segments.
>
>
>> On 1 March 2014 17:26, Erik van Zijst  wrote:
>>> Django's django.core.urlresolvers.reverse() seems to have changed its
>>> behavior in 1.6. It now runs the arguments through quote(), without
>>> specifying the safe characters for path components. As a result:
>>>
>>> on 1.4.10:
>>> In [2]: reverse('test', args=['foo:bar'])
>>> Out[2]: '/foo:bar'
>>>
>>> but on 1.6.2:
>>> In [2]: reverse('test', args=['foo:bar'])
>>> Out[2]: '/foo%3Abar'
>>>
>>> It would seem to me that this is a regression, as ":@-._~!$&'()*+,;=" are
>>> all allowed unescaped in path segments AFAIK.
>>>
>>> Cheers,
>>> Erik
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Django developers" 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/064ba557-a722-484f-93bf-423048b51b14%40googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>> --
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Django developers" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/django-developers/ZLGk7T4mJuw/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/CABxbXqXKhcKFPS8ufmYDGmgHU_QjBuFUb%3DaFXk3FROJyzAJw5A%40mail.gmail.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" 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/CA%2B69USsj%2BuWHJJfw7-Fr8SFq34Xq0TLThR3Bq2t3r66K9oAFrw%40mail.gmail.com.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CABxbXqU903Ry9x04%2Bu%2B%2BVaQKnrHH2e1mLwXkjr2YenhYku%2Bsng%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: requiring login to perform Trac actions?

[Sam Lai]

On 4 March 2014 10:44, Russell Keith-Magee  wrote:
>> If you believe the "create an account" barrier is a problem, do you think
>> adding something like GitHub auth to Trac would lower the barrier to an
>> acceptable level?
>
>
> This sounds like a reasonable option to me. Any halfway serious potential
> contributor should have a Github account, and it matches Django's own
> toolchain. The oAuth process is pretty smooth, so the problem set is down to
> "users who are genuinely new to software".

I've worked in a few industries where developers have never heard of
git, even if they spend their whole day on a Linux box and are
definitely not 'new to software'. That said, it is possible that the
subset who use Django are probably likely to be familiar with GitHub
given that Django is a web framework. Maybe some explanatory text at
the login screen would mitigate the issue.

Also, will GitHub oAuth actually solve the sporadic login issues?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CABxbXqU9PmCdp%3D4EOZoEJD4C4SP5j45srhGoxJfR2ZRqe0HtLQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Proposal: The 'use' template tag, a cross between 'include' and 'extends'.

[Sam Willis]

Hi All,

I would like to propose a new template tag to be included in Django, it is 
sort of a cross between 'include' and 'extends'. You can find an 
implementation here: https://gist.github.com/samwillis/af3992f69c2597a16252

The main use case for this tag is being able to create reusable 
'components' for rendering a website. Say for example a page header, a 
panel with headers and footers, or a modal window (as seen in the Bootstrap 
framework). Rather than needing to repeat the html everywhere you need it 
and having to search out all occurrences to make a change to the structure 
you can create a simple template and include it.

To some extent this can currently be done with either an included template 
using the '{% include "template.html" with var="value" %}' syntax or using 
a custom template tag. However, the former isn't suitable for changing 
whole blocks in the include template, and the latter can be overkill and 
may not be suitable for a designer with little knowledge of Python and the 
Django Template API.

The 'use' tag loads a template and renders it with the current context 
similar to the 'include' tag. You can pass additional context using keyword 
arguments as well as override blocks in the included template.

Example (simple) template:


{% block heading %}{% endblock %}


Example 'use' tag use with the above template:

{% use "page_header.html" %}
{% block heading %}Some Title{% endblock %}
{% enduse %}

{% use "page_header.html" with extra_class="large" %}
{% block heading %}Some Title{% endblock %}
{% enduse %}

As with 'include' use the 'only' argument to exclude the current context 
when rendering the included template:

{% use "page_header.html" only %}
{% block heading %}Some Title{% endblock %}
{% enduse %}

{% use "page_header.html" with extra_class="large" only %}
{% block heading %}Some Title{% endblock %}
{% enduse %}

The included template receives an additional context variable called 
'used_blocks' which is a Dict indicating which blocks were overridden in 
the 'use' tag. Using this you can conditionally show content around the 
block. For example, if you had this template for generating a page heading:


{% block heading %}{% endblock %}
{% if used_blocks.sub_heading %}
{% block sub_heading %}{% endblock %}
{% endif %}


and included it using:

{% use "page_header.html" %}
{% block heading %}My Page Title{% endblock %}
{% enduse %}

it would exclude the '' tags from the empty subheading.

Finally, as syntactic sugar if you are just overriding a single block you 
can express it as:

{% use "page_header.html" block heading %}
My Page Title
{% enduse %}

These example are a little simple, but this could be incredibly useful for 
more complex components such a modal windows.

I have made a first pass at an implementation here: 
https://gist.github.com/samwillis/af3992f69c2597a16252.

Although I have implemented this with the 'use' word, there may be a better 
word. I considered 'embed' but thought 'use' was a little cleaner

Thanks,
Sam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/0104008b-bb58-4730-a0dd-43c2875fa1b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: The 'use' template tag, a cross between 'include' and 'extends'.

[Sam Willis]

If this was to be an addition to 'include' it would result in it having an 
optional closing tag, that seems a little confusing and you would need an 
argument to flag that there are blocks to override (and parse until the 
'endinclude').

The advantage over Jonathans 'decorate' tag is that you can override any 
and multiple blocks in the included template.



On Wednesday, September 3, 2014 5:46:24 PM UTC+1, Jonathan Slenders wrote:
>
> From 2011: 
> https://github.com/vikingco/django-template-tags/blob/master/src/django_template_tags/templatetags/decorate.py
>
> My proposal was refused back then, but I'll be very happy if something 
> similar would make it. :)
>
>
>
> Le mercredi 3 septembre 2014 18:42:44 UTC+2, Jonathan Slenders a écrit :
>>
>> It's not similar. This implements the "decorator" pattern. Something that 
>> I've been proposing years ago.
>>
>>
>>
>> Le mercredi 3 septembre 2014 18:24:17 UTC+2, Ian a écrit :
>>>
>>> On Wed, Sep 3, 2014 at 10:10 AM, Sam Willis  wrote: 
>>> > Although I have implemented this with the 'use' word, there may be a 
>>> better 
>>> > word. I considered 'embed' but thought 'use' was a little cleaner 
>>>
>>> Since it's so similar to 'include', is there a reason not to just add 
>>> the new functionality to the existing tag? 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/5380864a-642d-44f6-bd58-31c555a517a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: The 'use' template tag, a cross between 'include' and 'extends'.

[Sam Willis]

Curtis,

You are welcome to include it in your project and I'm happy to help out. 
Depending on what happens here I may still release it as a simple 
standalone app though.

I do think this is the kind of thing that would do best in core though as 
it would ensure that there was a standardised patten for creating these 
reusable template components.


Marc,

I am happy to have a look around (and have already to some extent when 
developing this) and put together a review of the various existing options. 
This is my first foray into contributing to Django and so I am keep to help 
in any way.

Does anyone know of anything particular I should be looking at?



On Thursday, September 4, 2014 2:06:15 PM UTC+1, Marc Tamlyn wrote:
>
> I would like to see someone do a review of the various third party 
> implementations of concepts like this, I think there's a place in core for 
> some variant, it's just working out which one the "right" one is.
>
> The other issue with adding new tags to core (especially with "common" 
> names) is name clashes with third party code. This shouldn't be too 
> significant though if we have enough use.
>
>
> On 4 September 2014 12:09, Josh Smeaton 
> > wrote:
>
>> I really like this idea, and have wanted something similar every time I 
>> start a new project and begin building out the main template. I think 
>> including this (or something like this) in core is a great idea. Just 
>> because it *can* be implemented in 3rd party code, doesn't mean it has to 
>> be.
>>
>>
>> On Thursday, 4 September 2014 02:10:33 UTC+10, Sam Willis wrote:
>>>
>>>  Hi All,
>>>
>>> I would like to propose a new template tag to be included in Django, it 
>>> is sort of a cross between 'include' and 'extends'. You can find an 
>>> implementation here: https://gist.github.com/
>>> samwillis/af3992f69c2597a16252
>>>
>>> The main use case for this tag is being able to create reusable 
>>> 'components' for rendering a website. Say for example a page header, a 
>>> panel with headers and footers, or a modal window (as seen in the Bootstrap 
>>> framework). Rather than needing to repeat the html everywhere you need it 
>>> and having to search out all occurrences to make a change to the structure 
>>> you can create a simple template and include it.
>>>
>>> To some extent this can currently be done with either an included 
>>> template using the '{% include "template.html" with var="value" %}' syntax 
>>> or using a custom template tag. However, the former isn't suitable for 
>>> changing whole blocks in the include template, and the latter can be 
>>> overkill and may not be suitable for a designer with little knowledge of 
>>> Python and the Django Template API.
>>>
>>> The 'use' tag loads a template and renders it with the current context 
>>> similar to the 'include' tag. You can pass additional context using keyword 
>>> arguments as well as override blocks in the included template.
>>>
>>> Example (simple) template:
>>>
>>> 
>>> {% block heading %}{% endblock %}
>>> 
>>>
>>> Example 'use' tag use with the above template:
>>>
>>> {% use "page_header.html" %}
>>> {% block heading %}Some Title{% endblock %}
>>> {% enduse %}
>>>
>>> {% use "page_header.html" with extra_class="large" %}
>>> {% block heading %}Some Title{% endblock %}
>>> {% enduse %}
>>>
>>> As with 'include' use the 'only' argument to exclude the current context 
>>> when rendering the included template:
>>>
>>> {% use "page_header.html" only %}
>>> {% block heading %}Some Title{% endblock %}
>>> {% enduse %}
>>>
>>> {% use "page_header.html" with extra_class="large" only %}
>>> {% block heading %}Some Title{% endblock %}
>>> {% enduse %}
>>>
>>> The included template receives an additional context variable called 
>>> 'used_blocks' which is a Dict indicating which blocks were overridden in 
>>> the 'use' tag. Using this you can conditionally show content around the 
>>> block. For example, if you had this template for generating a page heading:
>>>
>>> 
>>> {% block heading %}{% endblock %}
>>> {% if used_blocks.sub_heading %}
>>>

Re: Proposal: The 'use' template tag, a cross between 'include' and 'extends'.

[Sam Willis]

Hi again,

One thing that I wasn't happy with in the implementation I posted yesterday 
was that you could not override templates included using 'use' in another 
child template. Effectively all blocks inside the 'use' tag and its 
included template where invisible outside of it. This needed to be the case 
so that you didn't get block names clashing with each other and could use 
the 'use' tag to include the same template with the same blocks overridden 
multiple times in one template

One potential solution to this is to enable blocks to have namespaces, so 
for example if you had the template:

# page_heading.html

{% block heading %}My Heading{% endblock %}
{% block sub_heading %}My Subheading{% endblock %}


and included it a template such as (note the 'ns page_heading'):

# base_page.html
...
{% use 'page_heading.html' ns page_heading %}
{% block heading %}Basic Page Heading{% endblock %}
{% enduse %}
...

You could then override the 'heading' block in a child template of 
'base_page.html' by doing:

# actual_page.html
{% extends 'base_page.html' %}
{% block page_heading.heading %}Basic Page Heading{% endblock %}

I have updated my implementation to support this here: 
https://gist.github.com/samwillis/af3992f69c2597a16252

It requires that the BlockContext supports namespaces, in my implementation 
there is NsBlockContext which is patched in when required but if this was 
accepted into core then NsBlockContext would replace BlockContext.

This is (almost) fully backwards compatible with existing code as blocks 
already named with periods will just end up in a namespace but continue to 
function fully. The only exception is if you have blocks named both 
'global.block_name' and 'block_name' as these would now address the same 
block. We could give the global namespace a more obscure name (such as 
'__global__') to prevent this but it would make the trick below more clunky.

One interesting use for the 'use' tag with this addition is breaking up 
more complex templates into multiple files. While researching various 
options before developing this I found allot of people discovering that you 
couldn't override a block inside an 'include'ed template. With this 'use' 
tag you would be able to do this, for example you could have base templates 
like this:

# base.html


{% use 'head.html' ns global %}{% enduse %}


 ...



# head.html
{% block title %}{% endblock %}

and the page template:

# actual_page.html
{% extends 'base.html' %}
{% block title %}My Page Title{% endblock %}

If we switched the 'use' tag to use a namespace other than global:

{% use 'head.html' ns html_head %}{% enduse %}

The page template would then be:

# actual_page.html
{% extends 'base.html' %}
{% block html_head.title %}My Page Title{% endblock %}

I think this will provide very useful in structuring complex templates.

Maybe with this functionality the tag should be called 'embed'?

What do you think?


Sam


On Thursday, September 4, 2014 5:28:34 PM UTC+1, Sam Willis wrote:
>
> Curtis,
>
> You are welcome to include it in your project and I'm happy to help out. 
> Depending on what happens here I may still release it as a simple 
> standalone app though.
>
> I do think this is the kind of thing that would do best in core though as 
> it would ensure that there was a standardised patten for creating these 
> reusable template components.
>
>
> Marc,
>
> I am happy to have a look around (and have already to some extent when 
> developing this) and put together a review of the various existing options. 
> This is my first foray into contributing to Django and so I am keep to help 
> in any way.
>
> Does anyone know of anything particular I should be looking at?
>
>
>
> On Thursday, September 4, 2014 2:06:15 PM UTC+1, Marc Tamlyn wrote:
>>
>> I would like to see someone do a review of the various third party 
>> implementations of concepts like this, I think there's a place in core for 
>> some variant, it's just working out which one the "right" one is.
>>
>> The other issue with adding new tags to core (especially with "common" 
>> names) is name clashes with third party code. This shouldn't be too 
>> significant though if we have enough use.
>>
>>
>> On 4 September 2014 12:09, Josh Smeaton  wrote:
>>
>>> I really like this idea, and have wanted something similar every time I 
>>> start a new project and begin building out the main template. I think 
>>> including this (or something like this) in core is a great idea. Just 
>>> because it *can* be implemented in 3rd party code, d

Re: The greatest proposal yet: rename this damn group

[Sam Lai]

FYI, this comes up again and again here, but the core devs have shot
it down repeatedly. Here's one from last year -
https://groups.google.com/d/msg/django-developers/yJYkZEGUzVk/u5xiIzg_TtMJ

For the record though, I think renaming it to something less ambiguous
is a good idea.

On 5 September 2014 12:57, Robert Grant  wrote:
> Yeah I like that one.
>
> Or django-verlords.
>
> On Friday, 5 September 2014 13:36:23 UTC+2, Piotr Buliński wrote:
>>
>> +1
>> My proposition: django-contributors
>> That’s pretty self-explanatory, confusion-avoiding name.
>>
>> Cheers,
>> Piotr
>>
>> On 05 Sep 2014, at 09:58, Robert Grant  wrote:
>>
>> > I am one of the happy few who read the line about what this group is for
>> > before I started posting.
>> >
>> > However, that line, and the endless supply of people who think this is
>> > for Django developers (see also: Java developers are generally considered 
>> > to
>> > be people* who develop in Java, not who develop Java), might be symptoms of
>> > the fact that this group has a funny name for something that is both
>> > developed and developed in.
>> >
>> > Can we rename it? :) Some semi-serious suggestions (because I can't
>> > think of an obvious alternative) :
>> >
>> > Django Masters
>> > Django Private
>> > Django Debate
>> > Django Internals
>> > Aymeric And Friends
>> >
>> >
>> >
>> >
>> >
>> > * Yes, they're still people.
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Django developers" 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 http://groups.google.com/group/django-developers.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msgid/django-developers/fd27a285-be01-417f-ab4b-4026d7221239%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" 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/8e2ff58a-a2d0-412c-8d95-4930bd0783db%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" 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/CABxbXqUksvOAbZyuqDHsQ9c185iyCHLz58T4XwAVY2iW30Jr2A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: The 'use' template tag, a cross between 'include' and 'extends'.

[Sam Willis]

Hi Jonathan,

I agree it may be one step to far but I thought it may be worth discussing 
as it opens up an interesting option for overcoming some of the 
shortcomings of the current 'include' tag. It actually isn't to hard to 
implement, I think my code should be pretty close to what would end up in 
use if it is accepted. The alternative to the namespaces could be adding a 
'public' option to the tag that makes the blocks inside available to 
overwrite?

 I am particularly keen on being able to override multiple blocks, I think 
this is a good example of what could be constructed with this tag. 
Bootstrap has a Modal component and the code below uses its markup as an 
example::

# modal.html

  

  {% if used_block.header %}

  ×Close
  {% block title 
%}{% endblock %}

  {% endif %}
  {% if used_block.body %}

  {% block body %}{% endblock %}

  {% endif %}
  {% if used_block.footer %}

  {% block footer %}{% endblock %}

  {% endif %}

  


This could then be included in a page in the following ways:

# my_page.html

{% use 'modal.html' with modal_id='settings_modal' %}
  {% block title %}
Your Settings
  {% endblock %}
  {% block body %}
... A settings form? ...
  {% endblock %}
  {% block footer %}
Close

Save changes
  {% endblock %}
{% enduse %}


{% use 'modal.html' with extra_class='large' modal_id='annother_modal' %}
  {% block title %}
Another Modal
  {% endblock %}
  {% block body %}
This one has no footer/
  {% endblock %}
{% enduse %}


{% use 'modal.html' with extra_class='small' block body %}
  This one doesn't even have a title, and as we are just overriding a 
single block we loose the block tags.
{% enduse %}

In the template we are using the 'used_blocks' context variable to decide 
when to include the div's that wrap the head, body and footer of the modal. 
We are also using the extra context variables assigned by the use tag to 
choose if its a normal, large or small modal and give it an id.

This can obviously already be implemented with a hierarchy of extended 
templates but I think this tag creates a very clean way of structuring 
these components that doesn't require making custom template tags or lots 
of template files.


Sam




On Friday, September 5, 2014 2:55:28 PM UTC+1, Jonathan Slenders wrote:
>
> There I think you are going one step too far.
>
> I think people should not be able to override blocks inside an included 
> template in a "use"-block. That's one level too deep. It's confusing and 
> you have other solutions for that.
> In the template that you "use", you could put a {% block %} around the {% 
> include %} if you want to be able to replace that. It's a little more work, 
> but in my opinion, it's not worth introducing the concept of name spaces.
>
>
>
> Aside from that, there's one example that I would like to share, why we 
> would need something like this.
> Ofter we end up writing code like this:
>
> {% include "start_table.html" %}
> {% include "content.html" %}
> {% endclude "end_table.html" %}
>
>
> "start_table.html" would contain:
> .."
>
> "end_table.html" would contain:
> 
>
> Now open any of the "start/end_table.html" files in an editor, and the 
> editor will not be able to find the matching tags.
> On the other hand, if you can have:
>
> {% use "table.html" %}
> {% include "content.html" %}
> {% enduse %}
>
>
> Then we have the HTLM open and close tags in the same file.
> (I agree that in this specific example, there is an alternative: use 
> extends in the included template. But there are many cases where you don't 
> want that, because you need e.g. the decorated and non-decorated version of 
> the include.)
>
> Now, whether or not to allow overriding multiple blocks of the "used" 
> template. I don't know. It's technically also possible to support both 
> cases. (E.g. replace the content of the "content" block if no blocks are 
> defined between "use" and "enduse". Otherwise, find matching block namess, 
> like with {% extends %}.)
>
>
>
>
>
> Le jeudi 4 septembre 2014 19:11:57 UTC+2, Sam Willis a écrit :
>>
>> Hi again,
>>
>> One thing that I wasn't happy with in the implementation I posted 
>> yesterday was that you could not override templates included using 'use' in 
>> another child template. Effectively all blocks inside the 'use' tag and its 
>> included template where 

Re: Django security releases issued: 3.0.1, 2.2.9, and 1.11.27

[Sam Willis]

Hi,

It looks to me like this has introduced a slight behaviour difference with 
1.11 on python 2.7 than on 3.x:

https://github.com/django/django/commit/f4cff43bf921fcea6a29b726eb66767f67753fa2#diff-e840e362abe9e625eee52d91897400bdR36

The release notes don't indicate what the difference in behaviour is 
between python 2 and 3.

I'm trying to follow the change and test cases but it looks like if you 
have two users 'm...@example.org' and 'mık...@example.org' (which is highly 
unlikely anyway to happen legitimately) neither can reset their password 
anymore on py2?

See: 
 
https://github.com/django/django/commit/f4cff43bf921fcea6a29b726eb66767f67753fa2#diff-d4ef44f66fdc7127c6178eee0fdcaf57R697
 

I'm guessing this was found after the similar GitHub vulnerability was 
found?

Thanks for the hard work!

On Wednesday, December 18, 2019 at 9:23:35 AM UTC, Mariusz Felisiak wrote:
>
> Details are available on the Django project weblog: 
>
> https://www.djangoproject.com/weblog/2019/dec/18/security-releases/ 
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5cde448c-7631-472f-857f-168bd872fe3e%40googlegroups.com.

Re: Deprecating logout via GET

[Sam Willis]

Why not have the logout link take the user to a page asking them to confirm the 
logout, and have it as a POSTed form button from there?

That adds a helpful confirmation page, removes the difficulties of styling a 
button as a link constantly (or changing the header design to a button).

One downside would be the change in behaviour, people will be used to the 
logout link immediately logging them out and so may not read the next page...

I’m sure there is literature in best practices for logout confirmation.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0161eeed-7f9a-4312-9ed5-fc2bafde64ee%40googlegroups.com.

Re: include_block template tag

[Sam Willis]

Hi Jure,

I think this would be a great addition to Django!

I also proposed something a few years ago which was almost identical 
(https://groups.google.com/d/msg/django-developers/-75sOjhJuRU/ax_TZJgRmPQJ) 
and had a basic implementation (it probably won't work anymore without some 
tweaks). However from my experience then it will be difficult to get this 
into core without the championing from a core developer.

If there was enough interest I would certainly be happy to contribute to 
the feature!

Sam

On Monday, August 17, 2020 at 10:05:29 AM UTC+1, Jure Erznožnik wrote:
>
> While rendering templates we often come into situations where data remains 
> the same, but sometimes we want to render it one way, other times - another.
>
> Examples:
>
> a library supporting various CSS frameworks. You would always render panel 
> <https://getbootstrap.com/docs/3.3/components/#panels-heading> title and 
> panel body, but bootstrap does it using one HTML, material uses another.
>
> you may decide to render a piece of data in a panel, input, table cell, 
> etc.
>
> analysis:
>
> There's a huge note with include tag 
> <https://docs.djangoproject.com/en/3.1/ref/templates/builtins/#include> 
> clarifying how include tag is NOT used for purposes listed above. This 
> leads me to believe (but I have not researched it thoroughly) that the 
> question has been asked many times before.
>
> proposal:
>
> implement support for passing HTML renders into an included template.
>
> I see two possible approaches for this:
>
> Approach 1 template example:
>
> {% includeblock template with ... %}
> {% subblock block1 %}
>  HTML code
> {% endsubblock %}
> {% subblock block2 %}
>  HTML code
> {% endsubblock %}
> {% endincludeblock %}
>
> block1 and block2 would be blocks defined in template using existing block 
> syntax. I'm not sure if recycling existing block tag would be possible in 
> this context, but I would certainly prefer to avoid new template tag 
> syntax. Basically what this tag would do is first evaluate the subblocks, 
> then override the blocks defined in the template, then render the template.
>
> Approach 2 template example:
>
> {% block block1 as block1_var %}
>HTML code
> {% endblock %}
> {% subblock block2 %}
>HTML code
> {% endsubblock %}
> {% include template with block1=block1_var block2=block2_var %}
>
> This approach is a bit less structured than the first one, but it requires 
> a lot less modification. Basically it would only add the with parameter to 
> store block render in a variable instead of actually rendering it to 
> output. Possible problem with block inheritance within the template.
>
>
> Would either of the above be interesting to include in Django templating 
> code?
>
> Thanks for your consideration,
> Jure
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bb721678-2220-41ae-8624-29661df353f2o%40googlegroups.com.

Re: include_block template tag

[Sam Willis]

Hi Carlton, 

Thanks for chipping in.

As a long time user of Django (I first stated with it back in 2006) from my 
experience where is excels is in providing a full toolbox for building 
things for the web. The most successful “third party” apps and library’s 
tend to be very large editions of functionality rather than small functions 
and template tags. I personally stay away from small libraries as I have 
been bitten before when they are no longer maintained.

One of the criticisms of Node.js and from personal experience reasons why 
people prefer Django and similar “everything included” frameworks is the 
fragmentation of tools and large number of dependancies.

For this reason I don’t think there will ever be a successful “third party” 
implementation of this particular idea. It’s not a big enough tool for 
people to justify adding to their dependancies. (People are more likely to 
swap to Jinja which has Macros and are “sort of” similar if you squint at 
them)

Also, last year I had a quick look at my old implementation again and I 
think I came to the conclusion that it would require some small changes to 
core in order to work. I don’t remember what they are now though.

I understand completely that the barrier for adding new functionality to 
Django should be high. It important to maintain its “maintainability” and 
stop feature creep, but I also think that there is a risk of not developing 
new ideas and attracting new developers and users if it is only 
“maintained”.

(Obviously there are new things happing like the incredible and exciting 
work going into async!)

Anyway, to summarise, I think this needs to be in core to get traction and 
for people to discover it. For some ideas going the external route to prove 
it certainly makes sense but for others (like this) I think it should be 
developed though consensus in the core framework.

Reusable template components are still an unsolved problem that would be 
lovely to solve.
Thanks!
Sam
On Wednesday, August 19, 2020 at 1:05:15 PM UTC+1 jure.er...@gmail.com 
wrote:

> It definitely does. Thanks.
>
> Jure
>
> On 19/08/2020 14:03, Carlton Gibson wrote:
> > From the thread, I’d suggest collaboration with Curtis if the ideas are 
> similar enough.
> >
> > Also from the thread: the idea seems to fit between include as we have 
> it now, and a custom tag.
> > Maybe that gap hasn’t been wide enough to grasp sufficient interest?
> >
> > I think the standard path for inclusion into core goes more or less:
> >
> > * Here’s an idea
> > * Here’s a third-party implementation.
> > * Everyone[*] is using it, and the troubles have been ironed-out
> > * let’s merge it.
> >
> > [*]: Everyone ≈ a good number.
> >
> > For a third-party lib, there’s no need for it ever get to the last step. 
> (It could but it doesn’t have to.)
> > Everything we can keep somewhere else makes Django more maintainable, so 
> there’s a general preference for NOT including things if possible.
> >
> > Hopefully that makes sense.
> >
> > Kind Regards,
> >
> > Carlton
> >
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4b1a3f96-9fa4-4ab3-9213-b00911a57750n%40googlegroups.com.

Re: Align Django admin checkboxes

[Sam Willis]

I believe this is designed so that when there are multiple checkboxes in a 
line they look like this:





On Monday, August 28, 2017 at 9:41:05 PM UTC+1, Collin Anderson wrote:
>
> A hybrid approach could be better. (To create this mockup I inserted an 
> empty "label" tag.)
>
> [image: Inline image 1]
>
> On Mon, Aug 28, 2017 at 4:24 PM, Aymeric Augustin <
> aymeric@polytechnique.org > wrote:
>
>> Hello,
>>
>> At first sight, the checkbox and the label is clickable in the first 
>> example while only the checkbox is in the second example. That's a 
>> regression in usability.
>>
>> Best regards,
>>
>> -- 
>> Aymeric.
>>
>>
>>
>> On 28 Aug 2017, at 11:38, Zach > wrote:
>>
>> Hi. Currently the alignment of the checkboxes are inconsistent with other 
>> form fields. It makes sense to align the checkbox and create a consistent 
>> user experience.
>>
>>
>>
>> 
>>
>> -- 
>> 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/b57f87df-d622-42d9-8414-21e488a85336%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-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/9D88058C-81A1-4704-A3FB-A508FDEDE130%40polytechnique.org
>>  
>> 
>> .
>>
>> 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/cca2864f-9b2f-4f15-922d-b5975ad022e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Sam Cooke]

On projects I've been working on I started using "prettier" fro JavaScript
and it made a huge difference to code consistency across the team, which
was great, but my favourite benefit (that I'm not sure I've seen mentioned
much here) is I can write code faster if I don't have to format it. Being
able to just type without worrying about it, then hit save and it jumps
into place, means if I'm working on files without automatic formatters I
now feel like I'm doing a machine's job tidying things up.

Having said that - whilst I use black on all of my python projects, it's
not had anywhere near as much of a positive impact as prettier has on
JavaScript because:
 - python is generally more readable and consistent naturally than
JavaScript
 - significant whitespace in python means you still spend time manually
formatting code so you save less time than with JavaScript
 - I've found black to be unreliable - it silently fails on quite a few of
my files
 - prettier is smarter about allowing you to add whitespace to make things
like lists more readable, but black is 100% fixed in its ways

The best thing about automatic formatters, in my opinion, is even if you
don't like the style at least you don't have to talk about it any more! And
you tend to get used to it eventually.

On Mon, 22 Apr 2019 at 19:10,  wrote:

> I wonder if there's a middle ground between minimizing code churn and
> having a standardized formatter. Our team recently switched to yapf after
> carefully configuring a .style.yapf file that's included in the root
> directory of every new repo. Once that config file is done, the workflow
> for yapf vs an unconfigurable formatter is identical.
>
>
> I experimented a bit with the following .style.yapf settings on the django
> codebase and think the output is as good as black's without some of the
> arbitrariness of string quotes:
>
> [style]
> based_on_style = pep8
> column_limit=100
> i18n_function_call=['_']
> blank_line_before_nested_class_or_def=True
> join_multiple_lines=False
> indent_dictionary_value=False
>
> coalesce_brackets=True
> dedent_closing_brackets=True
> align_closing_bracket_with_visual_indent=False
> space_between_ending_comma_and_closing_bracket=False
>
> split_complex_comprehension=True
> split_before_first_argument=True
> split_before_logical_operator=False
> split_before_bitwise_operator=False
> split_arguments_when_comma_terminated=True
> split_before_expression_after_opening_paren=True
> split_before_named_assigns=True
>
>
> Yapf currently has more stars than black, but whether black has more
> momentum or not, who can say.
>
>
> On Monday, April 22, 2019 at 10:14:44 AM UTC-4, Nick Sarbicki wrote:
>>
>>
>>> I'm just saying that if "As contributor, I can haz automatic code
>>> formatter to lower the barrier" is precisely the story you want to solve,
>>> then black may not be the only solution you want to consider deeply ;)
>>>
>>>
>> Jamie, sure, I wasn't responding directly to you about this, more to the
>> general people arguing against blacks style choices. I would happily
>> consider alternatives to black - although (without any formal research to
>> back this claim) it does feel like black has the most community support.
>>
>> My point is mostly that if there is a growing community consistency
>> through black then I'd be hesitant to choose another tool that goes against
>> this.
>>
>>
>>
>>> > Consistency in the end is the most important thing (even PEP8 agrees
>>> > there).
>>>
>>> Not sure where you got that impression:
>>> https://pep8.org/#a-foolish-consistency-is-the-hobgoblin-of-little-minds
>>> 
>>>
>>> Pep8 clearly states consistency is less important then readability (it's
>>> the
>>> first thing mentioned and mentioned repeatedly that you can use as an
>>> argument
>>> to break consistency). And this is the primary advantage of black, since
>>> readability is hard to quantify (and therefore lint or format) and I
>>> think
>>> this is where black has succeeded (by breaking consistency where it is
>>> needed).
>>> I mostly follow the discussion with interest from the sidelines, but
>>> just
>>> wanted to correct this consistency argument: if you want consistent
>>> code, go
>>> with autopep8, it'll keep your lines consistent below 79 characters and
>>> quite
>>> an unreadable mess.
>>> --
>>>
>>
>> Thanks for the correction Melvyn, you're right - aside from readability
>> and backwards compatibility consistency is important.
>>
>> I'd also note the irony of using PEP8 to argue for consistency with a
>> tool that is (at least on line length) inconsistent with PEP8. Although I
>> really don't want to start a debate on line length.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group a

Annotate date intervals or ranges

[Sam Peka]

It would be great if there was a way within the standard Queryset api to 
annotate ranges of dates. The use case is that it would remove the need to 
resort to RawSQL when grouping things by date ranges, such as the day of 
the month. I know the postgres extras package has a DateRangeField, but 
it's surprisingly difficult to do this dynamically.

So I'd propose something like this:

queryset.annotate(day_created=DateRange('day', 'created_date'))

Which for Postgres would equate to:

SELECT date_trunc('day', "created_date") as day_created from ...

Is there a technical reason why this hasn't already been done? Or has there 
not been much of a need for it?

-- 
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/fe7dcfc9-cbb5-439b-bf08-f45e854a99c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sqlite 3.12 breaks the Django test suite

[Sam Cooke]

We ran into this issue a couple of months ago - I'm not sure how helpful
this is but just in case extra information is useful I'll share our
workarounds. The faulthandler output was roughly the same - the error
happened during a rollback. This also happened on multiple python and
sqlite versions.

It started when we removed a model and the one foreign key to that model.
The quickest workaround we found was to simply add the model and foreign
key back when running tests - which implies to me that the structure of the
database was related to whether or not it segfaulted (the test where the
segfault occurred was unrelated to the model that was removed).

The second option was we could remove the creation of a model during a test
(i.e. something that meant a rollback was required).

The third option was to use an on-disk sqlite database rather than in
memory.

I hope some of that is useful,
Sam

On Thu, 7 Apr 2016 at 14:37 Florian Apolloner  wrote:

> This is the list of SQL statements we are executing:
> https://dpaste.de/Mqu1/raw first column is thread id, second is cursor id
> and third is the statement. I am a little bit confused about why the cursor
> ids seem to be "jumpy" like that -- but in general this should not cause
> issues I think
>
>
> On Thursday, April 7, 2016 at 3:06:14 PM UTC+2, Florian Apolloner wrote:
>>
>> Perfect, I can reproduce it. This also happens if the default/other
>> databases are not in memory -- I'll see what happens if I switch to
>> postgres for the second database (though I am getting an error there
>> currently -- might have to fix master :D)
>>
>> On Thursday, April 7, 2016 at 1:00:25 PM UTC+2, Raphael Hertzog wrote:
>>>
>>> [ CCing an upstream developer of SQlite too ]
>>>
>>> Hello,
>>>
>>> I did not want to open a ticket as I'm not sure if the problem
>>> is in SQLite or in Django but the Django test suite fails really badly
>>> with SQLite 3.12.0 that got recently released (and which is already
>>> in Debian Unstable).
>>>
>>> When using the default --parallel run, I get many weird
>>> errors and sometimes even a deadlock. When I run it with --parallel=1,
>>> I got a segfault.
>>>
>>> You can see a log of the failure here (this is a parallel run):
>>>
>>> https://ci.debian.net/data/packages/unstable/amd64/p/python-django/20160406_191352.autopkgtest.log.gz
>>>
>>> There's a backtrace of the segfault (with --parallel=1):
>>>
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?filename=gdb.txt;bug=820225;msg=27;att=1
>>>
>>> Cheers,
>>>
>>> PS: Tracked here in Debian too:
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820225
>>> --
>>> Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer
>>>
>>> Discover the Debian Administrator's Handbook:
>>> → http://debian-handbook.info/get/
>>>
>> --
> 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/813967fd-3a1f-4b2a-93cc-c14f320f920f%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/813967fd-3a1f-4b2a-93cc-c14f320f920f%40googlegroups.com?utm_medium=email&utm_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/CAMyx3A1YcqPkzUNboc%3DntngpAyLjLJ_9gy5vfZ_b5pxyqGjZrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Joining the "Python 3 Statement"

[Sam Willis]

As far as I can tell the only place where Django's Python 2.x deprecation is 
stated is here https://www.djangoproject.com/weblog/2015/jun/25/roadmap/

I think it should be more prominently stated in the docs, and as 1.11 is 
supposedly the last to support 2.7 (according to the blog post) it may be worth 
promoting it as such.

Maybe there should be a pominant announcement about which version is the last 
to support 2.7? Maybe in the release notes of 1.10?

-- 
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/678cee6c-3df4-4715-b6af-3d20bf3f3822%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing {% include %} to strip a trailing newline

[Sam Willis]

Could this be set within the template rather than the include tag? So for 
example have a new tag such as {% strip_final_new_line %} that when 
included at the end of a template immediately before the final new line 
would instruct it to be striped.

This stops the user from having to remember to use a special option on the 
include tag for each use of a template that requires it - it also work on a 
normal (not included) template render as well, if that is wanted.

An alternative tag could be {% endtemplate %} that can be placed anywhere 
in the template, forcing the end of rendering?

On Wednesday, January 4, 2017 at 7:58:42 PM UTC, Tim Graham wrote:
>
> Shortly after template widget rendering was merged, an issue about extra 
> newlines appearing in the rendered output was reported [0]:
>
> For example, from django-money:
>
> UIC-Franc
> \n\n
> US Dollar
> \n\n
>
> The newlines aren't useful and they break assertions like this:
>
> US Dollar in form.as_p
>
> --- end report---
>
> The reporter suggested removing the trailing newline in the attrs.html 
> template but Adam Johnson reported: "POSIX states that all text files 
> should end with a newline, and some tools break when operating on text 
> files missing the final newline. That's why git has the warning \ No 
> newline at end of file and Github has a warning symbol for the missing 
> newline."
>
> I suggested that perhaps {% include %} could do .rstrip('\n') on whatever 
> it renders.
>
> Preston pointed out that Jinja2 does something similar:
>
> http://jinja.pocoo.org/docs/dev/templates/#whitespace-control
>
>- a single trailing newline is stripped if present
>- other whitespace (spaces, tabs, newlines etc.) is returned unchanged
>
> I noted that the issue of {% include %} adding extra newlines was raised 
> in #9198 [1] but Malcolm said, "For backwards compatibility reasons we 
> cannot change the default behaviour now (there will be templates that rely 
> on the newline being inserted)." I was skeptical this would be a burdensome 
> change.
>
> Carl replied:  "It seems quite likely to me that there are templates in 
> the wild relying on preservation of the final newline. People render 
> preformatted text (e.g. text emails) using DTL. I probably have some text 
> email templates in older projects myself that would break with that change. 
>
> We could add a new option to {% include %}, though." Adam also said, "I 
> too have used DTL for text emails that would break under that behaviour. 
> New option to include sounds good to me."
>
>
> Me again: In the long run, having {% include %} remove the trailing 
> newline seems like a more sensible default. For example, I wouldn't expect 
> this code to have a newline inserted between it:
>
>
> {% include "foo.txt" %}
> {% include "bar.txt" %}
>  
>
> An option for {% include %} seems superfluous given that if you were 
> writing
>
>
> {% include "foo.txt" %}{% include "bar.txt" %}
>  
>
> now you can write the first thing which is much more intuitive.
>
>
> How about a keep_trailing_newline TEMPLATES option for backwards 
> compatibility for those who don't want to adapt their templates for the new 
> behavior? Jinja2 has that option.
>
> Carl replied: An engine option may be better than an option to {% include 
> %}, though it doesn't allow us to ensure that we strip the newline in the 
> specific case of attrs.
>
> How we default the engine option I guess just depends on how seriously we 
> take backwards compatibility. If we default it to strip and make people add 
> the config to preserve the old behavior, that's not really backwards 
> compatible. Historically (as seen in Malcolm's comment) we would choose to 
> err on the side of actual backwards compatibility in a case like this, even 
> if it didn't result in the ideal future behavior. But the adaptation isn't 
> hard in this case, so I won't object if the choice is to break back-compat.
>
>
> If it's not a per-include choice, of course, we have to break overall 
> back-compat to preserve form-attr-rendering back-compat.
> 
>
> What do you think?
>
> [0] https://github.com/django/django/pull/7769
> [1] https://code.djangoproject.com/ticket/9198
>

-- 
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/1819d705-7b6a-46f0-9ede-dee3cf5d7b69%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add custom autoreload file tracking options setting

[Sam Willis]

Could one options be to replace the current devserver with the one from 
Werkzeug? It already uses watchdog (similar to watchman) for monitoring 
file system events and is well maintained. With Django now allowing 
dependancies, this seems like something that doesn't necessarily need to be 
developed internally.

The Werkzeug devserver also has some niceties like an interactive debugger 
and ssl hosting with an automatically issued self signed certificate. It 
could be implemented behind the current management command relatively 
easily.

There is already an implementation as part of django-extentions that I 
believe is well used and battle tested 
- http://django-extensions.readthedocs.io/en/latest/runserver_plus.html 


On Thursday, January 5, 2017 at 9:11:53 AM UTC, Aymeric Augustin wrote:
>
> On 4 Jan 2017, at 23:31, Bobby Mozumder > 
> wrote: 
>
> > I guess I could just use Watchman to restart the Django development 
> server as needed? 
>
>
> If you find a way to tell watchman to run `django-admin runserver 
> --noreload` and restart it whenever a file in the current directory 
> changes, that should do the job. 
>
> Unfortunately the APIs exposed by watchman don’t make this trivial. 
> They’re intended to run a build process that will terminate, while the 
> development server will keep running. 
>
> -- 
> Aymeric. 
>
>

-- 
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/6d346a13-b096-42f8-a15b-a2814a81eef5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing and renaming Django's Python 2 related helpers

[Sam Willis]

Hi,

An alternative option with 'six' is to replace it with an alias of six 
propper (not vendored), something like this:

# django/utils/six.py
try:
from six import *
except ImportError:
raise ImportError((
"`django.utils.six` is deprecated, install six from pypi "
"(https://pypi.python.org/pypi/six) instead. After installing 
it will be available at "
"`django.utils.six` until Django V2.xx."))
except:
import warnings
warnings.warn((
"The `django.utils.six` alias is deprecated and will be removed 
in Django V2.xx.",
DeprecationWarning, 2
)

That way it removes the need for it to be maintained in core but ensures 
that other Django apps that are supporting py2 and 3 don't break.

Sam

On Tuesday, January 24, 2017 at 11:53:01 AM UTC, Aymeric Augustin wrote:
>
> Hello,
>
> Django is earning a lot of goodwill from its well-defined deprecation 
> policy. It was recently improved to allow pluggable apps to work without 
> import shims and without deprecation warnings from one LTS to the next. I 
> don’t know the exact details but I believe that's the intent.
>
> Combined with a thorough documentation of backwards-incompatible changes, 
> it helps many developers put up with changes, even those they don’t 
> understand, disagree with, or require significant work to adapt 
> applications.
>
> For this reason, in the context of the transition from Python 2 to Python 
> 3, which is very backwards incompatible for people who haven’t been able to 
> anticipate it, I’m in favor of a generous application of the deprecation 
> policy.
>
> I’m +1 on deprecating rather than removing utilities that were mentioned 
> in the documentation, notably python_2_unicode_compatible, which was a 
> public API until it got merged into six and we started using six’ version.
>
> I’m +0 on deprecating rather than removing modules that a developer of a 
> pluggable app would reasonably use for Python 2 compatibility, such 
> as django.utils.lru_cache or django.utils.six.
>
> I’d just remove less visible functions such as django.utils._os.abspathu, 
> provided they clearly fall in the “private API” bucket.
>
> Best regards,
>
> -- 
> Aymeric.
>
>
>
> On 21 Jan 2017, at 21:55, Tim Graham > 
> wrote:
>
> As we worked on removing Python 2 compatibility code from master this week 
> [0], we collected a number of import shims and functions that are only 
> needed for code that wants to support Python 2 [1].
>
> So far there is django.utils.six, as well as some undocumented things:
>
>- django.utils.lru_cache 
>- django.utils._os.abspathu, upath, npath 
>- django.utils.decorators.available_attrs
>- django.utils.encoding.python_2_unicode_compatible
>
> I'm advocating to remove the undocumented things in Django 3.0 (released 
> Dec. 2019) or later without a deprecation. By that time, I hope third-party 
> apps won't support Python 2 either and so part of adding Django 3.0 
> compatibility will include formally dropping support for Python 2 (if not 
> done already) and removing usage of this stuff (a fairly easy find/replace, 
> hopefully).
>
> Others have advocated to deprecate all these things, but I don't see much 
> advantage. If I were maintaining an app, I'd rather be able to use import 
> shims without warnings until Python 2 is gone. What's your preference?
>
> A similar concern applies to django.utils.http's urlquote() and 
> urlquote_plus() (documented) and urlunquote() and urlunquote_plus() 
> (undocumented). Claude has a PR that deprecates them [4] which I think is 
> fine considering they are half documented.
>
> A related issue is the naming of the force_text() / force_str() and 
> smart_text() / smart_str() functions. Aymeric proposed a PR to change all 
> force_text() 
> usage in Django to force_str() (they function identically on Python 3) [2], 
> however, I feel this might create some confusion. For example, when 
> backporting to 1.11 and earlier, we'll have to change force_str() to 
> force_text() for Python 2 compatibility. Third-party apps might also be 
> confused on which function to use. Claude proposed a similar that changes 
> ugettext() 
> and ungettext() to gettext() / ngettext() [3]. Would it be less confusing 
> to consider these changes when Python 2 is no longer supported by any 
> version of Django?
>
> [0] https://code.djangoproject.com/ticket/23919
> [1] https://code.djangoproject.com/ticket/27753
> [2] https://github.com/django/django/pull/7913
> [3] https://github.com/django/django/pull/7916
>
> -- 
> You received this message because you are subscribed to 

Subresource Integrity

[Sam Willis]

Hi,

You may have come across the (relatively) new subresource integrity 
(SRI)[1] security feature that is available in Chrome and Firefox (its 
coming to Edge[2] and Safari[3]) - it enables a hash to be provided as an 
attribute on a linked JavaScript or CSS tag that the browser can test 
against once the file has downloaded to ensure that it hasn't been tampered 
with. Its main use case is for when you are using a third party CDN for 
your static files. I have been looking at how best to implement it in/with 
Django and believe that incorporating it into the 'staticfiles' framework 
may be the best we to go.

Currently 'ManifestStaticFilesStorage' and 'CachedStaticFilesStorage' store 
a simple dict mapping file path to path was a hash in the filename for 
cache busting. I would like to propose that this is changed to a mapping of 
file path to a tuple of (filepath_with_hash, hash_algo, file_hash_base64). 
This allows us to add the subresource integrity attribute to any linked 
file that is managed by either of those storages.

I have mocked up how this could be done [4], the changes I made 
to django/contrib/staticfiles/storage.py are here [5].

There is then a simple template tag that includes the SRI token:
{% static_sri_token 'path/to/file.js' %}
>>> sha256-ATJWBF9ZhO9FS8vr9wEhYO+W9vLtd3jRZVmEdC5EL0s=

or the whole attribute:
{% static_sri_attrs 'path/to/file.js' %}
>>> integrity="sha256-ATJWBF9ZhO9FS8vr9wEhYO+W9vLtd3jRZVmEdC5EL0s=" 
crossorigin="anonymous"

By incorporating this into Django rather than a third party app it would 
ensure that everyone gains access to this new security feature for free - 
it can be documented with the static files docs, encouraging its use and 
help to secure more peoples projects.

Please note that my code is just a proof of principle, and I would be very 
happy to hear if anyone has any thought on a better way of implementing the 
feature.

[1]: 
https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
[2]: 
https://developer.microsoft.com/en-us/microsoft-edge/platform/status/subresourceintegrity/
[3]: https://webkit.org/status/#feature-subresource-integrity
[4]: https://gist.github.com/samwillis/90b5391f9dafc0662ae2af7b8f827bd9
[5]: 
https://gist.github.com/samwillis/90b5391f9dafc0662ae2af7b8f827bd9/revisions#diff-80f99275da9c9dbb59bb177e83b9f13e

-- 
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/26ac849d-d6d1-4e9e-aa14-d16b0552a43f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Tablespace not being set in query for oracle driver.

[Sam Richards]

If I connect to oracle as one user (e.g. test_user) but my tables are
in a different tablespace (e.g. test)

I would expect to be able to set my class with:
class Album(models.Model):
   str_album_name = models.CharField(max_length = 16, core=True)
   class Meta:
  db_tablespace="test"
  db_table="album"

So that a query to get everything would become:

select test.album.str_album_name from test.album

The problem is db_tablespace doesnt seem to do that. I did however get
it working by setting:
db_table = "test\".\"album"

I havent tested everything, but it does seem to at least do the querys
properly, but this doesnt seem quite right.

Or am I missing something?

Sam.


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