Re: [Python-Dev] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))

2007-03-09 Thread Greg Ewing
Martin v. Löwis wrote: > splitext(path) > Split the pathname path into a pair (root, ext) such that root + ext == > path, and ext is empty or begins with a period and contains at most one > period. Actually, that spec could be satisfied by a function that *always* returned an empty string for e

Re: [Python-Dev] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))

2007-03-09 Thread Phillip J. Eby
At 07:18 PM 3/9/2007 +0100, Martin v. Löwis wrote: >Phillip J. Eby schrieb: > > At 08:57 AM 3/9/2007 +0100, Martin v. Löwis wrote: > >> In the case that triggered the discussion, the change implemented > >> was not an incompatible change, because the new implementation still > >> met the old specif

Re: [Python-Dev] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))

2007-03-09 Thread Martin v. Löwis
Phillip J. Eby schrieb: > At 08:57 AM 3/9/2007 +0100, Martin v. Löwis wrote: >> 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). > > No, it

Re: [Python-Dev] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))

2007-03-09 Thread Phillip J. Eby
At 08:57 AM 3/9/2007 +0100, Martin v. Löwis wrote: >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). No, it wasn't, actually. Read the doc str

Re: [Python-Dev] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))

2007-03-09 Thread Martin v. Löwis
Grig Gheorghiu schrieb: > Titus and I are thinking about mentoring a Google Summer of Code > project that would use the 'buildbot try' feature: set up a bunch of > buildbot slaves and set them up so sending them a patch will trigger a > checkout of the latest Python svn, followed by the application

Re: [Python-Dev] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))

2007-03-08 Thread Martin v. Löwis
[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 e

Re: [Python-Dev] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))

2007-03-08 Thread Terry Reedy
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: 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

Re: [Python-Dev] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))

2007-03-08 Thread Steven H. Rogers
[EMAIL PROTECTED] wrote: > > 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 u

Re: [Python-Dev] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))

2007-03-08 Thread Grig Gheorghiu
On 3/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > 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/commu