<br><div><span class="gmail_quote">On 3/20/06, <b class="gmail_sendername">Guido van Rossum</b> &lt;<a href="mailto:guido@python.org">guido@python.org</a>&gt; 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: - What's the timeline? I don't expect to be setting a schedule now and sticking to it for the next five years. But we owe everybody out there who is watching some clarity about when Python 3000 can be expected,

and how we plan to get there; there are widely differing estimates of how long it will take, and I don't want to scare users away or cause developers to hold their breath waiting for it (some of which I 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>&nbsp;</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-&gt;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>&nbsp;</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;&nbsp;&nbsp;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.

</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 procedure for proposing and new features? It may be time 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 &lt;<a href="mailto:thomas@python.org">thomas@python.org</a>&gt;

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!