python 3.x
stefanoC
3.x ?
I found a few discussions talking about this, eg. and
http://groups.google.com/group/django-developers/browse_thread/thread/f8c747a26aa5d8ed/0749bfa67b47c802
and http://groups.google.com/group/django-developers/browse_thread/thread/bf9d8808ee5aadb4/40fc62ffdfc551ff?q=%22python+3%22&lnk=nl&
as well as this page: http://wiki.python.org/moin/PortingDjangoTo3k
So this question is not about the technical difficulties, rather about
the existance of an official planning for supporting python 3.x.
I guess i could formulate my question as: is there any url that tracks
plans and difficulties for django supporting python 3.x?
I am finding myself more an more interested into moving over python 3
- it brings several answers to some of my problems...
Russell Keith-Magee
> bumping an already old question, is django going to run on python
> 3.x ?
>
> I found a few discussions talking about this, eg. and
> http://groups.google.com/group/django-developers/browse_thread/thread/f8c747a26aa5d8ed/0749bfa67b47c802
> and http://groups.google.com/group/django-developers/browse_thread/thread/bf9d8808ee5aadb4/40fc62ffdfc551ff?q=%22python+3%22&lnk=nl&
> as well as this page: http://wiki.python.org/moin/PortingDjangoTo3k
>
> So this question is not about the technical difficulties, rather about
> the existance of an official planning for supporting python 3.x.
The short answer:
http://docs.djangoproject.com/en/dev/faq/install/#can-i-use-django-with-python-3
The longer answer:
We haven't published a formal plan -- mostly because in volunteer
projects, long term formal plans aren't worth the paper they aren't
printed on :-)
However, we are aware of the need to transition, and we do have an
informal plan to do so. In practical terms, it means dropping support
for Python 2.4 and 2.5 in successive releases of Django. Once we're at
a Django 2.6 minimum supported version, using 2to3 to maintain
parallel implementations becomes a lot easier.
The factor slowing progress is the rate at which we can deprecate
Python versions. This is largely driven by the Python versions that
are in the field and are commercially supported. At the moment, RedHat
Enterprise Linux is the laggard of the bunch; in order to support
RHEL, we need to support Python 2.4. Our own deprecation policy is
governed by the deprecation policies of the underlying operating
system platforms.
Effectively, this means that official support for Django under Python
3 is still a couple of years away.
Yours,
Russ Magee %-)
Jeremy Dunck
<rus...@keith-magee.com> wrote:
...
> Effectively, this means that official support for Django under Python
> 3 is still a couple of years away.
Fortunately, there is plenty to do preparing for this glorious day --
many commonly-used libraries which Django depends on directly, or
which are commonly used in Django apps (like feedparser,
BeautifulSoup, dateutils, etc.) need porting to python3. This is an
active need serving the larger Python community. Please consider
helping there.
Andy Kelley
By the way, does it bother anybody else that the home page of PIL says
"A version of 1.1.7 for 3.X will be released later" and the date for
1.1.7 is November 15, 2009?
On Sep 2, 9:45 am, Jeremy Dunck <jdu...@gmail.com> wrote:
Markus Gattol
It is actually so that with using __future__ and >=2.6 you already have
most of the things available from Python 3 e.g. print() rather than
print. See table at the bottom of
http://docs.python.org/dev/library/__future__.html#module-__future__
Sure, everybody is raving about Python 3 but 2.6 being the smallest
supported version with Django would already be a huge leap towards 3 I
think.
As Russell said, looks like RHEL is going to be the indicator as to when
things will move forward.
If I look at http://distrowatch.com/table.php?distribution=redhat
however and assume that RHEL 5.5 is going to be supported for quite some
time then I think it might be a long time until Django arrives at 2.6
being the smallest supported Python version.
How long are we going to plan supporting RHEL 5.5 and thus Python 2.4
after RHEL is out?
Gabriel Hurley
month ago:
http://groups.google.com/group/django-developers/browse_frm/thread/b7390024b28a694d/f72c272152e968d7
Russell's reply there spells it out as clearly as anyone will be able
to right now...
All the best,
- Gabriel
On Sep 3, 1:27 am, Markus Gattol <markus.gat...@sunoano.org> wrote:
> It is actually so that with using __future__ and >=2.6 you already have
> most of the things available from Python 3 e.g. print() rather than
> print. See table at the bottom of
>
> http://docs.python.org/dev/library/__future__.html#module-__future__
>
> Sure, everybody is raving about Python 3 but 2.6 being the smallest
> supported version with Django would already be a huge leap towards 3 I
> think.
>
> As Russell said, looks like RHEL is going to be the indicator as to when
> things will move forward.
>
VernonCole
maintain
parallel implementations becomes a lot easier."
statement is correct.
For a short time on the pywin32 team we tried to "maintain parallel
implementations" and found that it was a mistake we had to undo. The
correct approach is to maintain a SINGLE implementation -- in Python 2
format -- and use 2to3 as a tool when the code happens to be running
on Python 3+. 2to3 should be run by distutils when it detects that
setup.py is being run by Python3. It should NOT be run manually by a
human.
Then, some years in the future when the last Python 2.7 engine fades
away, you will run 2to3 once for the last time, and THEN maintain in
Python 3 format. You do NOT write your code with print() functions,
etc.. Simply roll any needed refactoring into the trunk at the
earliest opportunity, and make sure you don't break them during
maintenance.
That's my advice from my experience. The code I am supporting runs on
any version of Python from 2.3 thru 3.1, including IronPython.
--
Vernon Cole
stefanoC
while indeed it's clear django will not official run on 3.0 any soon,
it's clearer to me why & how.
yes I'm aware of __future__ import, though it's not really magic (eg.
support for bytes / unicode types is more of a compatibility thing,
for argparse python 2.7 minimum is necessary, etc.) but I'd rather
struggle with these things than without Django :-)
I'll see if there are ways for me to help...
cheers,
Stefano
Russell Keith-Magee
> "Once we're at a Django 2.6 minimum supported version, using 2to3 to
> maintain
> parallel implementations becomes a lot easier."
>
> As much as I admire Russ, and I do, I don't think that the above
> statement is correct.
My apologies -- in the haste of getting a response out, I was a little
lax in my choice of words. What you've described - i.e.,
* A single maintained 2.X source tree
* An auto-generated 3.X source tree,
* When 2.X support is dropped, the migration script is run one last
time to migrate the source tree to be 3.X
is pretty close to what I had in my head as the likely path. In
practice, I'm sure there will be some complications, but we won't
really know what they are until we get serious about 3.X support.
> For a short time on the pywin32 team we tried to "maintain parallel
> implementations" and found that it was a mistake we had to undo. The
> correct approach is to maintain a SINGLE implementation -- in Python 2
> format -- and use 2to3 as a tool when the code happens to be running
> on Python 3+. 2to3 should be run by distutils when it detects that
> setup.py is being run by Python3. It should NOT be run manually by a
> human.
>
> Then, some years in the future when the last Python 2.7 engine fades
> away, you will run 2to3 once for the last time, and THEN maintain in
> Python 3 format. You do NOT write your code with print() functions,
> etc.. Simply roll any needed refactoring into the trunk at the
> earliest opportunity, and make sure you don't break them during
> maintenance.
>
> That's my advice from my experience. The code I am supporting runs on
> any version of Python from 2.3 thru 3.1, including IronPython.
It's good to know that there are people in the community that have
done this in anger on other projects. If anyone can provide patches
for refactors that are necessary in order to simplify the 3.X
migration process, I'm happy to apply those patches -- and as I
indicated, I already have applied a couple of patches for exactly this
reason; for example changeset 13509 was to change the way we use
sorting functions to avoid a keyword argument that has been deprecated
for 3.X.
Yours,
Russ Magee %-)
VernonCole
It has the same syntax as CPython 2.6/2.7, but ALL text strings are in
unicode, just like in Python 3.x. 8-bit byte arrays must be declared
as such. I suspect that about half of the problems with Python 3
conversion will be in that very area.
To handle str vs unicode differences, I use...
<code>
def str2bytes(sval):
""" convert a string literal to a byte array """
if sys.version_info < (3,0) and isinstance(sval, str):
sval = sval.decode("latin1")
return sval.encode("latin1")
if sys.version[0] >= '3': #python 3.x
StringTypes = str
makeByteBuffer = bytes
memoryViewType = memoryview
_BaseException = Exception
else: #python 2.x
from exceptions import StandardError as _BaseException
memoryViewType = type(buffer(''))
makeByteBuffer = buffer
try: #jdhardy -- handle bytes under IronPython
bytes
except NameError:
bytes = str
StringTypes = (str,unicode) # will be messed up by 2to3 but never
used
</code>
Perhaps something in that same spirit should be adopted as a standard
"drop in" for modules which are being converted?
That would keep everyone doing such patches on the same page.
--
Vernon
On Sep 7, 12:01 am, Russell Keith-Magee <russ...@keith-magee.com>
wrote: