I prefer Proposal 2 out of the list, and regarding Russell's point I
believe that the tutorial ought to promote Python 3 and be written from
that perspective with Python 2 exceptions - because exactly of Django's
importance in the Python landscape.
Thanks and good day.
On 09/08/2012 19:35, Russell Keith-Magee wrote:
On Fri, Aug 10, 2012 at 4:58 AM, charettes <charett...@gmail.com> wrote:
I think this will only be an issue for django application maintainers.
IMHO, projects target a specific version of python and won't have to provide
python 2-3 compatibility. Am I wrong?
Yes and no.
On the one hand -- yes. Jo(sephin)e Public is here to write some code,
and it's going to be for their own purposes, which means they've
already picked a Python version, and so making their code
cross-version isn't important.
However, on the other hand, if you're "doing it right™", *every* app
is a reusable app, and teaching best practices is important. Like it
or not, Django is a major part of the Python ecosystem, and a lot of
people look at us as an example of what best practices look like.
My suggestion would be to look at a fifth option. Lets remember that
this is a training exercise, and for many of our user base, this is
their first exposure to Python. If we overload complexity in the
basics, they're going to come to the conclusion that Python is nasty
and horrible.
So - let's write the initial tutorials targeting a specific version,
but provide hints/directions indicating that there is a bigger picture
to consider:
a) There should also be an aside at the start of section 1 of the
tutorial quickly explaining the Python version landscape to those that
aren't familiar with it, and explaining how the tutorial will handle
this landscape.
b) Write the docs as Py2, with "Py3 admonition" whenever there's a
difference between the two. I haven't done a full audit of the
tutorial, but there shouldn't be *too* many of these.
c) Add a new tutorial section indicating how to write cross-version
Python. For that document, I agree that Aymeric's option 2 looks
attractive, because it's the version that is the easiest to clean up
when the time comes to deprecate Py2 (although I wouldn't complain if
we packaged a pre-canned version of the lambda function in
django.utils)
Over time, we could change the primacy of the docs from Py2 native
(with Py3 warnings) to Py3 native (with Py2 warnings), until we
finally deprecate Py2.
In the interest of keeping the tutorial clear, I *might* be convinced
to drop step (b) entirely. This would mean we still have a Py2
tutorial, but with a couple of clear pointers towards best practices
(one indicating that there is a bigger picture to consider, and one
showing how to paint that picture). However, that would leave native
Py3-only users high and dry, which isn't exactly ideal.
Yours,
Russ Magee %-)
--
Daniel Sokolowski
Web Engineer
Danols Web Engineering
http://webdesign.danols.com/
Office: 613-817-6833
Fax: 613-817-5340
Toll Free: 1-855-5DANOLS
Kingston, ON K7L 1H3, Canada
Notice of Confidentiality:
The information transmitted is intended only for the person or entity to which
it is addressed and may contain confidential and/or privileged material. Any
review re-transmission dissemination or other use of or taking of any action in
reliance upon this information by persons or entities other than the intended
recipient is prohibited. If you received this in error please contact the
sender immediately by return electronic transmission and then immediately
delete this transmission including all attachments without copying distributing
or disclosing same.
--
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.
