"Martin v. Löwis" <ma****@v.loewi s.dewrites:
>I'm surprised to read this:
http://en.wikipedia.org/wiki/Python_3
"""Note that while there is no explicit requirement that code be able
to run unmodified in both versions, in practice it is quite likely for
most code. As of January 2007, it looks like most reasonable code
should run quite well under either branch."""
It's difficult to predict the future, but I think this statement is
a fair description.
>>
I haven't been following Python 3 development recently. Have things
really changed that much? Last time I looked, e.g. dict.items() no
longer returned a list.
Correct.
>Seems unlikely that most code will run on 2
and 3, in that case,
Why that? Most reasonable code doesn't care what dict.items returns,
as it reads like
for k,v in dict.items():
do_something_wi th(k,v)
We could discuss that. However, my example wasn't really intended to
relate strictly to that technical feature. Rather, to the intent of
the Python 3 developers, as suggested by things like that change, and
by what they've said over the last year or so (I think I've seen that
specific change used several times by people explaining that 2.6 / 3.0
compatibility will be impractical, which is why I chose it).
>and IIUC Guido has said all along that not much
code will run on both.
I think you misunderstood. It's not a design goal that code works
without modifications, yet most reasonable code will even without
that being an explicit goal.
I think the design goals have been fairly clear. What hasn't been
clear (to me, at least) is the practical question of the feasibility
of code working unchanged on both 2.6 and 3.0.
http://www.python.org/dev/peps/pep-3000/
"""There is no requirement that Python 2.6 code will run unmodified on
Python 3.0. Not even a subset. (Of course there will be a tiny subset,
but it will be missing major functionality.) """
Though certainly neither quote is precise enough to pin it down
formally, certainly the tone of the first quote (from the Wikipedia
article) to my ear makes it sound like (at minimum!) it will be
practical for most projects, if they do the work to support both 3.0
and 2.6, to run simultaneously on 2.6 and 3.0 without use of a
translation tool. The second quote makes it sound like that will be
highly impractical. That picture is reinforced by what follows (in
PEP 3000):
"""
The recommended development model for a project that needs to support
Python 2.6 and 3.0 simultaneously is as follows:
0. You should have excellent unit tests with close to full
coverage.
1. Port your project to Python 2.6.
2. Turn on the Py3k warnings mode.
3. Test and edit until no warnings remain.
4. Use the 2to3 tool to convert this source code to 3.0 syntax. Do
not manually edit the output!
5. Test the converted source code under 3.0.
6. If problems are found, make corrections to the 2.6 version of
the source code and go back to step 3.
7. When it's time to release, release separate 2.6 and 3.0 tarballs
(or whatever archive form you use for releases).
It is recommended not to edit the 3.0 source code until you are ready
to reduce 2.6 support to pure maintenance (i.e. the moment when you
would normally move the 2.6 code to a maintenance branch anyway).
"""
So which is it? That is, will it be practical for most projects to
support 2.6 and 3.0 simultaneously, from the same codebase, without
relying on translation tools? I'm assuming the practicalities of this
*are* clear by now to the Python 3 developers -- is that right? It
seems to me that if I don't understand what the Python 3 developers
expect the practicalities to be, most other interested people won't
either ("interested " in the opposite sense to "disinteres ted" rather
than to "uninterested") .
John
