Here's a documentation proposal: https://github.com/django/django/pull/5783
On Saturday, December 5, 2015 at 6:42:18 PM UTC-5, Tim Graham wrote:
>
> No we haven't done that before. I think advertising it in the blog post
> and release notes would be enough. In particular, I'd like to advertise
No we haven't done that before. I think advertising it in the blog post and
release notes would be enough. In particular, I'd like to advertise it as a
tentative plan just in case someone comes along after we advertise the plan
more widely and offers a compelling reason to continue Python 3.2
Do we currently raise any warnings/exceptions in cases where Python support
has / or is about to be dropped (particularly mid LTS).. As a suggestion,
I was thinking it could be helpful to people affected we raised exception
msg indicating the last Django version to support their current
Donald could probably provide more information, but this post from April
shows the Python 3.2 numbers downloading from PyPI are constant, and pretty
small [https://caremad.io/2015/04/a-year-of-pypi-downloads/] His take was
that CI systems (like Django's!) were doing most of the Python 3.2 package
I agree with Tim. Unless someone puts their hand up to say they definitely
require python 3.2 support for 1.8, I think it makes sense to drop support
in the next dot release of 1.8. 3.2 isn't an easy python to find in the
wild as far as I know, so I'd be surprised if there was any real support
No, using pypy3 doesn't make things easier. There are a handful of test
failures with pypy3 and it doesn't solve the issue that
unittest-xml-reporting doesn't work with Python 3.2.
Issues aside, the main thing I'm trying to find out is, are we providing
any substantial value supporting Django
On Wednesday 02 December 2015 21:05:00 Tim Graham wrote:
>
> Given that no one reading this indicated that they plan a long-term
> deployment of Python 3.2, how about if in the next 1.8.x release we
> advertise that Python 3.2 support for Django 1.8 will end January 1, 2017?
> (we won't break
I ran into another snag trying to put the Python 3.2 tests on the 14.04
machines and that's that the unittest-xml-reporting package we use on
Jenkins to collect the test results isn't compatible with Python 3.2 (the
Ubuntu 12.04 machine uses an older fork of unittest-xml-reporting but I
> On Nov 26, 2015, at 9:50 AM, Tim Graham wrote:
>
> The thing that makes me a little uncomfortable is promoting the use of
> possibly insecure Python 3.2 well after it's end-of-life. I guess there might
> be some Linux distributions that will backport security fixes to
The thing that makes me a little uncomfortable is promoting the use of
possibly insecure Python 3.2 well after it's end-of-life. I guess there
might be some Linux distributions that will backport security fixes to
their own versions of Python 3.2, but it seems that Ubuntu 12.04's version
of
Hello Tim,
Did you consider marking affected tests as expected failures on Python
3.2.6?
I've done that on one of my projects which faced this exact issue (or a
closely related one):
https://github.com/aaugustin/myks-gallery/blob/master/gallery/test_admin.py#L199-L205
Best regards,
--
Hi,
Am Wed, 25 Nov 2015 16:36:52 -0800 (PST)
schrieb Tim Graham :
> b. Install the latest non-broken Python 3.2 release (3.2.5)
> "manually" (without using deadsnakes) on the newer CI servers
While it would only really hurt the people in charge with the bugfix
releases, as
2015-11-26 5:22 GMT+01:00 Asif Saifuddin :
> Python 3.2 should be removed as if any one use py3 should use 3.3+ or
> better the latest stable.
>
Hi Asif,
Your email sounds like the answer is obvious. It doesn't show that you
thought about the use cases, especially those you
Python 3.2 should be removed as if any one use py3 should use 3.3+ or
better the latest stable.
best
Asif
On Thursday, November 26, 2015 at 6:36:53 AM UTC+6, Tim Graham wrote:
>
> Django 1.8 is the last version to support Python 3.2. Python 3.2 is
> scheduled to be end of life at February
14 matches
Mail list logo