Re: [Python-Dev] Proposal to revert r54204 (splitext change)

On 3/16/07, Steve Holden <[EMAIL PROTECTED]> wrote: > Perhaps you'd like to remind me that "backward compatibilty" includes > the necessity to run new programs on old versions of Python, too? Ahh, but you see, new programs are the easy part. You actually have at least four choices of different le

[Python-Dev] Weekly Python Patch/Bug Summary

Patch / Bug Summary ___ Patches : 342 open (-38) / 3712 closed (+54) / 4054 total (+16) Bugs: 951 open (-14) / 6588 closed (+33) / 7539 total (+19) RFE : 257 open (-15) / 266 closed (+13) / 523 total ( -2) New / Reopened Patches __ ftp.pytho

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

Mike Krell wrote: > On 3/16/07, Greg Ewing <[EMAIL PROTECTED]> wrote: >> Mike Krell wrote: >> >>> I said the name ".emacs" was used as an example. For that matter, the >>> name "a.txt" was also used as an example. The use cases are real. >> So does your application create any file names >> that h

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

"Martin v. Löwis" writes: > Phillip J. Eby schrieb: > > Some other options: > > > > 1. Deprecate splitext() and remove it in 3.0 > > How would that help the problem? Isn't it useful to have a function > that strips off the extension? No. It's useful to have a function that performs a w

Re: [Python-Dev] [ 1673007 ] urllib2 requests history + HEAD

> From: Facundo Batista <[EMAIL PROTECTED] > > This patch was posted by "koder_ua". > I think that Request must have a "request type" parameters, so people > can send "HEAD" requests easily. > But it seems to me that keeping a request history in the module is bad,

Re: [Python-Dev] deprecate commands.getstatus()

On Fri, Mar 16, 2007 at 09:50:29AM -0700, Guido van Rossum wrote: -> > What do people think of this basic interface? -> > -> > (status, output) = subprocess.get_status_output(cmd) -> > -> > output = subprocess.get_output(cmd) -> > -> > Here 'status' is the 'returncode' from subprocess.Popen

Re: [Python-Dev] deprecate commands.getstatus()

-> > >> What about reimplementing commands.* using subprocess? Or providing a -> > >> commands.*-compatible interface in the subprocess module? OK, so as I understand it, the next step would be for me to provide a patch implementing this, right? Or is this PEP-required (please no...)? What do pe

[Python-Dev] who gets paid for this?

Hi all, I'm a grad student at UC Davis studying the python community and I wanted to know if some on this list could help me out. I'm studying the factors that affect people "graduating" from being mailing list participant to developers with write access to the repository. Is it possible to find

Re: [Python-Dev] deprecate commands.getstatus()

On Tue, Mar 13, 2007 at 04:55:07PM -0700, Guido van Rossum wrote: -> On 3/13/07, Titus Brown <[EMAIL PROTECTED]> wrote: -> > What about reimplementing commands.* using subprocess? Or providing a -> > commands.*-compatible interface in the subprocess module? -> -> What does that buy us? The simpl

Re: [Python-Dev] deprecate commands.getstatus()

On Tue, Mar 13, 2007 at 02:16:21PM -0700, Guido van Rossum wrote: -> On 3/13/07, Georg Brandl <[EMAIL PROTECTED]> wrote: -> > I'd like to deprecate commands.getstatus() in 2.6. -> > -> > Reason: there is getoutput() and getstatusoutput(). In the latter, "status" -> > means the exit code. getstatus(

[Python-Dev] Looking for a topic for a masters thesis

Hi all, Forgive me for the off-topic post. I'm looking for a topic for a masters thesis in the field of (programming) language theory in Computer Science - in the timeframe of 2-4 years. To combine this with my love of Python, can anyone here suggest a topic that would directly benefit Python in

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

On 3/16/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > Mike Krell wrote: > > > I said the name ".emacs" was used as an example. For that matter, the > > name "a.txt" was also used as an example. The use cases are real. > > So does your application create any file names > that have a single dot at th

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

Mike Krell wrote: > I said the name ".emacs" was used as an example. For that matter, the > name "a.txt" was also used as an example. The use cases are real. So does your application create any file names that have a single dot at the beginning? -- Greg

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

That may actually be a genuinely useful approach: splitext(name, ignore_leading_dot=False, all_ext=False) ... that's perfect. I updated my patch to do it that way! :) --S ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mail

Re: [Python-Dev] Status of thread cancellation

On 12:06 am, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Can you suggest any use-cases for thread termination which will *not* result in a completely broken and unpredictable heap after the thread has died? Suppose you have a GUI and you want to launch a long-running computation without

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

On 15 Mar, 11:34 pm, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schrieb: However, the decision was a bad one regardless of the existing policy, and sets a bad precedent while we are discussing this policy. I could be wrong, but I think it would be reasonable to assume that if Martin strongly

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

Patrick Maupin schrieb: > On 3/16/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> Assuming the current behavior is a bug (which I still believe to be >> the case), in order to actually make use of the bug fix, you have to >> pass the parameter. This will make your code break on old versions. >

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

On 3/16/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Assuming the current behavior is a bug (which I still believe to be > the case), in order to actually make use of the bug fix, you have to > pass the parameter. This will make your code break on old versions. But, that's a GOOD thing. If

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

On 03/16/2007 05:43 PM, Nick Coghlan wrote: -- Sjoerd Mullender > Phillip J. Eby wrote: >> At 01:31 PM 3/16/2007 +0100, Martin v. Löwis wrote: >>> Phillip J. Eby schrieb: 2. Add an optional flag argument to enable the new behavior >>> How would that help backwards compatibility? >> All existi

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] That may actually be a genuinely useful approach: splitext(name, ignore_leading_dot=False, all_ext=False) Split the extension from a pathname. Returns "(root, ext)". By default, the extension is all characters from

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

Mike Krell schrieb: > On 3/16/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > >> If they pass the flag to the function, the code will stop running on >> 2.5 and earlier. This is worse than having code that works on all >> versions. This is also whz I wondered how the flag helps backwards >> com

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 16, 2007, at 3:30 PM, Mike Krell wrote: > On 3/16/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > >> If they pass the flag to the function, the code will stop running on >> 2.5 and earlier. This is worse than having code that works on all >>

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

Paul Moore writes: > On 16/03/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > What's *actually* under dispute here is whether it's acceptable to classify > > this perfectly useful-as-is behavior, that was documented and tested in > > released versions of Python for several years (with patche

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

On 3/16/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > If they pass the flag to the function, the code will stop running on > 2.5 and earlier. This is worse than having code that works on all > versions. This is also whz I wondered how the flag helps backwards > compatibility: when people add

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

On 3/16/07, Nick Coghlan <[EMAIL PROTECTED]> wrote: > splitext(name, ignore_leading_dot=False, all_ext=False) +1. ISTM this is a reasonable way to go in the face of our existing backward compatibility issue and the differing definitions of extensions across OS's. Mike ___

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

Steve Holden schrieb: >> Somebody has pointed out that it is fairly easy to write a wrapper >> around splitext that explicitly produces the old behavior on all >> versions, or the new behavior on all versions, depending on what >> precisely is desired. Users that have coded for a specific behavio

Re: [Python-Dev] deprecate commands.getstatus()

On 3/16/07, Titus Brown <[EMAIL PROTECTED]> wrote: > -> Yes. Another intermediate step might be to rewrite the commands module > -> to call the new APIs in the subprocess module. > > My preference would be to push people towards subprocess, and the more > capable & complex API there, by deprecating

Re: [Python-Dev] deprecate commands.getstatus()

On 3/16/07, Titus Brown <[EMAIL PROTECTED]> wrote: > -> > >> What about reimplementing commands.* using subprocess? Or providing a > -> > >> commands.*-compatible interface in the subprocess module? > > OK, so as I understand it, the next step would be for me to provide a > patch implementing this

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

Phillip J. Eby wrote: > At 01:31 PM 3/16/2007 +0100, Martin v. Löwis wrote: >> Phillip J. Eby schrieb: >>> 2. Add an optional flag argument to enable the new behavior >> How would that help backwards compatibility? > > All existing calls to splitext() would work the same way they've done > for sev

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

At 01:47 AM 3/16/2007 -0400, Terry Reedy wrote: >I think it is a ludicrous comparison, not even in the same ballpark, that >tends to discredit the valid points you have made. Of course it's not in the same ballpark. The point was to show how ludicrous the *logic* is, by applying it to something

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

At 01:31 PM 3/16/2007 +0100, Martin v. Löwis wrote: >Phillip J. Eby schrieb: > > Some other options: > > > > 1. Deprecate splitext() and remove it in 3.0 > >How would that help the problem? Isn't it useful to have a function >that strips off the extension? Not if there's no consensus as to what "e

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

Martin v. Löwis wrote: > Patrick Maupin schrieb: >> The worst part is, if they are relying on that specific behavior and have >> to rely on the new specific behavior, and want to support old and new >> versions of Python, they are potentially left with some very unattractive >> options -- check the

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

Martin v. Löwis wrote: > Phillip J. Eby schrieb: >> Some other options: >> >> 1. Deprecate splitext() and remove it in 3.0 > > How would that help the problem? Isn't it useful to have a function > that strips off the extension? > >> 2. Add an optional flag argument to enable the new behavior > >

Re: [Python-Dev] What's New maintenance

A.M. Kuchling schrieb: > Where should I add a note about this: a comment at the top of > whatsnew.tex, maybe? That would be good. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsub

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

Patrick Maupin schrieb: > The worst part is, if they are relying on that specific behavior and have > to rely on the new specific behavior, and want to support old and new > versions of Python, they are potentially left with some very unattractive > options -- check the Python version to figure out

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

Thomas Wouters schrieb: > Hah, everyone agree? They weren't agreeing when you changed it, either > :) But no, we don't add a warning *and* change the API. We add a warning > *about* changing the API. 2.6 sees no semantic change, just a warning > when os.path.splitext is used on a dotfile with no

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

Phillip J. Eby schrieb: > Some other options: > > 1. Deprecate splitext() and remove it in 3.0 How would that help the problem? Isn't it useful to have a function that strips off the extension? > 2. Add an optional flag argument to enable the new behavior How would that help backwards compatibi

[Python-Dev] What's New maintenance

On Thu, Mar 15, 2007 at 10:31:06PM +0100, "Martin v. L?wis" wrote: > I would do that, except that Andrew explicitly reserved the right to > change whatsnew.tex. I believe he does go over Misc/NEWS in doing so. It's actually OK to add things to whatsnew.tex, subject to the warning that: 1) I will

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

On 3/14/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: Thomas Wouters schrieb: > However, changing documented, tested behaviour without warning gives > Python an even worse name. I agree with PJE that the change is the wrong > thing to do, simply because it sets (yet another) precedent. If > p

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

On 16/03/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > What's *actually* under dispute here is whether it's acceptable to classify > this perfectly useful-as-is behavior, that was documented and tested in > released versions of Python for several years (with patches to change its > behavior expli

Re: [Python-Dev] Status of thread cancellation

On 16/03/2007 1.06, Greg Ewing wrote: >> Can you suggest any use-cases for thread termination which will *not* >> result in a completely broken and unpredictable heap after the thread >> has died? > > Suppose you have a GUI and you want to launch a > long-running computation without blocking th

Re: [Python-Dev] Status of thread cancellation

Josiah Carlson wrote: > Greg Ewing <[EMAIL PROTECTED]> wrote: >> [EMAIL PROTECTED] wrote: >> >>> Can you suggest any use-cases for thread termination which will *not* >>> result in a completely broken and unpredictable heap after the thread >>> has died? >> Suppose you have a GUI and you want to

Re: [Python-Dev] Proposal to revert r54204 (splitext change)

On 3/15/07, Terry Reedy <[EMAIL PROTECTED]> wrote: > As to the usefulness of current behavior, the only supposed use-case code > posted, that I have noticed, was that it made it easy to turn '.emacs' into > '1.emacs', but then MK said the app does not really do that. I said the name ".emacs" was