"Martin v. Löwis" <[EMAIL PROTECTED]> writes: >> 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_with(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 "disinterested" rather than to "uninterested"). John -- http://mail.python.org/mailman/listinfo/python-list
