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