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

[Curtis Maloney]

Interesting idea... so much so I'd like to steal it :)  However, since it
can be implemented as a 3rd party app, I suspect you'll get some push-back
from trying to get it into core.

I've recently started work to reimagine my "sniplates" project [
https://bitbucket.org/funkybob/django-sniplates], which overlaps some of
these ideas.

My plan is to allow you to load "widget" sets from another template
[widgets are simply blocks in the template], and use them within your other
templates.

Since the widget sets are retained in the render_context, you can load them
in inherited templates and access them all the way down.

I was also going to include the {% reuse %} tag from formulation, which
lets you re-use any block tag from the current template context.

I'd be interested in including your idea into my app, if you're wiling to
collaborate.

--
Curtis



On 4 September 2014 02: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 %}
> {% 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.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django 

Re: DatabaseError: no such table: django_content_type

[Tim Graham]

This is django-developers, the list for discussing the development of 
Django itself. For questions about using Django, please use the 
django-users mailing list. It's also helpful to include a traceback of the 
error.

On Wednesday, September 3, 2014 4:29:52 PM UTC-4, Leandro Moreno wrote:
>
> Hello list! I'm trying to run my tests and I have these error.
>
> In a config.py file I'm doing this:
>
> from django.contrib.contenttypes.models import ContentType
> ContentType.objects.get_for_model(model=MyModel)
>
> And when I run the tests, this error apears, and only with tests.
>
> I'm including contrib.contenttypes to my INSTALLED_APPS. I did syncdb and 
> migrate. So, I cannot see where the problem is.
>

-- 
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/ff0980ac-641d-422d-9467-480c11587397%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Please don't kill the ecosystem

[Collin Anderson]

Considering we're trying to come out with more frequent releases, I wonder
if it would sometimes make sense to sometimes have a 3-release deprecation
for some features.

-- 
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/CAFO84S4jfKyoQAfAXvRAqonXEH5apHpMDPULY5Qvv0rk-62qQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

DatabaseError: no such table: django_content_type

[Leandro Moreno]

Hello list! I'm trying to run my tests and I have these error.

In a config.py file I'm doing this:

from django.contrib.contenttypes.models import ContentType
ContentType.objects.get_for_model(model=MyModel)

And when I run the tests, this error apears, and only with tests.

I'm including contrib.contenttypes to my INSTALLED_APPS. I did syncdb and 
migrate. So, I cannot see where the problem is.

-- 
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/4d78e325-dd2e-4d3a-8dd9-43fa645ec90d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: proposing max line length of 119 + enforcing it with flake8

[Carl Meyer]

On 09/03/2014 01:47 PM, Tim Graham wrote:
> Ticket #23395  raised the
> issue that our contributing guidelines is not exactly clear regarding
> long lines. Currently it says,
> 
> "One big exception to PEP 8 is our preference of longer line lengths.
> We’re well into the 21st Century, and we have high-resolution computer
> screens that can fit way more than 79 characters on a screen. Don’t
> limit lines of code to 79 characters if it means the code looks
> significantly uglier or is harder to read."
> 
> I'd like to propose changing it like this:
> 
> "An exception to PEP 8 is our preference of longer line lengths. Don’t
> limit lines of code to 79 characters if it means the code looks
> significantly uglier or is harder to read. Up to 119 characters is okay
> as this is the width of GitHub code review; anything longer requires
> horizontal scrolling which makes review more difficult. This check is
> included when you run flake8. Documentation, comments, and docstrings
> should be wrapped at 79 characters."
> 
> The biggest hurdle is cleaning up the existing code as we currently have
> ~1700 lines longer than that. I attached an initial patch on the ticket
> to show how long strings can be restructured. If there is no objection,
> perhaps I can work with some afraid-to-commit workshop participants
> to divvy up the work. flake8 fixes were a big hit last time.

I support this change to the wording, and your sample long-line fixes
look fine.

How about just removing the sentence "An exception to PEP 8 is our
preference of longer line lengths." With recent updates to PEP 8 to
accommodate longer lines, the stated policy is no longer an exception to
PEP 8, and I think "preference of longer line lengths" is poorly worded
anyway; preference vs what? Nobody prefers longer lines to shorter ones,
all else equal (at least I'd hope not).

Carl

-- 
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/54077233.5070802%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

proposing max line length of 119 + enforcing it with flake8

[Tim Graham]

Ticket #23395  raised the 
issue that our contributing guidelines is not exactly clear regarding long 
lines. Currently it says,

"One big exception to PEP 8 is our preference of longer line lengths. We’re 
well into the 21st Century, and we have high-resolution computer screens 
that can fit way more than 79 characters on a screen. Don’t limit lines of 
code to 79 characters if it means the code looks significantly uglier or is 
harder to read."

I'd like to propose changing it like this:

"An exception to PEP 8 is our preference of longer line lengths. Don’t 
limit lines of code to 79 characters if it means the code looks 
significantly uglier or is harder to read. Up to 119 characters is okay as 
this is the width of GitHub code review; anything longer requires 
horizontal scrolling which makes review more difficult. This check is 
included when you run flake8. Documentation, comments, and docstrings 
should be wrapped at 79 characters."

The biggest hurdle is cleaning up the existing code as we currently have 
~1700 lines longer than that. I attached an initial patch on the ticket to 
show how long strings can be restructured. If there is no objection, 
perhaps I can work with some afraid-to-commit workshop participants 
to divvy up the work. flake8 fixes were a big hit last time.

-- 
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/8772de23-2970-4b60-91ae-f5817f9b2bac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Please don't kill the ecosystem

[Pkl]

Hello,

Hello,

My apologies for sounding rude, and for raising these issues so late.

Yes, upgrading a project itself is a matter of a pair of evenings, the 
problem is with third-party libraries, and more again, plugins of 
third-party libraries (especially CMS-related). 
I've had to bundle a dozen of these with my app, because they didn't quite 
follow the pace of Django evolutions. Now of course, as you say, I might as 
well stabilize for some time on a LTS version, but as was said too, the 
next steps would also be much harder then. Or I could forget about modular 
apps, and go towards monolitic third-party apps instead...

I felt that crucial variables like "request.REQUEST" or "raw_post_data" 
could stay aliased for much more than 2 minor versions (but undocumented 
and with warnings, of course), for teh sake of retrocompatibility.
However if it's acknowledged, in the core team, that code maintainability 
and security would be hindered by keeping these artefacts, I can't argue 
that. 

Concerning the "rules of open source", I've yet to find a satisfying way to 
apply them regarding these "micro breaks". Imagine that project 
"myvideoplugin" is unmaintained (not handling PR) : unable to patch the 
original Repo, I'd have to fork it ; and unable to push results to the 
original pypi name, I'd have to create a separate myvideoplugin-pkl package 
on Pypi... that's quite some hassle for (often) a 10-lines patch.

Thanks Curtis for the proposal, I was thinking about a django-retrocompat 
package indeed, however I realize that doing a decent job of 
retrocompatibility would be a much harder job than initially expected, 
since breaking changes are rarely a matter of simple aliases 
(https://docs.djangoproject.com/en/1.7/releases/1.7/#backwards-incompatible-changes-in-1-7)
 
; django-retrocompat wouldn't stand the expectations of users. But a 
minimal package dealing only with "renamed fields" would be doable, I'll 
have a look at it.

regards, 
Pkl

-- 
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/3317f347-d82b-4edd-90fd-16da41f5dc49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: integrating django-secure

[Tim Graham]

Over the past couple days, I've made some more updates and polish to the 
PR. A couple people have looked at it, but some more eyes would be 
appreciated as it's hopefully now in a mergeable state. Thanks!

https://github.com/django/django/pull/3128

p.s. It uses flat, non-dict settings. We can continue the debate on other 
dict settings in another thread.

On Tuesday, September 2, 2014 3:09:42 PM UTC-4, Carl Meyer wrote:
>
> On 09/01/2014 02:34 PM, Michael Manfre wrote: 
> > On Mon, Sep 1, 2014 at 2:12 PM, Aymeric Augustin 
> >  > > wrote: 
> > 
> > If we recommend HSTS, we need visible warnings and a small duration 
> > in examples, for people who copy-paste without reading. 
> > 
> > 
> > The default duration should also be less than a day for the exact reason 
> > brought up. The visible warnings could state why it is a good idea to 
> > increase the duration, after it is tested in production. 
>
> There is no default duration; the default is no HSTS at all. Tim has 
> updated the documentation to warn about the possible issues, and 
> recommend testing with a short duration before increasing. 
>
> Carl 
>

-- 
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/2831b58c-8e05-4efe-9710-f402e3780572%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'.

[Jonathan Slenders]

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/f481b5c8-fb59-46e5-bda5-13436a4bb1ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANNOUNCE] Django 1.7 released

[Thomas Leo]

Keep up the great work!

On Tuesday, September 2, 2014 6:13:21 PM UTC-4, James Bennett wrote:
>
> Django 1.7 is now available:
>
> https://www.djangoproject.com/weblog/2014/sep/02/release-17-final/
>
> Alongside this are bugfix releases for 1.4, 1.5 and 1.6. The bugfix 1.5 
> release is the final releae in the 1.5 series, as Django 1.5 has now 
> reached end-of-life.
>  

-- 
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/b9782210-94e3-41ed-97d9-76992319c9a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANNOUNCE] Django 1.7 released

[Yo-Yo Ma]

Epic, thanks so much!

-- 
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/d48aa100-bc8e-4fea-8b20-78bed42c47ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Please don't kill the ecosystem

[Anssi Kääriäinen]

On Wed, 2014-09-03 at 14:46 +0200, Aymeric Augustin wrote:


> 1.5 and 1.6 must have been easier than 1.4. 1.7 may be more difficult
> because
> of migrations and app-loading. If anyone has improvements to suggest
> for the
> documentation, please do!

We could perhaps have better documentation of how to handle deprecations
in 3rd party libraries. Namely, how to remove usage of deprecated
features in a way that works silently both before and after the addition
of the deprecation.

For example, lets consider the get_query_set() -> get_queryset() naming
change done in 1.6. If 3rd party library writers change the method name
to get_queryset() for 1.6, then their code won't work in 1.5. If they
don't do the change, then all users trying to run with -Wall will get a
bunch of deprecation warnings they can't do much about. This will
effectively ruin the "run with -Wall" advice.

The usual way to solve these kinds of problems in code that needs to
work in multiple Django versions is to write code which is conditional
on Django's version. It looks a bit ugly to define methods
conditionally, but in practice this works extremely well.

So, when adding a new deprecation to Django, we should document how 3rd
party library writers can write code that works *silently* both before
and after the feature deprecation is added. If there is no easy way to
achieve that, then we should reconsider the deprecation.

 - Anssi


-- 
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/1409750485.11410.611.camel%40TTY32.
For more options, visit https://groups.google.com/d/optout.

Re: Please don't kill the ecosystem

[Aymeric Augustin]

2014-09-03 10:40 GMT+02:00 Tom Evans :
>
> I think it was more distraction by topics he had not come across. We
> set him off by saying "look at the release notes, go thru each change
> in turn, see if we are affected and what we need to fix it".
>

Thanks Tom for the details. I understand better. Upgrading Django exposes
you
to components or features you didn't even know existed. The time I spent
triaging Trac tickets gives me a massive advantage there :-)

The problem then was that he was new. He hadn't had to deal too much
> with TZ support, so adding TZ support to our project meant a day of
> learning about how TZ work in UNIX.
>

You went for USE_TZ = True. That required a lost of work to adjust your
entire
codebase. I'm considering that a new feature for your project. If you wanted
to upgrade as fast as possible, you could have kept the legacy behavior with
USE_TZ = False. That was the default for projects upgraded from 1.3.

Similarly, changing the project layout is a good thing, but then he
> spent a day learning about package layouts - not a bad thing by any
> means, but in the 1.3 -> 1.4 release there are 75 similarly complex
> enhancements/deprecations/incompatibilities - it just takes some time
> to go through if you have not come across that topic before, eg,
> clickjacking.


Right, this was another complicated change you couldn't skip.

1.5 and 1.6 must have been easier than 1.4. 1.7 may be more difficult
because
of migrations and app-loading. If anyone has improvements to suggest for the
documentation, please do!

-- 
Aymeric.

-- 
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/CANE-7mU23ag9N4vnuajfFsOdtYKBp1RttE3WqG%2B36BUXo6yQ4g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Please don't kill the ecosystem

[Tom Evans]

On Tue, Sep 2, 2014 at 2:53 PM, Aymeric Augustin
 wrote:
> 2014-09-02 15:33 GMT+02:00 Tom Evans :
>
>> this story was scored
>> at 8 points, it took a junior developer much longer than 8 points and
>> wasn't finished in a single sprint - and 1.3->1.4 was *easy*
>
>
> I don't know how much a point or a sprint is worth in this context :-/

Sorry, context is important! "A sprint" ~ 9 work days, points vary
wildly from sprint to sprint unfortunately - 12 is about a sprints
worth of work.

> 

Good steps.

>
> Did your junior developer follow a similar process? If he did, what took
> them
> so long?
>
> What I want to understand is how much of an advantage I have when it comes
> to
> upgrading Django. What do I know that isn't written down and makes it so
> hard
> for others?

I think it was more distraction by topics he had not come across. We
set him off by saying "look at the release notes, go thru each change
in turn, see if we are affected and what we need to fix it".

The problem then was that he was new. He hadn't had to deal too much
with TZ support, so adding TZ support to our project meant a day of
learning about how TZ work in UNIX.

Similarly, changing the project layout is a good thing, but then he
spent a day learning about package layouts - not a bad thing by any
means, but in the 1.3 -> 1.4 release there are 75 similarly complex
enhancements/deprecations/incompatibilities - it just takes some time
to go through if you have not come across that topic before, eg,
clickjacking.

Cheers

Tom

-- 
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/CAFHbX1%2B%2Bzdz0GK2jvJJ5tH1zLAi3agc3JNFhN4nWEXBBaLPATw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.