Re: Misleading wikipedia article on Python 3?

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
.

Relevant Pages

  • Re: Misleading wikipedia article on Python 3?
    ... I haven't been following Python 3 development recently. ... The recommended development model for a project that needs to support ... Use the 2to3 tool to convert this source code to 3.0 syntax. ... expect the practicalities to be, ...
    (comp.lang.python)
  • Re: I sing the praises of lambda, my friend and savior!
    ... thus implying that the philosophy behind ... > choose a language whose design philosophy matches one's own. ... > number of disagreements with Python's design goals; ... I don't think I have a problem with python design goals. ...
    (comp.lang.python)
  • Re: General question about Python design goals
    ... which priority have the above design goals for Python? ... minds" and making it usable and understandable for "little minds" is no ... A programming language is not a "work of art". ...
    (comp.lang.python)
  • Python and Flaming Thunder
    ... I've read that one of the design goals of Python was to create an easy- ... to-use English-like language. ... Flaming Thunder at http://www.flamingthunder.com/, which has proven ...
    (comp.lang.python)