Zooming back in to the actual issue this thread is about, I think the u""-vs-""
issue is a bit of a red herring, because the _real_ problem here is that 2to3
is slow and buggy and so migration efforts are starting to work around it, and
therefore want to run the same code on 3.x and all the way back to 2.5.
In my opinion, effort should be spent on optimizing the suggested migration
tools and getting them to work properly, not twiddling the syntax so that it's
marginally easier to avoid them.
On Dec 8, 2011, at 4:27 PM, Martin v. Löwis wrote:
>> This is not a comment on the success of py3, but rather the persistence
>> of old versions of things. Even assuming an awesomely optimistic
>> schedule for py3k migrations, even assuming that *everything* on PyPI
>> supports Py3 by the end of 2013, consider that all around the world,
>> every day, new code is still being written in FORTRAN.
>
> While this is true for FORTRAN, it is not for Python 1.5: no new
> Python 1.5 code is written around the world, at least not every day.
> Also for FORTRAN, new code that is written every day likely isn't
> FORTRAN 66, but more likely FORTRAN 90 or newer.
That's because Python 1.5 was upward-compatible with 2.x, and pretty much
everyone could gently migrate, and start developing on the new versions even
while supporting the old ones. That is obviously not true of 3.x, by design;
2to3 requires that you still develop on the old version even if you support a
new one, not to mention the substantially increased effort of migration.
> The reason for that is that FORTRAN just isn't an obsolete language,
> by any means, else people wouldn't bother producing new versions of
> it, porting compilers to new processors, and so on. Contrast this to
> Python 1, and soon Python 2, which actually *is* obsolete (just as
> FORTRAN 66 *is* obsolete).
Much as the Python core team might wish Python 2 would "soon" be obsolete, all
of these things are happening for python 2.x now and all indications are that
they will continue to happen. PyPy, Jython, ShedSkin, Skulpt, IronPython, and
possibly a few others are (to varying degrees) all targeting 2.x right now,
because that's where the application code they want to run is. PyPy is even
porting the JIT compiler to a new processor (ARM).
F66 is indeed obsolete, but it became obsolete because people stopped using it,
not because the standards committee declared it so.
>> Much of it is being in FORTRAN 77
>
> Can you prove this? I trust that existing code is being maintained
> in FORTRAN 77. For new code, I'm skeptical.
I am not deeply immersed in the world where F77 is still popular, so I don't
have any citations for you, but casual conversations with people working in the
sciences, especially chemistry and materials science, suggests to me that a lot
of F77 and start new projects in it. (I can see someone with more direct
experience promptly replied in this thread already, anyway.)
>> There are plenty of proprietary Python 2 systems which exist today for
>> which there will not be a budget for a Python 3 migration this decade.
>
> And people using it can happily continue to use Python 2. If they
> don't have a need to port their code to Python 3, they are not concerned
> by whether you use a u prefix for strings in Python 3 or not.
I didn't say they didn't have a need ever, I said they didn't have a budget
now. What you are saying to those users here is basically: "if you can't
migrate today, then just don't bother, we're never going to make it any
easier". Despite the fact that I ultimately agree on u'' (nobody should care
about this), it is not a good message to send.
-glyph
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
