On Wed, 13 May 2015 04:18 am, Ned Batchelder wrote:
> On Tuesday, May 12, 2015 at 2:03:04 PM UTC-4, Rob Gaddi wrote:
[...]
>> B) If I can't manage that, what's the etiquette behind having later
>> versions of a module break compatibility with older versions of Python.
>> I've avoided using features I know are newer, like yield from and Enums,
>> but I won't swear it'll work on 3.0 if I can't test it that way.
>
> No one supports 3.0 any more. 3.2 is kind of the oldest version
> that is still reasonable, and many people are only aiming for 3.3
> and 3.4.
No one *should* support 3.0. It is semi-officially "broken".
The first production-ready (i.e. "final") version of 3.0 was released on
December 3rd, 2008. It soon became obvious that it had serious problems,
and following a single point release (3.0.1) it reached official end of
life with the release of 3.1 on June 27th, 2009.
There's no outright prohibition on supporting 3.0, and if somebody wants to
use it they can (we can't stop you, it's FOSS), but unlike older versions
which have reached end of life in the fullness of time, 3.0 never had a
user-base actually relying on it in production. It would be a waste of time
to explicitly support it.
Anything written for 3.1 will probably work in 3.0, and if it doesn't, it's
probably a bug in 3.0. Either way, I wouldn't waste time fixing bugs that
only affected 3.0.
> Just because you are supporting 2.7 and 3.4 doesn't mean you need
> to support 3.0 and 3.1.
I agree whole-heartily with that. 2.x and 3.x are a fork in the language,
and you can support older versions on one branch without necessarily doing
the same on the other branch.
# requires fixed-width font for best results
1.4->1.5->2.0->2.1->2.2->2.3->2.4->2.5->2.6->2.7
\ \
\ 3.0->3.1->3.2->3.3->3.4
1.6
(I am unsure whether what became 3.0 *literally* was forked from 2.4, I
suspect not, but 2.5 was intended as the first of the transition versions
for moving between 2.4 and what was then known as Python 3000, and 2.6 was
the first to explicitly include Python 3 features via the __future__
module.)
> 2.x and 3.x are different languages.
I wish people wouldn't say that. They're different languages in the same
sense that American English and British English are different languages. I
prefer to emphasise the 98% similarities by calling them different dialects
than the 2% differences -- especially since it has turned out to be far
easier and more practical to write hybrid 2.x + 3.x code than anyone
imagined back in the Python 3000 days.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
