> Removing _any_ built-in that was around in 1.5.2 will pose similar
> problems.
Only proportional to the likelihood that it was used in 1.5.2, which
is proportional to how useful it is. intern(): extremely unlikely
(nobody knows what it's for); coerce(): rather unlikely (too
advanced); apply(): very likely.
> How hard can it be, in Python source that needs to run
> on both 1.5.2 and 2.5, to, e.g.:
>
> try: import legacy_25x_152
> except ImportError: pass
>
> where the "legacy module" would inject apply (etc) in builtins? (In
> 2.4, you'd "just" need to turn off deprecation warnings, which in
> such a stretched case as 1.5-to-2.4 you're surely doing anyway...).
The problem (and real cost, for some!) is that people who write code
that should work for 1.5.2 and later end up having to do more
maintenance on it for each new Python version they support. Maybe we
should just be resigned to having a bunch of unwanted builtins until
3.0 comes along (where I'm okay with all bets being off).
> Guido has specifically asked for built-ins that could be deprecated.
>
> It doesn't seem to me that asking for deprecation warnings to be
> turned off, or a "legacy module" to be conditionally imported, is
> "going out of our way to make it harder" to have code running all
> the way from 1.5 to 2.5 -- if such a feat currently requires 99 units
> of effort it MAY move all the way to 100 this way, but I doubt the
> relative augmentation of effort is even as high as that.
(a) It's always better to be able to use a common subset than to have
to resort to version checking or version-specific hacks. (We've
all learned this in the context of platform independence; I think
the same applies to version independence.)
(b) Since 2.4 and 2.5 don't yet exist (2.4 is at best a moving
target), someone wanting to use a cross-version subset *now* has
to settle for targeting and testing with 1.5.2 through 2.3.
Forcing these folks to do a new release for 2.4 or 2.5 is not
increasing their work from 99 to 100 units, it's increasing the
work they have to do in the future from 0 to 1 (on an arbitrary
scale :-).
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4