"Donovan Baarda" <[EMAIL PROTECTED]> writes:
>
> Just my 2c;
>
> I don't mind new features in minor releases, provided they meet the
> following two criteria;
>
> 1) Don't break the old API! The new features must be pure extensions that in
> no way change the old API. Any existing code should be un-effected in any
> way by the change.
>
> 2) The new features must be clearly documented as "New in version X.Y.Z".
> This way people using these features will know the minium Python version
> required for their application.
No no no! The point of what Anthony is saying, as I read it, is that
experience suggests it is exactly this sort of change that should be
avoided. Consider the case of Mac OS X 10.2 which came with Python
2.2.0: this was pretty broken anyway because of some apple snafus but
it was made even more useless by the fact that people out in the wild
were writing code for 2.2.1 and using True/False/bool. Going from
2.x.y to 2.x.y+1 shouldn't break anything, going from 2.x.y+1 to 2.x.y
shouldn't break anything that doesn't whack into a bug in 2.x.y -- and
"not having bool" isn't a bug in this sense.
My 2p.
Cheers,
mwh
--
Well, you pretty much need Microsoft stuff to get misbehaviours
bad enough to actually tear the time-space continuum. Luckily
for you, MS Internet Explorer is available for Solaris.
-- Calle Dybedahl, alt.sysadmin.recovery
_______________________________________________
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
