Eric Smith, 16.03.2011 04:12:
On 3/15/2011 10:58 PM, Lennart Regebro wrote:
On Tue, Mar 15, 2011 at 22:42, Guido van Rossum wrote:
Fortunately there may not be any more such cases since no new major
versions of Python 2 will be released. So I'm not sure what an update
of PEP 5 will buy us.
That is a good point. But at least making sure no more API's get
deprecated in 3.3 (and preferably 3.4) would go a long way, as we are
likely to still have to support Python 2 in parallell for those
versions as well.
I think it's valid that we should consider the affect of libraries that are
trying to support 2.x and 3.y (for some values of x and y) at the same
time.
I don't really see any for this specific change, though. It's not an issue
of supporting "both 2.x and 3.x", it's an issue of supporting 3.2 and
earlier CPython versions, and it's not even hard to do that. Basically, you
can copy&adapt code from a project that already supports it and be done.
CPython has broken backwards compatibility in certain areas more than once.
It even broke basically all existing C code in 2.5 with the introduction of
Py_ssize_t (well, technically, it didn't break it on 32bit platforms, but
it introduced a pretty heavy push for people to walk through their code and
manually adapt it anyways). Other breakages had a much smaller impact than
that. If the amount of affected code is smaller, it's unfortunate to be
amongst those who are hit by such a change, but if there's a reason to go
that route, well, then there's a reason.
I still consider this is mostly a communication issue. If this change had
been properly written up, preferably in a PEP, including the reasoning for
it to get done, I think this whole discussion would not have been necessary.
Stefan
_______________________________________________
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
