<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>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.</div><div><div><br></div><div>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.</div></div><br><div><div>On Dec 8, 2011, at 4:27 PM, Martin v. Löwis wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><blockquote type="cite">This is not a comment on the success of py3, but rather the persistence<br></blockquote><blockquote type="cite">of old versions of things. &nbsp;Even assuming an awesomely optimistic<br></blockquote><blockquote type="cite">schedule for py3k migrations, even assuming that *everything* on PyPI<br></blockquote><blockquote type="cite">supports Py3 by the end of 2013, consider that all around the world,<br></blockquote><blockquote type="cite">every day, new code is still being written in FORTRAN.<br></blockquote><br>While this is true for FORTRAN, it is not for Python 1.5: no new<br>Python 1.5 code is written around the world, at least not every day.<br>Also for FORTRAN, new code that is written every day likely isn't<br>FORTRAN 66, but more likely FORTRAN 90 or newer.<br></div></blockquote><div><br></div><div>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. &nbsp;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.</div><br><blockquote type="cite"><div>The reason for that is that FORTRAN just isn't an obsolete language,<br>by any means, else people wouldn't bother producing new versions of<br>it, porting compilers to new processors, and so on. Contrast this to<br>Python 1, and soon Python 2, which actually *is* obsolete (just as<br>FORTRAN 66 *is* obsolete).<br></div></blockquote><div><br></div><div>Much as the Python core team might <i>wish</i>&nbsp;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. &nbsp;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. &nbsp;PyPy is even porting the JIT compiler to a new processor (ARM).</div><div><br></div><div>F66 is indeed obsolete, but it became obsolete because people stopped using it, not because the standards committee declared it so.</div><br><blockquote type="cite"><div><blockquote type="cite">Much of it is being in FORTRAN 77<br></blockquote><br>Can you prove this? I trust that existing code is being maintained<br>in FORTRAN 77. For new code, I'm skeptical.<br></div></blockquote><div><br></div><div>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. &nbsp;(I can see someone with more direct experience promptly replied in this thread already, anyway.)</div><br><blockquote type="cite"><div><blockquote type="cite">There are plenty of proprietary Python 2 systems which exist today for<br></blockquote><blockquote type="cite">which there will not be a budget for a Python 3 migration this decade.<br></blockquote><br>And people using it can happily continue to use Python 2. If they<br>don't have a need to port their code to Python 3, they are not concerned<br>by whether you use a u prefix for strings in Python 3 or not.<br></div></blockquote></div><div><br></div>I didn't say they didn't have a <i>need ever</i>, I said they didn't have a <i>budget now</i>. &nbsp;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". &nbsp;Despite the fact that I ultimately agree on u'' (nobody should care about this), it is not a good message to send.<div><br><div><div><div>-glyph</div></div></div></div></body></html>