<br><div><span class="gmail_quote">On 3/20/06, <b class="gmail_sendername">Guido van Rossum</b> <<a href="mailto:firstname.lastname@example.org">email@example.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
We need to start deciding on important meta-issues like:<br><br>- What's the timeline? I don't expect to be setting a schedule now and<br>sticking to it for the next five years. But we owe everybody out there<br>who is watching some clarity about when Python 3000 can be expected,
<br>and how we plan to get there; there are widely differing estimates of<br>how long it will take, and I don't want to scare users away or cause<br>developers to hold their breath waiting for it (some of which I<br>imagine is happening with Perl 6).
</blockquote><div><br>Personally, I like the idea of Python 3.0 being released somewhere between 2.6 and 2.7, as you suggested at PyCon. That puts it between 1.5 and 3 years from now, given the usual release schedules. From what I can see now, that should be enough time to work out the major changes in
3.0. Maybe we should bill 3.0 as a 'developer release', urging extension/module-writers to adapt their code to 3.0 but not pushing it for general use. On the other hand, maybe it's better to make many pre-releases of 3.0, to give people a chance to look at
3.0 and to give developers (including ourselves) a chance to figure out how to upgrade (or facilitate upgrading) libraries, extensions and applications.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- What's the upgrade path? Do we provide a conversion tool, or a<br>compatibility mode, or both, or what? Will it be at all possible to<br>write code that runs in Python 2.x (for large enough values of x) as<br>well as in
3.0? </blockquote><div><br>I would like Pythonic code to be usable in both 2.x (where x is, say, 6 or higher) and 3.0, but 3.0 shouldn't need to worry too much about it. A compatibility mode is probably a bad idea -- isn't the whole reason for
3.0 to not worry about compatibility? :-) Then again, if it costs us little or nothing, it may be worth considering.<br><br>As for a conversion tool, it's a nice idea, but I wonder how well it'll work in practice. Take dict.items
() returning an iterator; how are you going to detect it, let alone convert it? You can 'convert' it by translating it to 'list(dict.items())', but it won't result in high quality code. Maybe a 'change highlighter', which runs through code and detects things that might have changed in Python
3.0, is a more workable idea. I do believe that's the minimum we should aim for, though.<br></div><br>Or, if source-inspection turns out to be too hard, have a backward-compatibility-aware 3.0, which can warn that something will behave differently than
2.x. (Maybe that's what you meant by 'compatibility mode') I wouldn't call it 'python' or 'python3' though, but keep it separate from python. It would have to replace a number of types with proxy-types that also check various uses.
<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">This also touches upon the issue of parallel releases<br>of Python 2.x and 3.x. My personal expectation (contrary to what MvL
<br>said recently) is that there will be several 2.x releases issued even<br>after 3.0 is out; possibly 3.0 and 2.6 may coexist, and 2.7-2.9 may<br>continue to evolve 2.x while 3.x is maturing. I've seen this used<br>successfully in Perl (with 4->5) and Apache, and closer to home in
<br>Zope. Again, this is important in the light of how the transition is<br>perceived in the world outside python-dev.</blockquote><div><br>I think the choice for parallel releases is a no-brainer, although we'll have to see how it turns out in practice. If
3.0 is a smash hit with an easy upgrade path, we'll need less 2.x releases than if upgrading ends up being a labourious process.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- Will we do a grand library reform at the same time? Personally I see<br>that as quite a separate issue; apart from some specific things like<br>the stdio redesign, we could start the library reform in 2.6, or<br>post-3.0
, depending on how much energy there it.</blockquote><div><br>Agreed. We can certainly add new modules/names to 2.6 to make them forward-compatible and add pending-deprecationwarnings to the old names. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- What's the implementation strategy? I've started a branch where I<br>plan to do some weeding out; but I've already found that the large<br>amount of legacy code makes the weeding difficult. I may yet decide to<br>switch to a sandbox model where only new code or carefully modernized
<br>old code is added (this is how Zope 3 was developed).</blockquote><div><br>Hm, I don't feel that we need to throw out that much code. If you want to re-implement Python from scratch (with copious copy-pasting from 2.x
) a sandbox model might make more sense, but then 1.5-3 years is quite unrealistic, and we'd also need to consider the C API stability. I'd much rather go for rigorous reviews and weeding of the existing source, than copying reviewed code until we have a working interpreter.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">- What's the procedure for proposing and new features? It may be time<br>to start a new series of PEPs that focus exclusively on Python 3000.
<br>I'd like to reserve the numbers 3000-3099 for meta-PEPs (e.g.<br>addressing the above questions) and 3100-3999 for feature PEPs.</blockquote><div><br>Aye. I would like to suggest we document all changes, even when they are no-brainers that have been on the wishlist for years and don't fit the PEP style: making
dict.keys/items/values return iterators, making -tt the default, removing the emacs/vi-tabsize-comment-hack from the parser, making all strings unicode, etc. In the end, a 'best practices' document describing how to write
2.x-and-3.x-compatible code may come in handy, too (but that can't be written until many features are fleshed out.)<br></div></div><br>-- <br>Thomas Wouters <<a href="mailto:firstname.lastname@example.org">email@example.com</a>>
<br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!