On Thursday 11 January 2007 05:13, Raymond Hettinger wrote: > It is my strong preference that we not go down this path. > Instead, the 2.6 vs 3.0 difference analysis should go in an > external lint utility.
I don't see how an external utility can possibly catch everything that's going to break - it's going to be much much easier to catch things like use of has_key and the like from inside the interpreter. Additionally, catching things like C code extensions using a slot or a method or a function that's going away is just not going to be possible otherwise. > The Py2.x series may live-on for some time and should do so > as if Py3.x did not exist. Burdening the 2.x code with loads > of warnings will only clutter the source code and make > maintenance more difficult. There may also be some performance > impact. If it's a single check of a C int, the performance impact will be minimal. I agree that 2.x will live for a long time - but unless we provide the best possible upgrade path, we will be stuck maintaining both 2.x and 3.x for ever. Additionally, without a 2.x<->3.x upgrade path 3.x is essentially a new language, having to build a new userbase from scratch. Worse yet, 2.x will suffer as people have the perception "Python 2? That's a dead/abandoned language" > We should resolve that Py2.6 remain as clean as possible > and that Py3.0 be kept in its own world. Forging a new > blade does not have to entail dulling the trusty old blade. I completely disagree here. We cannot simply ignore 3.0 in the 2.x series. We need to provide (as much as possible) an upgrade path for people who write and use code in the language. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. _______________________________________________ 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
