On Sun, 23 Mar 2008 23:12:55 +0100
"Lennart Regebro" <[EMAIL PROTECTED]> wrote:
> > You develop for 2.6, and then make sure it runs on 3.0 -
> > *exactly* the same as for 2.5/2.6.
> Uh... no. You develop for 2.5, and then you don't do anything else. It
> *will* run under 2.6. No need to check. Because it's backwards
> compatible.

This is, to be blunt, wishful thinking. I'm not sure that that's even
the intent. How many programs that used set.Set in 2.3 broke in 2.4
when the set module vanished? I don't know that there are any such
changes in 2.6. However, I don't believe the feature set for 2.6 has
been frozen yet, and until that happens, you can't know whether or not
your statement is true.

> And 3.0 is not. So it's definitely not the same. However,
> if 2.6 were forwards compatible, this would be true for the 2.6 to 3.0
> port.

Um, I'm used to "forward compatible" meaning "ignores features we
recognize as being for future versions of ourselves, but don't
otherwise understand" (or similar). Doing that in a programming
language is liable to be an even worse disaster than it is for data
language.

2.6 can add features to help make converting code to 3.0 easier. 3.0
can't add features to help make converting code from 2.6 easier. The
issue of adding features to 2.x to make converting code from 2.y
easier has never come up, because we've never removed features before
(though we've moved them, and added restrictions, and probably other
things that caused code to break).

       <mike
-- 
Mike Meyer <[EMAIL PROTECTED]>          http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Reply via email to