Re: Django 2.0 Python version support (Python 3.6+ only?)

2017-01-07 Thread roboslone 
> I do not think this matters, first off there is no commitment from our side 
> on type hinting or anything. We do not have any DEP or something related and 
> didn't even discuss if we actually want type hinting. Personally I am kinda 
> against it anyways, since it clutters the code for not much gain. So if we 
> were to do it, I would prefer stub files anyways, in which case we won't 
> depend on any python version as far as I understood that.

As Django user, I have to say type hinting would help a lot to understand how 
things work in Django without looking at docs. It could save a lot of time for 
beginners, too. Also I have to mention, that PyCharm (which is the most popular 
IDE for Python, I believe) has support for type hinting and could help you 
avoid many problems before even firing up a server.

In my opinion not adding type hints in Django 2.0 would be a mistake.

> "Django 2.0 will be the last version of Django to support Python 3.4. This 
> allows those running older operating systems with Python 3.4 (such as Ubuntu 
> 14.04 and CentOS 6) to use the latest version of Django for an additional 
> eight months. If you don't intend to upgrade to a system with Python 3.5 or 
> later by the end of security updates for Django 2.0 in April 2019, stick with 
> Django 1.11 LTS which is supported until April 2020."


As to Python 3.4 support, Django 1.11 will be LTS and most projects written 
with Django <=1.10 will probably stay on LTS version. Using Django 2.0 in 
existing project would require rewriting some bits anyway (correct me if I'm 
wrong), so there's really not much point in sticking to Python 3.4/3.5 in my 
opinion. If you're rewriting your code to use new version of Django, you could 
as well use new version of Python. Isn't it the whole point of major release?

Sticking to 3.6 would allow using format strings, and that would greatly 
increase readability (looking at %-strings here). To be honest, using 
str.format on string with many variables can hurt readability almost as much as 
% does. Also, variable annotation only appeared in 3.6, so supporting Python 
3.5 an older would mean that variable annotation is only possible using 
comments (which is not necessarily a bad thing, tough it has some downsides as 
pointed out in PEP-526).

I have to add, that nowadays deploying python applications with desired version 
of Python is fairly easy. One could use relocatable virtualenvs, Docker 
containers and so on. So even if you're on an outdated distro (or something 
like RHEL, that wouldn't get new python version in ages, probably) and your OS 
is stuck with older version of Python, your application doesn't have to be.

Since there're a lot of Django users out there who aren't subscribed to this 
mailing list, I suggest to sum up this discussion in a blog post and let users 
vote. I believe a big "Help decide Django 2.0 fate" button on djangoproject.com 
would attract much more attention to the issue. Maybe most of Django users are 
ready to migrate to Python 3.6 when they switch to Django 2.0 (probably not, 
but who knows) and developers could start enjoying new Python features a year 
or two earlier.

P.S. Please treat everything above as a personal opinion, I'm probably wrong 
about some things. And sorry for a bad English, it's not my native language.

> On 7 Jan 2017, at 19:48, Tim Graham  wrote:
> 
> Daniele, here's my try at being more concrete than "It seems reasonable" and 
> "decent ledge of overlap". Let me know if you meant something different!
> 
> "Django 2.0 will be the last version of Django to support Python 3.4. This 
> allows those running older operating systems with Python 3.4 (such as Ubuntu 
> 14.04 and CentOS 6) to use the latest version of Django for an additional 
> eight months. If you don't intend to upgrade to a system with Python 3.5 or 
> later by the end of security updates for Django 2.0 in April 2019, stick with 
> Django 1.11 LTS which is supported until April 2020."
> 
> I'd rather not allow Python 3.4 users to strand themselves on Django 2.0 when 
> sticking with 1.11 would provide longer security support (lesson learned from 
> Python 2.6 users stranded on Django 1.6), but hopefully documenting this 
> danger will help prevent that this time around.
> 
> On Saturday, January 7, 2017 at 6:30:23 AM UTC-5, Daniele Procida wrote:
> On Sat, Jan 7, 2017, Florian Apolloner  
> wrote: 
> 
> >Not sure on how we'd put that into text, but something along the lines of 
> >"we will support 3.4+ as long as feasible for us to do so" -- though I do 
> >understand that this is like the same as saying: "We'll just support what 
> >we want, how long we want" :D 
> 
> For the purposes of being reassuring, it needs to be concrete, otherwise 
> we're just moving people's doubt and uncertainty around! 
> 
> 
> It seems reasonable that Django 2.0 should continue to support Python 3.4, 
> and that Django 2.1 should not. That provides

Re: Adding a middleware to match cookies

2017-01-07 Thread Tobias McNulty 
On Jan 7, 2017 11:41 PM, "Jeff Willette"  wrote:

the specific case I am talking about deals with google analytics cookies,
which are different for every user and sent with the request. When
accessing request.user, I really only care about sessionid and csrftoken,
if present. So sending a vary by cookie header back will cause all the
unauthed/unsessioned users to miss the cache because of the GA cookies.

Since I have no use for these cookies in my code, and they are only used
for external requests to GA, eliminating them somewhere (earlier the
better) should improve cache hits, right?


Perhaps, but the place to do that is in your edge cache servers, not Django:

* http://www.varnish-cache.org/docs/3.0/tutorial/cookies.html
* https://web.archive.org/web/20151031024029/https://www.fastl
y.com/blog/how-to-cache-with-tracking-cookies

I'm unclear how feasible this is (I've never tried it). It's with noting
the last page isn't even on Fastly's public site anymore.

In any event, I'm not seeing the case for a change to Django proper here.
If Django's cache middleware is the only cache you're using, you might be
able to accomplish something like the above via middleware, as Carl
suggested.

If you're looking for assistance with the middleware implementation, I
recommend the django-users list. If you're using a another cache in front
of Django, you'll need to figure how to implement this there, or find a
simpler route such as never setting the tracking cookies in the first
place, or splitting the request in two.

Good luck!

Tobias

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

Re: Adding a middleware to match cookies

2017-01-07 Thread Jeff Willette 
the specific case I am talking about deals with google analytics cookies, 
which are different for every user and sent with the request. When 
accessing request.user, I really only care about sessionid and csrftoken, 
if present. So sending a vary by cookie header back will cause all the 
unauthed/unsessioned users to miss the cache because of the GA cookies.

Since I have no use for these cookies in my code, and they are only used 
for external requests to GA, eliminating them somewhere (earlier the 
better) should improve cache hits, right?

On Saturday, January 7, 2017 at 8:25:10 PM UTC+9, Florian Apolloner wrote:
>
> Hi Jeff,
>
> On Saturday, January 7, 2017 at 3:50:56 AM UTC+1, Jeff Willette wrote:
>>
>> What if there was an optional middleware early in the request processing 
>> that matched cookies based on a regex in settings and then modified the 
>> header to only include the matched cookies? 
>>
>
> I do not see how this would help -- you'd still have to set "Vary: Cookie" 
> on the response as soon as you are accessing request.user. Or is the goal 
> of this to allow Django's internal page caching stuff to ignore some 
> cookies? That seems doable, but very very dangerous.
>
> This issue reminds me of another issue I came up with (or as Carl puts it: 
> "…presenting the hypothetical case that exposed this bug."), namely 
> https://code.djangoproject.com/ticket/19649 -- Basically as soon as 
> Django accesses __any__ cookie we should set "Vary: Cookie", with all the 
> downsides this entails. I think we finally should fix that and put a fix 
> for it into the BaseHandler.
>
> What would be great would be an HTTP header which allowed for something 
> ala "Cache: if-request-did-not-have-cookies" -- usually it is pointless to 
> cache __anything__ with cookies anyways. That said, with all the analytics 
> super cookies out there, there are not many pages without cookies anymore :(
>

-- 
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/7d443c5e-5f70-421f-a44c-82dd6d71e477%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - January 7, 2017

2017-01-07 Thread Tim Graham 


Triaged

---

https://code.djangoproject.com/ticket/27675 - Django postgres JSONField 
encoding (needsinfo)

https://code.djangoproject.com/ticket/27679 - Document that empty formsets 
display min_num+extra forms (accepted)

https://code.djangoproject.com/ticket/27690 - remove sleep before dropping 
test db (accepted)

https://code.djangoproject.com/ticket/27687 - Dateformat issue using django 
basic logging formatter (invalid)

https://code.djangoproject.com/ticket/27664 - Manager.contribute_to_class() 
is called with abstract model rather than concrete model (needsinfo)

https://code.djangoproject.com/ticket/27677 - Disable savepoint support for 
MySQL NDB engine tables, and option to overwrite the default. (wontfix)

https://code.djangoproject.com/ticket/27684 - Migrations accept default 
value for DateField that are not portable to all backends (duplicate)

https://github.com/pallets/jinja/issues/640 - Regression: can't reuse a 
variable name in a {% for %} loop (created)


Authored

--

https://github.com/django/django/pull/7806 - Fixed #27698 -- Added 
django.test.utils.ContextList.get()

Reviewed/committed

--

https://github.com/django/django/pull/7774 - Refs #27637 -- Fixed 
timesince, timeuntil on New Year's Eve in a leap year.

https://github.com/django/django/pull/7595 - Fixed #27522 -- Fixed 
runserver autoreload when using staticfile's options.

https://github.com/django/django/pull/4889 - Fixed #25004 -- Updated 
OpenLayers-based widget to OpenLayers 3

https://github.com/django/django/pull/7787 - Fixed #27681 -- Fixed binary 
&/| operators for negative values on MySQL.

https://github.com/django/django/pull/6660 - Fixed #26621 -- Corrected 
simplify_regex()'s handling of named capture groups.

https://github.com/django/django/pull/7770 - Fixed #25912 -- Added binary 
left/right shift operators to F expressions.

https://github.com/django/django/pull/7769 - Refs #15667 -- Removed 
trailing newline from widget attrs.html template.

https://github.com/django/django/pull/7767 -  Fixed #27658 -- Prevented 
collectstatic from overwriting newer files in remote storages.

https://github.com/django/django/pull/7724 - Fixed #24423 -- Reorganized 
i18n tag tests.
https://github.com/django/django/pull/7522 - Fixed #27432 -- Made app_label 
arguments limit showmigrations --plan output.

-- 
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/24a5c096-ad48-4027-84b6-f41a66098825%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a middleware to match cookies

2017-01-07 Thread Carl Meyer 
On 01/07/2017 03:25 AM, Florian Apolloner wrote:
> On Saturday, January 7, 2017 at 3:50:56 AM UTC+1, Jeff Willette wrote:
> 
> What if there was an optional middleware early in the request
> processing that matched cookies based on a regex in settings and
> then modified the header to only include the matched cookies?
> 
> 
> I do not see how this would help -- you'd still have to set "Vary:
> Cookie" on the response as soon as you are accessing request.user. Or is
> the goal of this to allow Django's internal page caching stuff to ignore
> some cookies? That seems doable, but very very dangerous.

Right, the latter is how I understood it; you'd still use Vary: Cookie,
but strip some cookies before the request reaches the cache middleware.

I don't think it's too dangerous, if you're conservative about the
cookies you strip (e.g. only strip cookies that are known for sure to be
unused on the server, like Google Analytics cookies for instance.)

> 
> This issue reminds me of another issue I came up with (or as Carl puts
> it: "…presenting the hypothetical case that exposed this bug."), namely
> https://code.djangoproject.com/ticket/19649 -- Basically as soon as
> Django accesses __any__ cookie we should set "Vary: Cookie", with all
> the downsides this entails. I think we finally should fix that and put a
> fix for it into the BaseHandler.

+1

> What would be great would be an HTTP header which allowed for something
> ala "Cache: if-request-did-not-have-cookies" -- usually it is pointless
> to cache __anything__ with cookies anyways. That said, with all the
> analytics super cookies out there, there are not many pages without
> cookies anymore :(

+1. Basically analytics have already effectively broken HTTP caching as
it was designed to work.

Carl

-- 
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/709febeb-8336-aafa-7faa-74d1e2b46802%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Adding a middleware to match cookies

2017-01-07 Thread Carl Meyer 
On 01/06/2017 11:26 PM, Jeff Willette wrote:
> Wy would this not help the efficiency of the downstream caches? Is it
> because the request has already passed through them with the cookies
> intact? and when it comes back through the response they have no way to
> know they have been stripped?

That's correct. Stripping cookies from the request in Django is far too
late to have any effect on an external cache. If the request has reached
Django, then it's already passed through any external caching proxies,
with all cookies, and the cache has already decided not to serve a
cached response. (And if the cache holds on to the response, it'll
associate with the the request it saw, which still had all its cookies).

Carl

-- 
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/d1383be4-749e-3183-4354-ac0047bd0517%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: django-formtools is neglected/unmaintained

2017-01-07 Thread Tim Graham 
django-formtools 2.0 is now available on PyPI.

On Thursday, January 5, 2017 at 5:29:43 AM UTC-5, Romain Garrigues wrote:
>
> Hi guys,
>
> I'm currently investing some efforts to clean and make some django 
> packages up-to-date.
> After django-dirtyfields (https://github.com/romgar/django-dirtyfields), 
> I'm now beginning to work on django-model-utils (
> https://github.com/carljm/django-model-utils) where there is some work to 
> update it, but after this, and if nobody else had enough time to have a 
> look, I can try to contribute on django-formtools.
>
> Romain.
>
> Le mercredi 4 janvier 2017 23:20:40 UTC, eric@datalyticsolutions.com 
> a écrit :
>>
>> Thanks a lot, Tim! If you think I could help, then let me know. 
>> Otherwise, I'll just stay out of your way :)
>>
>> On Wednesday, January 4, 2017 at 4:02:29 PM UTC-7, Tim Graham wrote:
>>>
>>> According to https://github.com/django/django-formtools/issues/75, 
>>> there's a change in master that's needed for 1.10 compatibility.
>>>
>>> I'll try to do a release if I can get access to the PyPI record. I 
>>> pinged the owner (jezdez) in #django-dev about it.
>>>
>>> On Wednesday, January 4, 2017 at 5:51:56 PM UTC-5, Adam Johnson wrote:

 1) Tim added testing on Django 1.10 in July 2016, it seems to work? 
 https://github.com/django/django-formtools/commits/master
 2) New contributors are always welcome
 3) I don't know of other packages, you can check 
 https://djangopackages.org/
 4) It's true that many websites are built with pure JS frontends these 
 days, there are probably more recently developed tools there

 On 4 January 2017 at 22:42,  wrote:

> Hi Tim,
>
> You make some good points. Basically, my situation is that I want to 
> use some features of Django v1.10 for a project at my company, but I am 
> unable to because I use django-formtools for a FormPreview, and it is not 
> compatible with v.1.10. I am also worried about using Django for future 
> projects given that there seem to be problems finding people to 
> contribute 
> to what seems to be an important package. Whether I contribute depends on 
> the answers to several questions: (1) How much work is necessary to get 
> formtools compatible with v1.10? (2) Would my contribution make a 
> difference, given that I would be a new contributor, and I don't have a 
> ton 
> of time to give? (3) Is there another package that people are using for 
> FormPreviews that I'm not aware of? I couldn't find anything else that 
> was 
> more up-to-date than django-formtools. (4) Is this a sign that people 
> simply aren't using Django for this task, and are maybe instead using 
> some 
> kind of Javascript library instead? If you have any information these 
> questions, please let me know.
>
> Thanks,
> Eric
>
> On Tuesday, January 3, 2017 at 6:04:59 PM UTC-7, Tim Graham wrote:
>>
>> Is the situation bad enough that you would volunteer to maintain the 
>> project?
>>
>> The Django team is a collection of volunteers (excepting me) who work 
>> on Django. It seems that no one on the team or reading this mailing list 
>> has time or interest in maintaining the project. We need to clarify the 
>> maintenance status, but that doesn't necessarily mean continuing the 
>> project in its current form if there's little interest.
>>
>> Absent volunteers, another idea could be for an interested freelancer 
>> to start a kickstarter-style fundraiser to raise money to fund some time 
>> to 
>> work on some issue in the backlog. At least it would help determine if 
>> any 
>> users think the project is worth paying for.
>>
>> On Tuesday, January 3, 2017 at 7:28:59 PM UTC-5, 
>> eric@datalyticsolutions.com wrote:
>>>
>>> This is really bad. django-formtools used to be part of the core of 
>>> Django. Is this getting the attention it deserves from the Django 
>>> Foundation?
>>>
>>> On Monday, November 28, 2016 at 9:55:48 PM UTC-7, Asif Saifuddin 
>>> wrote:

 Hi Tim,

 In case there is lack of active maintainers for the project then 
 you could add me to the list of maintainers. I do contribute to django 
 eco 
 system regularly.

 my github activities:

 github.com/auvipy


 And about moving to jazzband, I do take part in django-admin2 
 maintenance there with the two other old maintainers, The fact is 
 moving it 
 to jazzband haven't increased the active co maintainers.

 Thanks,

 Asif

 On Tuesday, November 29, 2016 at 5:45:59 AM UTC+6, Tim Graham wrote:
>
> Hi,
>
> django-formtools seems neglected. It's been

Presenting DCP, a compatibility layer for Django (feedback welcome)

2017-01-07 Thread Pkl 

Hello,

I've *at last* had some time to experiment with the idea I had thrown years 
again, of a system to workaround the recurring breakages introduced by new 
django releases, breakages which sometimes lead to unreconcilable 
requirements between django apps.

After a sprint at PyconFR, with a colleague (R. Gomès), and some cleanups 
and improvements, here it is:

https://github.com/pakal/django-compat-patcher  (also known as DCP)
https://pypi.python.org/pypi/django-compat-patcher

The philosophy of the module is that, with extremly agile languages such as 
python, one doesn't have to choose between a fast-moving project, and a 
compatibility-friendly project.
So, in an approach reminding "aspect oriented programming", DCP separates 
the Django codebase, which may move forward and be left mostly free of 
compatibility shims, from retrocompatibility shims ; and changing the 
"level of compatibility" of a project is just the matter of tweaking some 
Django settings.
Since, as usual, "explicit is better than implicit", logging and code 
warnings are used to ensure that project users are informed about what 
compatibility fixers are applied, and how project dependencies are rated 
deprecation-wise.

I've noticed there had been debates and evolutions for the past years, 
until the switch to a "lax semantic versioning" for Django. 
Surely it's an effort in the right direction, but I guess I'm not the only 
one worried by the "lax" adjective ; especially after the long history of 
breakages occurring for quite cosmetic reasons (eg. the removal of 
urlpatterns(), which broke most django apps available, whereas dotted-path 
URLs were rather harmless).
That's why I think DCP is still relevant, as it gives back some control 
over compatibility to end users of Django ; and it should remove part of 
the apprehension some may have known too, when installing a new Django 
version.

DCP has been successfully used to upgrade wide projects from django 1.7 to 
django 1.10, with no hassle. But more feedback would be nice, before it can 
be marked "production ready".
The project welcomes patches, especially new backward/forward compatibility 
fixers one might need.


*Apart from that *: I think many people could benefit from more 
instructions about how to handle (backwards and forwards) compatibility, so 
here are some ideas I had :


*1) Advertising compatibility systems for Django, in the official docs.*

That is to say, packages like "django-compat" (which I only discovered 
lately), dedicated to library developers who need a wide compatibility.
And packages like "django-compat-patcher" for project maintainers who have 
compatibility issues and deadlines (it's not *always* the right moment to 
fork and patch a bunch of big dependencies).
All that would come in addition to the docs now mentioning "how to support 
2 LTS versions at a time".
These measures might diminish the number of django app using handmade 
compatibility shims, or completely ignoring previous versions of django.


*2) Pushing a compatibility system like DCP into Django itself*

What would be the gain ? It would pleasantly reduce the work needed for 
Django evolutions.

At the moment, first compatibility shims must be introduced, and 
specifically tested in code ; then these compatibility shims must be 
removed, and their tests with them.

With a separate compatibility system, only half the work would be needed : 
once the code has been modified, the old version is moved to a fixer, and 
its associated unit-test is moved to the compatibility system test suite. 
The activation/deactivation of this particular fixer is then only a matter 
of django settings, not of new code commits.
Most importantly, this way, django main tests suites  would stop making 
asserts on the presence or absence of deprecation warnings (which is a way 
of mixing unrelated aspects of the framework). Django tests suites could 
thus be leveraged by compatibility systems to ensure that the whole system 
is well sane and backwards/forward compatible, whatever the series of 
django shims applied.


*Any remarks about DCP concept itself, or about suggestions for doc/core 
inclusions ?*

thanks,
regards,
Pascal

-- 
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/37750f9b-d5e4-4216-a510-546502c084c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Template handling of undefined variables

2017-01-07 Thread Tim Martin 
On Friday, 6 January 2017 10:15:22 UTC, Alasdair Nicol wrote:
>
> Hi,
>
> On Thursday, 5 January 2017 17:51:39 UTC, Tim Martin wrote:
>>
>>
>>
>> On Thursday, 5 January 2017 04:15:31 UTC, Carl Meyer wrote:
>>>
>>> Hi Tim, 
>>>
>>> On 01/04/2017 03:39 PM, Tim Martin wrote: 
>>>  
>>> > 1) There are test cases where we have templates that should treat "x 
>>> >is y" as True where x and y are both undefined. 
>>>
>>> Really? Is this an accidental side effect of some historical change, or 
>>> really the intent of the test? That behavior seems buggy to me; more 
>>> likely to be a bug-magnet than useful. 
>>>
>>
>> There are a couple of test cases in test_if.py: 
>> test_if_is_both_variables_missing and 
>> test_if_is_not_both_variables_missing. These are verifying this specific 
>> case, so they haven't been introduced by accident. I haven't got as far as 
>> figuring out whether it was a fully thought through decision or whether 
>> someone just created these cases for completeness.
>>
>
> I added the tests in ticket 26479 (see comment 5 onwards) [1]. I believe I 
> added them for consistency with == and != operators, which have similar 
> tests [2], [3] (trickier to spot because they are numbered). I apologise if 
> adding the tests has made it harder to improve the behaviour of the tag. 
>

Thanks for the background info Alasdair, that saved me lots of time hunting 
around.

I agree you were right to add the tests, which were useful since without 
them I wouldn't have realised the potential behaviour change I was 
introducing. As I see it, these tests don't in themselves form a reason not 
to change the behaviour (since AIUI you originally added them for 
completeness, rather than because this specific behaviour was desired).

Does anyone think changing the behaviour of {% if a is None %} is the wrong 
thing to do? I realise there can potentially be template code out there 
relying on this, but after a quick scout through the documentation I can't 
see anywhere that the behaviour on undefined variables is specified 
officially.

For what it's worth, the same issue doesn't come up with ==, because 
although the existing template behaviour has the same pattern, it's 
possible to override == and != so that the Undefined object gives the same 
behaviour as None did before. It's only for 'is' that this can't be 
achieved. I don't know how for to go with this: preserving the existing == 
behaviour but changing it for 'is' leaves the two operations superficially 
inconsistent (though there's nothing fundamentally wrong with two things 
that satisfy equality but not 'is'). I can see a couple of alternatives (in 
all cases all variables are undefined):

* "x is y" is false, but "x == y" is true and "x != y" is false (minimal 
difference from the current behaviour)
* "x is y" and "x == y" are both false, "x != y" is true (probably the most 
mutually consistent?)
* "x is y", "x == y" and "x != y" are all false (the SQL NULL alternative - 
I'm not sure if I like this, but it has the merit that wrongly skipping 
sections of a template is usually less bad than wrongly including parts of 
a template)

Tim
 

-- 
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/d1b0879b-5514-4fc7-8abf-a38710e00efe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.0 Python version support (Python 3.6+ only?)

2017-01-07 Thread Tim Graham 
Daniele, here's my try at being more concrete than "It seems reasonable" 
and "decent ledge of overlap". Let me know if you meant something different!

"Django 2.0 will be the last version of Django to support Python 3.4. This 
allows those running older operating systems with Python 3.4 (such as 
Ubuntu 14.04 and CentOS 6) to use the latest version of Django for an 
additional eight months. If you don't intend to upgrade to a system with 
Python 3.5 or later by the end of security updates for Django 2.0 in April 
2019, stick with Django 1.11 LTS which is supported until April 2020."

I'd rather not allow Python 3.4 users to strand themselves on Django 2.0 
when sticking with 1.11 would provide longer security support (lesson 
learned from Python 2.6 users stranded on Django 1.6), but hopefully 
documenting this danger will help prevent that this time around.

On Saturday, January 7, 2017 at 6:30:23 AM UTC-5, Daniele Procida wrote:
>
> On Sat, Jan 7, 2017, Florian Apolloner  
> wrote: 
>
> >Not sure on how we'd put that into text, but something along the lines of 
> >"we will support 3.4+ as long as feasible for us to do so" -- though I do 
> >understand that this is like the same as saying: "We'll just support what 
> >we want, how long we want" :D 
>
> For the purposes of being reassuring, it needs to be concrete, otherwise 
> we're just moving people's doubt and uncertainty around! 
>
>
> It seems reasonable that Django 2.0 should continue to support Python 3.4, 
> and that Django 2.1 should not. That provides a decent ledge of overlap for 
> those climbing up these tricky upgrade paths to rest on and catch their 
> breath. 
>
> Daniele 
>
>

-- 
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/68cfdafc-730c-42bb-a772-4f17193645f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.0 Python version support (Python 3.6+ only?)

2017-01-07 Thread Florian Apolloner 
On Saturday, January 7, 2017 at 4:03:43 AM UTC+1, Tim Graham wrote:
>
> I don't know if matters to anyone, but I guess as long as we support 
> Python 3.4 we can't do the type hinting project (PEP 484) since that's new 
> in 3.5?
>

I do not think this matters, first off there is no commitment from our side 
on type hinting or anything. We do not have any DEP or something related 
and didn't even discuss if we actually want type hinting. Personally I am 
kinda against it anyways, since it clutters the code for not much gain. So 
if we were to do it, I would prefer stub files anyways, in which case we 
won't depend on any python version as far as I understood 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/040670a9-d2ad-4f97-9498-b28000b60396%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.0 Python version support (Python 3.6+ only?)

2017-01-07 Thread Daniele Procida 
On Sat, Jan 7, 2017, Florian Apolloner  wrote:

>Not sure on how we'd put that into text, but something along the lines of 
>"we will support 3.4+ as long as feasible for us to do so" -- though I do 
>understand that this is like the same as saying: "We'll just support what 
>we want, how long we want" :D

For the purposes of being reassuring, it needs to be concrete, otherwise we're 
just moving people's doubt and uncertainty around!


It seems reasonable that Django 2.0 should continue to support Python 3.4, and 
that Django 2.1 should not. That provides a decent ledge of overlap for those 
climbing up these tricky upgrade paths to rest on and catch their breath.

Daniele

-- 
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/20170107113010.1464403373%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.0 Python version support (Python 3.6+ only?)

2017-01-07 Thread Florian Apolloner 
Not sure on how we'd put that into text, but something along the lines of 
"we will support 3.4+ as long as feasible for us to do so" -- though I do 
understand that this is like the same as saying: "We'll just support what 
we want, how long we want" :D

On Friday, January 6, 2017 at 2:33:24 PM UTC+1, Tim Graham wrote:
>
> So you all want to do a one time exception to our guidance of of 
> "Typically we will support a Python version up to and including the first 
> Django LTS release whose security support ends after security support for 
> that version of Python ends." and support Python 3.4 for how long? Or 
> revise the guidance?
>
> On Friday, January 6, 2017 at 8:16:02 AM UTC-5, Daniele Procida wrote:
>>
>> On Fri, Jan 6, 2017, Florian Apolloner  wrote: 
>>
>> >In the end (in my experience), people are using Django everywhere and 
>> part 
>> >of the usage also comes from the fact that it's not that hard to deploy 
>> for 
>> >sysadmins since python is available anywhere; compiling a new Python + 
>> >infrastructure around it is something else again and requires a lot of 
>> >change requests in some companies. 
>>
>> In practical terms it makes a big difference. Remember <
>> https://groups.google.com/forum/#!topic/django-developers/qCjfOu-FPxQ/discussion>,
>>  
>> that prompted a change of LTS policy? 
>>
>> *Anything* that makes the transition easier is to be welcomed, and that 
>> doesn't just mean technically easier, it also means easier to think about 
>> and to talk about to project managers and clients and web project owners. 
>>
>> Reassurance in time of change counts for a great deal. When someone gets 
>> to spend a day or two basking in the glory of a top item on Hacker News 
>> because he wrote a "Don't go to Python 3" article, there is clearly some 
>> reassuring to be done. 
>>
>> If the technical cost of supporting 3.4 in Django 2.0 is not too high, I 
>> feel it would be valuable to have it. 
>>
>> The actual technical justification for keeping it may be weak, but 
>> barriers to adoption are not always technical ones anyway, and my 
>> preference would be to keep them as low as possible. 
>>
>> Daniele 
>>
>>

-- 
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/616e0309-0119-4269-85b0-a48e421a563a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a middleware to match cookies

2017-01-07 Thread Florian Apolloner 
Hi Jeff,

On Saturday, January 7, 2017 at 3:50:56 AM UTC+1, Jeff Willette wrote:
>
> What if there was an optional middleware early in the request processing 
> that matched cookies based on a regex in settings and then modified the 
> header to only include the matched cookies? 
>

I do not see how this would help -- you'd still have to set "Vary: Cookie" 
on the response as soon as you are accessing request.user. Or is the goal 
of this to allow Django's internal page caching stuff to ignore some 
cookies? That seems doable, but very very dangerous.

This issue reminds me of another issue I came up with (or as Carl puts it: 
"…presenting the hypothetical case that exposed this bug."), namely 
https://code.djangoproject.com/ticket/19649 -- Basically as soon as Django 
accesses __any__ cookie we should set "Vary: Cookie", with all the 
downsides this entails. I think we finally should fix that and put a fix 
for it into the BaseHandler.

What would be great would be an HTTP header which allowed for something ala 
"Cache: if-request-did-not-have-cookies" -- usually it is pointless to 
cache __anything__ with cookies anyways. That said, with all the analytics 
super cookies out there, there are not many pages without cookies anymore :(

-- 
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/91d681aa-2bf2-46b5-820c-176a04b4499e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.0 Python version support (Python 3.6+ only?)

2017-01-07 Thread Daniel Moisset 
Type hinting can be done in python 3.x by depending on the typing module
(or inlining it). Type hinting for instance/class attributes will have a
much nicer syntax in python 3.6 only (PEP 526)

Best,
   D.

On 7 January 2017 at 03:03, Tim Graham  wrote:

> I don't know if matters to anyone, but I guess as long as we support
> Python 3.4 we can't do the type hinting project (PEP 484) since that's new
> in 3.5?
>
>
> On Friday, January 6, 2017 at 12:08:07 PM UTC-5, Tim Graham wrote:
>>
>> Tom, I'm not following how Python 3.4 support in Django 2.0 will benefit
>> you if you want to stick to LTS versions of Django? I think either you or I
>> have a misunderstanding somewhere. I'll try to recap:
>>
>> Django 1.11 is the next LTS. It's supported until April 2020 and supports
>> Python 3.4. The next LTS, Django 2.2 is due in April 2019, after the Python
>> 3.4 end of life in March 2019 -- so I don't think we can justify supporting
>> Python 3.4 in that LTS unless we decide to base our supported Python policy
>> on CentOS rather than Python's own support lifecycle. Florian and Daniele
>> are proposing supporting Python 3.4 for Django 2.0 and/or 2.1. Those
>> versions have security support ending in April 2019 and December 2019,
>> respectively. If you want to use Python 3.4 and maximize the time you can
>> receive Django security updates, stick with 1.11 LTS (April 2020).
>>
>> Look at these tables if you're in doubt:
>> https://www.djangoproject.com/download/#supported-versions
>> https://docs.python.org/devguide/#status-of-python-branches
>>
>> On Friday, January 6, 2017 at 11:22:17 AM UTC-5, Tom Evans wrote:
>>>
>>> On Thu, Jan 5, 2017 at 8:10 PM, Asif Saifuddin 
>>> wrote:
>>> > Hi,
>>> >
>>> > django 2.0 will be released in december 2017 and ubuntu 18.04 will be
>>> > released in april 2018 which will default atleast 3.6, so I think this
>>> > should also be taken as consideration while deciding.
>>>
>>> I know supporting endless versions of python is not desirable, but
>>> please bear in mind that some of us are in situations where what the
>>> latest release of Ubunutu is not really relevant.
>>>
>>> Our organisation uses CentOS 6, which is not EOL until the end of
>>> 2020. In CentOS 6, the stock version of python is python 2.6; we go
>>> through special measures (EPEL) to get that up to python 2.7. If we
>>> wanted to make the move to Python 3, we'd be talking about Python 3.4,
>>> again through EPEL.
>>>
>>> We have an infrastructure team responsible for provisioning servers,
>>> and it is on their schedule that OS upgrades occur - it is not easy
>>> for us as developers to argue that this team should spend significant
>>> resource to upgrade to a later OS version or to roll custom python
>>> RPMs.
>>>
>>> Updating all of our codebase to Python 3 is going to be a pain for us,
>>> it is hard to argue a business need with "Everything stays exactly the
>>> same but is slightly more secure and easier to maintain".
>>> Realistically, when we move to Python 3, it will be because the
>>> supported Django LTS requires it. If we also have to jump through lots
>>> of hoops to get the very latest Python 3 release, it won't make it
>>> easier to argue, it will mean we are more likely to postpone it and
>>> keep using old django versions, particularly on internal intranet
>>> sites.
>>>
>>> If there is a way that Python 3.4 support can be maintained without
>>> significant detriment or penalty, this would be greatly appreciated by
>>> those of us running more conservative enterprise distributions.
>>>
>>> Cheers
>>>
>>> Tom
>>>
>> --
> 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/680d3d55-a9d4-46d9-a587-
> c49649f24cbf%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Daniel F. Moisset - UK Country Manager
www.machinalis.com
Skype: @dmoisset

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