[EMAIL PROTECTED] wrote:
That assumes there is a need for the old functionality. I really don't
see it (pje claimed he needed it once, but I remain unconvinced, not
having seen an actual fragment where the old behavior is helpful).
This passage is symptomatic of the thing that really bothers me here. I
have rarely used splitext before (since what I really want is
determineMIMEType(), and that is easier to implement with one's own
string-munging) and certainly won't use it again after following this
discussion.
The real issue I have here is one of process. Why is it that PJE (or
any python user who wishes their code to keep working against new
versions of Python) must frequent python-dev and convince you (or
whatever Python developer might be committing a patch) of each use-case
for old functionality? I would think that the goal here would be to
keep all the old Python code running which it is reasonably possible to,
regardless of whether the motivating use-cases are understood or not.
It is the nature of infrastructure code to be used in bizarre and
surprising ways.
My understanding of the current backwards-compatibility policy for
Python, the one that Twisted has been trying to emulate strictly, is
that, for each potentially incompatible change, there will be:
* at least one release with a pending deprecation warning and new,
better API
* at least one release with a deprecation warning
* some number of releases later, the deprecated functionality is removed
I was under the impression that this was documented in a PEP somewhere,
but scanning the ones about backwards compatibility doesn't yield
anything. I can't even figure out why I had this impression. *Is*
there actually such a policy?
If there isn't, there really should be. Deciding each one of these
things on a case-by-case basis leaves a lot of wiggle room for a lot of
old code to break in each release. For example, if you put me in charge
of Python networking libraries and I simply used my judgment about what
usages make sense and which don't, you might find that all the
synchronous socket APIs were mysteriously gone within a few releases...
;-)
Perhaps policy isn't the right way to solve the problem, but neither is
asking every python application developer to meticulously follow and
participate in every discussion on python-dev which *might* affect their
code.
As recently as last week, Guido commented that people build mental
models of performance which have no relation to reality and we must rely
on empirical data to see how things *really* perform. This is a common
theme both here and anywhere good software development practices are
discussed.
These broken mental models are not limited to performance. In
particular, people who develop software have inaccurate ideas about how
it's really used. I am avoiding being specific to Python here because
I've had a similarly broken idea of how people use Twisted, heard
extremely strange ideas from kernel developers about the way programs in
userland behave, and don't get me started on how C compiler writers
think people write C code.
If Python is not going to have an extremely conservative (and
comprehensive, and strictly enforced) backwards-compatibility policy, we
can't rely on those mental models as a way of determining what changes
to allow. One way to deal with the question of "how do people really
use python in the wild" is to popularize the community buildbots and
make it easy to submit projects so that at least we have a picture of
what Python developers are really doing.
Buildbot has a "build this branch" feature which could be used to settle
these discussions more rapidly, except for the fact that the community
builders are currently in pretty sad shape:
http://www.python.org/dev/buildbot/community/all/
By my count, currently only 9 out of 22 builders are passing. The
severity of these failures varies (many of the builders are simply
offline, not failing) but they should all be passing. If they were,
rather than debating use-cases, we could at *least* have someone check
this patch into a branch, and then build that branch across all these
projects to see if any of them failed.
Unfortunately open source code is quite often better tested and
understood than the wider body of in-house and ad-hoc Python code out
there, so it will be an easier target for changes like this than
reality. I don't really have a problem with that though, because it
creates a strong incentive for Python projects to both (A) be open
source and (B) write comprehensive test suites, both of which are useful
goals for many other reasons.
In the past I've begged off of actually writing PEPs because I don't
have the time, but if there is interest in codifying this I think I
don't have the time *not* to write it. I'd prefer to document the
pending/deprecate/remove policy first, but I can write up something more
complicated about community buildbots and resolving disputes around
potential breakages if there is actually no consensus about that.
_______________________________________________
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