On Wed, 26 Jan 2005 09:47:41 -0500, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > This is what I mean about the patch taking on a life of its own. It's > an optimization patch that slows down METH_O and METH_NOARGS. It's a > incremental change that throws away backwards compatibility. It's a > simplification that introduces a bazillion new code paths. It's a > simplification that can't be realized until 3.0.
I've been thinking about how to move towards 3.0. There are many changes that are desirable and unlikely to occur prior to 3.0. But if we defer so many enhancments, the changes will be voluminous, potentially difficult to manage, and possibly error prone. There is a risk that many small warts will not be fixed, only because they fell through the cracks. I thought about making a p3k branch in CVS. It could be worked on slowly and would be the implementation of PEP 3000. However, if a branch was created all changes would need to be forward ported to it and it would need to be kept up to date. I know I wouldn't have enough time to maintain this. The benefit is that people could test the portability of their applications with 3.0 sooner rather than later. They could see if the switch to iterators created problems, or integer division, or new-style exceptions, etc. We could try to improve performance by simplifying architecture. We could see how much a problem it would be to (re)move some builtins. Any ideas how we could start to realize some benefits of Py3.0 before it arrives? I'm not sure if this is worth it, if it's premature, or if there are other ways to acheive the goal of easing transition for users and simplifying developers tasks (by spreading over a longer period of time) and reducing the possibility of not fixing warts. Neal _______________________________________________ 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
