>> 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.)"""
That's a different statement, though: It is likely that code will not
run unmodified on 3k. For example, print is now a statement, and
many many modules use that statement somewhere; they break in 3k.
However, it *is* a design goal to make 2.6 so that transition to
3k becomes simpler. That's not a 3k feature, but a 2.6 one.
> 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:
That's Guido's recommendation, yes: use the 2to3 tool.
There are certainly projects for which this might be the only reasonable
strategy. However, whether that will be the *common* strategy remains
to be seen. I personally believe that many projects won't need the 2to3
tool, if they are willing to compromise on the notations used in the
source code.
> So which is it?
Both.
> 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?
That remains to be seen. I believe it will be, yes. Only when people
start trying we will actually know. Personal preference will vary
across projects; some will use the conversion tool even though they
could have come up with a single-source solution, others will fight
for a single-source solution even though life would have been much
simpler with the conversion tool.
> I'm assuming the practicalities of this
> *are* clear by now to the Python 3 developers -- is that right?
Not at all (at least now to me). I know what kind of changes *I*
regularly do to make code run in 3k, namely, put parentheses around
into the print statements. I can live with that. Whether it is
practical to run, say, Django unmodified, I don't know - I have
not looked into Django with that much detail, let alone tested
whether it will work.
Note that I'm primarily talking about pure Python here; for
C code, you can get a single-source version only with a lot
of #ifdefs (but again, I believe it is practical to make it
work that way).
> 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").
I think comp.lang.python is then the wrong place to find out; the py3k
list likely reaches more of these developers. OTOH, I don't know whether
they all want to participate in a survey of their expectations...
Rather than studying people's opinions, why don't you try to port your
own projects to 3k, and report whether you found it practical to use
a single source (assuming you would prefer such a solution for your
own project)?
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
