[EMAIL PROTECTED] schrieb: > 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?
Because this is the way free software works. I'm the one contributing (actually, merely integrating changes proposed by others, Larry Hastings in particular), so I get to make decisions. This patch had been open for three years. If pje had any problems with it, he could have rejected it. If you had problems with it, you could have commented that it should not be applied. Nobody did, so I decide. > 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. Exactly: which it is reasonably possible to. In this case, I found no reasonable way to keep it running while still fixing the bug, and not breaking too much other stuff in order to keep that particular code running. So the only alternative would have been to reject the change and live with the bug forever, something that many people here considered bad. > 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 If you want to contribute a patch that changes splitext to follow this policy, please go ahead and submit one. I personally consider a deprecation warning unacceptable in this specific case. > 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? There is PEP 5, which is not followed, since it requires backwards-incompatible behavior to go through the PEP process. > If there isn't, there really should be. So submit a PEP. Or better, take over maintenance of PEP 5 (or better, cooperate with the author of the PEP on maintaining it). > 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. And there is no need to. If they find that their code breaks, they can submit bug reports, or, better, contribute patches. This is what alpha releases are for, and the trunk is buildable all the time, so you can test your code against the new release even before it happens. If you want to study the changes, you can read Misc/NEWS from time to time. > 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. I was going to say that. Now, if "the community" doesn't pick up the concept of community buildbots, "the community" has no right to complain (IMO, and I put that deliberately into quotes, knowing that "the community" doesn't exist as such, but is made up of individuals, some interested in the buildbots, stability, and so on, and others being less conservative). > 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. If you think it needs codification, I think you will need to write it yourself - nobody else will do it for you. Depending on what it will say, I might disagree. I do disagree with the requirement that every incompatible go through the PEP, and I understand "incompatible change" as "programs only relying on document behavior might break". In the case that triggered the discussion, the change implemented was not an incompatible change, because the new implementation still met the old specification (which, of course, was underspecified). Regards, Martin _______________________________________________ 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