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 <anthony interlink.com.au>
It's never too late to have a happy childhood.
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com
|