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 used as an example. For that matter, the name a.txt was also used as an example. The use cases are real. Mike ___ 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
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 launch a long-running computation without blocking the user interface. You don't know how long it will take, so you want the user to be able to cancel it if he gets bored. If the code is in Python, you can use sys.settrace to handle this. If the code is in an extension module that a user has control over, having a cancel_thread() function that is made available to Python, and having your C code check the value of a single variable every few seconds could do the same thing (even checking the value in a tight loop shouldn't slow computations down significantly, branch prediction should be able to make it a more or less zero-cost operation). Yes, it can be tedious, but at least the programmer can actually control cleanup in a reasonable manner. Option 3, farm the long running operation out to another process and use the OS-provided facilities to abort and cleanup if the user changes their mind. It's the only way to be sure the aborted operation doesn't leave the main process in a dodgy state. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
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 the user interface. You don't know how long it will take, so you want the user to be able to cancel it if he gets bored. There's no single place in the code where you could put in a check for cancellation. Sprinkling such checks all over the place would be tedious, or even impossible if large amounts of time are spent in calls to a third-party library that wasn't designed for such things. Interaction with the rest of the program is extremely limited -- some data is passed in, it churns away, and some data is returned. It doesn't matter what happens to its internal state if it gets interrupted, as it's all going to be thrown away. In that situation, it doesn't seem unreasonable to me to want to be able to just kill the thread. I don't see how it could do any more harm than using KeyboardInterrupt to kill a program, because that's all it is -- a subprogram running inside your main program. How would you handle this situation? It's really simple: don't use threads, use processes! Spawn an external process which does the calculation, pass data to it through pipe/socket/namedpipe/xmlrpc/whatever and read data back from it when it's done. If you need to kill it, just kill it away, at any asynchronous time: the OS will clean up after it. After many years working with these issues, I came to the personal conclusion of avoiding threads as much as possible. Threads are processes with shared memory, but in many real-world use cases I faced, there is really only a very little chunk of memory which is shared, and Python makes it incredibly easy to marshal data to a process (pickle or whatever). So in many cases there's really little excuses for going mad with threads. -- Giovanni Bajo ___ 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
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 explicitly rejected in the past), as a bug. Just to put this into context, the word bug is probably not the best to use here. The orignal behaviour was described as a bug, certainly, but that's not how the change has been treated. If the behaviour was being deemed a bug, it would be acceptable in a bugfix release (ie. 2.5.1). No-one is advocating that. Rather, the change is being treated as a behaviour change (which it is) and submitted for a *feature* release (2.6). Whether the behaviour change is good, reasonable, acceptable - that's the question here. (And one on which I don't have an opinion!) Paul ___ 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
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 providing an alternate API with clearer semantics is too 'heavy-weight' a solution and warning is for some reason unacceptable (I don't see why; all the arguments against warning there go for *any* warning in Python) -- then the problem isn't bad enough to fix it by breaking other code. I think producing pointless warnings also gives Python a bad name (I've seen many complaints about Python's warnings in the past, in particular when they fill up Apache log files). I would be more pissed if my apache logfiles were full of errors, instead :-) But perhaps we should be more forward about the use of warnings: warn people (so to speak) about warnings, and tell them about the -W option for making them louder/quieter. However, if everybody (and here I mean everybody) can agree that adding a warning to the current implementation would be an acceptable compromise, I could agree to such a compromise also (although I would prefer if somebody else took the blame for adding that warning. I happily take the blame for changing the behavior). What specific warning would you propose, and in what specific circumstance would it be issued? 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 extension (or a file with an extension but no name, so you will.) 2.7/3.0 see the change in semantics. We do this for three reasons: - People who rely on the documented, tested, ages-old behaviour will get fair warning that the behaviour will change. I don't mean just programmers. I mean users, too. Yes, users will get to see the warning and many of them might not be able to do something about it. Well, considering this class of users would get a behavioural change, and quite likely a bug, giving them a warning hardly seems intrusive. - People who (inadvertently) rely on the new behaviour get a warning that their code is currently bugged. This includes users, too, of course: they get a warning that this program is bugged in older versions of Python. If there was a way to telepathically warn the actual programmer, that would be better, but there isn't, so we can't. We will have to use the user as the messenger. Furthermore, even if the original programmer is a user of his or her own program and uses Python 2.6, he or she may never trigger the erroneous behaviour himself. The user who got the warning is the only one who can tell him or her that there's a problem with dotfiles. (Even though only a small fraction of the actual users will send in a bug -- it's still the best we can do.) - Most importantly, people who don't care about the change, whose code works acceptibly with either version of os.path.splitext, will get warned about the change in behaviour. If, as in one of the given examples in this thread, files are renamed based on their 'extension', it may work either way, and it may make sense either way, but it will *change*. Files may end up being differently renamed. I don't see that as acceptible behaviour, for upgrading python to cause a subtle but noticeable change in how a program does its work -- without error. That's why we warn. There is a big difference between fixing this, and fixing bugs that are obviously bugs: functions that behave differently from the documentation or (if not documented) in obviously wrong ways. If you need to wonder what 'obvious' means: if the average programmer using the function does not realize he's getting 'incorrect' behaviour, it's not obviously wrong. This entire thread should make it obvious that os.path.splitext's old behaviour, while nonsensical if you think about it, is not *obviously* wrong. If os.path.splitext(.dotfile) were to return (.dotfile, .dotfile), that would be obviously wrong. What it does now is not. Changing it is the right thing, but changing it without first warning about it is not. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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
[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 rewrite the text as necessary. 2) some changes I consider too obscure to bother describing in whatsnew.tex. If such a change is added to the text, I'll just remove it. I would feel bad if someone were to spend a long time writing a paragraph or section, and then I decided to delete the text. So... add changes as you wish, but please don't work very hard on the text, and writing in note form is fine -- I'll rewrite as needed. You don't need to comment out your added text; we're so far from release I don't care if the formatting is incorrect. Where should I add a note about this: a comment at the top of whatsnew.tex, maybe? I do go over Misc/NEWS every so often. --amk ___ 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
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 compatibility? 3. Create a new function with the new behavior (as you proposed the last time there was a patch submitted for this) What to do with the old function in this case? 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
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 extension (or a file
with an extension but no name, so you will.) 2.7/3.0 see the change in
semantics.
Would you like to work on that? Feel free to undo my changes as needed,
although I think the merging of the various implementations of splitext
can be kept, as should the additional test cases (just with a different
outcome). The tracker reports need to be updated to indicate the change,
too.
- People who rely on the documented, tested, ages-old behaviour will
get fair warning that the behaviour will change. I don't mean just
programmers. I mean users, too. Yes, users will get to see the warning
and many of them might not be able to do something about it. Well,
considering this class of users would get a behavioural change, and
quite likely a bug, giving them a warning hardly seems intrusive.
Here I disagree. I believe many people will see the warning that won't
see any behavior change (except for temporarily getting a warning).
Much code will do
for fn in os.listdir(path):
if os.path.splitext(fn)[1] in ('.c', '.h', '.vcproj'):
some_action
This code will be unaffected by the change, unless people have
a file called .c in a directory.
- People who (inadvertently) rely on the new behaviour get a warning
that their code is currently bugged. This includes users, too, of
course: they get a warning that this program is bugged in older versions
of Python. If there was a way to telepathically warn the actual
programmer, that would be better, but there isn't, so we can't. We will
have to use the user as the messenger.
But we do warn the programmer: there is a change in the documentation
(not just Misc/NEWS).
What it does
now is not. Changing it is the right thing, but changing it without
first warning about it is not.
Ok, I can accept a solution that will allow it to be changed eventually,
although I'm not happy with producing a warning. So, as I said, if
somebody wants to commit such a change, go ahead. If you want me to
review it first, I can do that as well.
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
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 how splitext works, or just roll their own and stop calling splitext entirely, because its behavior is not consistent across versions. 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 behavior will have to write a wrapper - whether they explicitly code for the old behavior or the new one. 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
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 Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 How would that help backwards compatibility? By providing it! The suggestion would retain the same behavior unless a newly-specified aspect of the API is exercised, therefore avoiding gratuitous change to existing programs' functionality. Since the default would be to behave as the existing function does then you would have to specify a True value for the strange-and-incomprehensible-treatment-of-dotfiles to get the behavior as specified in the patch you just applied. This seems like the best option to me, as clearly there are enough different opinions about whether the old or the new behavior is a bug that a user-selectable behavior is actually desirable. My suspicion is that most users just won't care about dotfiles, and will continue to use splitext as is. Windows users are always surprised to see them appearing, but they are becoming more common as open source functionality migrates to Windows. But those who do care (as you obviously do) can use bizarreAndInexplicableDotfileBehavior=True ;-) 3. Create a new function with the new behavior (as you proposed the last time there was a patch submitted for this) What to do with the old function in this case? Presumably keep it, thereby adding to the bloat in the language - definitely NOT my preferred option. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com See you at PyCon? http://us.pycon.org/TX2007 ___ 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
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 Python version to figure out how splitext works, or just roll their own and stop calling splitext entirely, because its behavior is not consistent across versions. 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 behavior will have to write a wrapper - whether they explicitly code for the old behavior or the new one. How is forcing people to write such a wrapper better than providing an optional argument (defaulting to current behavior) to specify the behavior they want? Presumably people who already care enough to want the patched behavior have already written such a wrapper around the current version. This should continue to work, albeit with less than exemplary efficiency. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com See you at PyCon? http://us.pycon.org/TX2007 ___ 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
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 extension means. Proposals to add sorted dictionaries or routines to add non-duplicate items to a list or to flatten data structures are routinely rejected for the same reason: users are recommended to write a routine that does what their particular application needs. 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 several years, and the documentation would now make it obvious to new users of the function that there's a choice about how to handle dotfiles. Heck, we could throw in another optional argument to strip multiple extensions like .tar.gz. For that matter, the documentation should address the issue that no matter what options you use, you may *still* end up with unexpected results, for files like Release 1.2, due to the fuzzy nature of the concept of a file extension on modern OSes. 3. Create a new function with the new behavior (as you proposed the last time there was a patch submitted for this) What to do with the old function in this case? Leave it alone - it's not broken. If people have buggy programs because they assumed '.foo' files were handled in a way that the docstrings and tests clearly indicate they are *not*, and they didn't test their *own* program, it's not Python's responsibility to fix their programs. ___ 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
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 that's more obviously disagreeable. The problem (as I see it) is that people who favor the change seem to be trying to use the specifics of this case to justify it -- but my point is that special cases aren't special enough to break the rules. And, that the rules shouldn't be changed to majority wins, if they think it's 'obviously' a bug. (Aside from all that, I also couldn't think of any milder examples of a popular, yet controversial change at that particular moment.) ___ 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
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 several years, and the documentation would now make it obvious to new users of the function that there's a choice about how to handle dotfiles. Heck, we could throw in another optional argument to strip multiple extensions like .tar.gz. 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 the last dot to the end of the string. ext will be empty if there are no dots in the name and root will be empty if the characters starts with a single dot and that is the only dot in the name. If ignore_leading_dot=True, then a leading dot is always considered part of root, and is ignored when determining the extension. root will never be empty in this case. If all_ext=True, the extension is all characters from the first dot to the end. For that matter, the documentation should address the issue that no matter what options you use, you may *still* end up with unexpected results, for files like Release 1.2, due to the fuzzy nature of the concept of a file extension on modern OSes. Not sure what can be done about that... although such filenames are likely a big reason why grabbing 'all extensions' will typically be a bad idea. Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
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, right? Or is this PEP-required (please no...)? No pep. 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, and 'output' would be the combined stdout/stderr. 'commands.getstatus' would be removed entirely [0]. This mimics 'commands' fairly closely, while adhering to PEP 8 guidelines; it's a simple API; and it should be dead easy to implement. Right. Does it also match the style of the API provided by the subprocess module? It will also have the various advantages people have mentioned: * better error trapping; * better post-fork behavior; * multi-platform support; If this sort of thing goes in, I guess commands.* would then be deprecated with a note saying go look at these similar commands in subprocess, right? Yes. Another intermediate step might be to rewrite the commands module to call the new APIs in the subprocess module. An additional function that I would personally like is: (status, output, errout) = subprocess.get_status_output_err(cmd) although the name is hideous. I'd like to change 'get_status_output' to return a triple, but I'm not sure how big a change that would be relative to the expected behavior from the ancestral commands function. Call it get_status_output_errors and you have my blessings. If at all possible, get_status_output should *not* just concatenate the output and errors from this API, but attempt to really *merge* the stdout and stderr stream so that if they are interleaved they come out in the right order. That's what the old getstatusoutput() did by putting '21' around the command. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
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 commands completely. I'm happy to do it either way. Yeah, but the deprecation rules require that the commands module has to stay around for at least one release; the quickest we can go is to deprecate it in 2.6 and remove it in 2.7. However, it would be fine to reimplement it in 2.6 using calls to subprocess. Anyway, don't sweat it. Either way will be fine. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
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 behavior will have to write a wrapper - whether they explicitly code for the old behavior or the new one. How is forcing people to write such a wrapper better than providing an optional argument (defaulting to current behavior) to specify the behavior they want? 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 the flag, the code stops working on old versions, so it will *not* be backwards compatible. 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
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 ___ 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
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 the flag, the code stops working on old versions, so it will *not* be backwards compatible. I don't understand. Under Nick's proposal, calling splitext with no keyword parameters results in the exact behavior we have today, so it's obviously backward compatible. If you use a keyword parameter, you're using a new feature implemented in 2.6, so there is no expectation of backward compatibility unless and until the keyword parameters are backported. Mike ___ 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
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 patches to change its behavior explicitly rejected in the past), as a bug. Just to put this into context, the word bug is probably not the best to use here. The orignal behaviour was described as a bug, certainly, but that's not how the change has been treated. [...] Rather, the change is being treated as a behaviour change (which it is) and submitted for a *feature* release (2.6). Very well put, and the main point. Whether the behaviour change is good, reasonable, acceptable - that's the question here. (And one on which I don't have an opinion!) That definition of the question is open-minded of you. However, Phillip's point remains valid. Eg, Martin's clear preference for not changing API and mild resistance to a warning suggests that the design of this change is strongly influenced by the feeling that current behavior is a bug. I think that's inappropriate. Note that Phillip (and glyph, AIUI) is not opposing a behavior change in Python; he simply wants the current API to keep the same spec (here I mean the docstring). I have seen many discussions like this one on various Emacs-related lists, and I would not use a mild phrase like the word 'bug' is probably not the best to use here. In my experience, use of the word bug to describe behavior that is consistent with all documented specifications is usually a political play. When such a change is described as a feature, the majority of programmers who haven't careful studied the spec will say I thought it already does that now, and I wish it would. When it is described as a bugfix, that changes to I thought it already does that now, so I demand that it do so. (All this is much less true of Python, but the dynamic can be seen here, too.) That is, even in a feature release backward compatibility is very important, it's just not paramount any more. If you describe it as a new feature, then people are very likely to accept the admittedly expensive process of defining a new API for the improved behavior, and where necessary deprecating the old behavior, and finally removing it. If you describe it as a bugfix, many will not. My opinion is that this shift of atmosphere leads to bad decisions. In cases where behavior conforms to spec, the process of define new API -- deprecate -- remove, though expensive, is almost always a good investment. It both lowers compatibility costs, and makes them much more plan-able. These costs are both large and easy to underestimate, so that's a very good thing. ___ 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
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 versions. This is also whz I wondered how the flag helps backwards compatibility: when people add the flag, the code stops working on old versions, so it will *not* be backwards compatible. I don't understand. Under Nick's proposal, calling splitext with no keyword parameters results in the exact behavior we have today, so it's obviously backward compatible. If you use a keyword parameter, you're using a new feature implemented in 2.6, so there is no expectation of backward compatibility unless and until the keyword parameters are backported. Let's remember the lessons of True and False in Python 2.2.1. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRfr04nEjvBPtnXfVAQKxXgP9GmIx6OANec+aGsT9X9KoJsWLM+RGYrjB RuDy5uxIbxfZg0logFzvTH4iLCnjJzfhhFrc8V9RjDf7I8vubM+caaEvZBDRoabW bNO6L4IA1zGKjmKYhVhnLkRFNk3iEHwvG9Fa4ahqcCaeS99IYBejwtZ0Sqd171dL ZQnUFBT5vBU= =NlKx -END PGP SIGNATURE- ___ 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
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 compatibility: when people add the flag, the code stops working on old versions, so it will *not* be backwards compatible. I don't understand. Under Nick's proposal, calling splitext with no keyword parameters results in the exact behavior we have today, so it's obviously backward compatible. If you use a keyword parameter, you're using a new feature implemented in 2.6, so there is no expectation of backward compatibility unless and until the keyword parameters are backported. 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. 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
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 the last dot to the end of the string. ext will be empty if there are no dots in the name and root will be empty if the characters starts with a single dot and that is the only dot in the name. If ignore_leading_dot=True, then a leading dot is always considered part of root, and is ignored when determining the extension. root will never be empty in this case. If all_ext=True, the extension is all characters from the first dot to the end. = 'first dot' = 'first non-ignored dot' in case both options are true. In the long run (in 3.0), I think ignore_leading_dot should default to True rather than False since I think that is what more people will want. However, I believe the 2-to-3 converter could remove 'ignore_leading_dot=True' and insert 'ignore_leading_dot=False' as needed. Terry Jan Reedy ___ 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
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 existing calls to splitext() would work the same way they've done for several years, and the documentation would now make it obvious to new users of the function that there's a choice about how to handle dotfiles. Heck, we could throw in another optional argument to strip multiple extensions like .tar.gz. 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 the last dot to the Presumably that would be the last dot after the last separator (i.e. / and/or \). I would not expect ext to ever contain a separator. end of the string. ext will be empty if there are no dots in the name and root will be empty if the characters starts with a single dot and that is the only dot in the name. If ignore_leading_dot=True, then a leading dot is always considered part of root, and is ignored when determining the extension. root will never be empty in this case. If all_ext=True, the extension is all characters from the first dot to the end. For that matter, the documentation should address the issue that no matter what options you use, you may *still* end up with unexpected results, for files like Release 1.2, due to the fuzzy nature of the concept of a file extension on modern OSes. Not sure what can be done about that... although such filenames are likely a big reason why grabbing 'all extensions' will typically be a bad idea. Regards, Nick. -- Sjoerd Mullender ___ 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
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 you don't use the flags approach, your code will silently fail on the old versions. Pat ___ 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
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. But, that's a GOOD thing. If you don't use the flags approach, your code will silently fail on the old versions. Whether it will fail depends on the code. It will silently behave differently, but it will not (necessarily) fail. 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
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 supports such a change, Martin would oppose a policy which would strictly forbid such changes, and it is just such a policy that Python needs. I still can't guess what policy you have in mind, so I can't object to it :-) I may accept a policy that rejects this change, but allows another change to fix the problem. I would oppose a policy that causes this bug to be unfixable forever. Well, there's *also* the fact that I strongly disagree that this is a bug, but I don't know that I could codify that in a policy. Hence the parallel discussion. However, I do apologize for obliquely referring to this thing I'm working on without showing a work in progress. It's just that different parts of the policy will rely on each other, and I don't want to get bogged down talking about individual details which will be dealt with in the final rev. That, and I am trying to integrate feedback from the ongoing discussion... ___ 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
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 blocking the user interface. You don't know how long it will take, so you want the user to be able to cancel it if he gets bored. That's a perfectly reasonable use-case which doesn't require this feature at all ;). Interaction with the rest of the program is extremely limited -- some data is passed in, it churns away, and some data is returned. It doesn't matter what happens to its internal state if it gets interrupted, as it's all going to be thrown away. If that's true, then the state-sharing features of threads aren't required, which is the right way to design concurrent software anyway. In that situation, it doesn't seem unreasonable to me to want to be able to just kill the thread. I don't see how it could do any more harm than using KeyboardInterrupt to kill a program, because that's all it is -- a subprogram running inside your main program. The key distinction between threads and processes is the sharing of internal program state. How would you handle this situation? Spawn a process, deliver the result via an event. If you're allergic to event-driven programming, then you can spawn a process *in* a thread, and block in the thread on reading from the process's output, then kill the *process* and have that terminate the output, which terminates the read(). This is a lot like having a queue that you can put a stop object into, except the file interface provided by OSes is kind of crude. Still no need to kill the thread. At the end of the day though, you're writing a GUI in this use-case and so you typically *must* be cognizant of event-driven issues anyway. Many GUIs (even in the thread-happy world of Windows) aren't thread-safe except for a few specific data-exchange methods, which behave more or less like a queue. One of the 35 different existing ways in which one can spawn a process from Python, I hope, will be sufficient for this case :). ___ 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
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/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 ___ 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
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 the beginning? Yes. How many more times would you like me to answer this question? Just in case you'd like me to answer it three more times, here are the answers: Yes, yes, and yes. Mike ___ 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
[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 the future - or point me to the appropriate communities/forums to look for such a topic? I'm mostly looking for places to start researching my options. thank you, Arnar ___ 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
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(), however, returns the output of ls -ld - file which is completely nonobvious and confusing. - - +1. - - Perhaps the whole commands module can be deprecated in favor of subprocess. - - -1. - - Reason (for both voteS): I have learned that the getoutput() and - getstatusoutput() functions in the commands module are exceedingly - popular amongst Googlers who write simple Python scripts that - occasionally invoke an external command. It's much simpler than using - os.popen() or the subprocess module (which is also very popular BTW). What about reimplementing commands.* using subprocess? Or providing a commands.*-compatible interface in the subprocess module? cheers, --titus ___ 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
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 simplicity of the commands interface on top of the more functional subprocess interface, no? subprocess is very powerful but there isn't a simple way to get the output. See http://docs.python.org/lib/node530.html, and see the docs comparing os.system() with subprocess, http://docs.python.org/lib/node537.html So, if you added 'getstatusoutput' and 'getoutput'-style commands to the subprocess module, you would (a) be able to deprecate a module in the stdlib, simplifying it a bit, and (b) provide simple commands implementing a common use case for subprocess, run this command and give me the output. (You can already do 'getstatus' with a 'Popen(cmd).wait()'.) cheers, --titus ___ 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
[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 out who is being employed to work on python and who is doing it on their own time? Some of my data points to there being two ways that people make the jump. More specifically, could those who worked on python as some aspect of their job prior to getting repo access let me know? Or if there are devs who know this information about others, I'd be really appreciative to get it. Thanks a lot. -- Christian Bird -- Christian Bird [EMAIL PROTECTED] ___ 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
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 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, and 'output' would be the combined stdout/stderr. 'commands.getstatus' would be removed entirely [0]. This mimics 'commands' fairly closely, while adhering to PEP 8 guidelines; it's a simple API; and it should be dead easy to implement. It will also have the various advantages people have mentioned: * better error trapping; * better post-fork behavior; * multi-platform support; If this sort of thing goes in, I guess commands.* would then be deprecated with a note saying go look at these similar commands in subprocess, right? An additional function that I would personally like is: (status, output, errout) = subprocess.get_status_output_err(cmd) although the name is hideous. I'd like to change 'get_status_output' to return a triple, but I'm not sure how big a change that would be relative to the expected behavior from the ancestral commands function. cheers, --titus [0] As per GvR, http://mail.python.org/pipermail/python-dev/2007-March/071926.html ___ 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
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, and 'output' - would be the combined stdout/stderr. 'commands.getstatus' would be - removed entirely [0]. - - This mimics 'commands' fairly closely, while adhering to PEP 8 - guidelines; it's a simple API; and it should be dead easy to implement. - - Right. Does it also match the style of the API provided by the - subprocess module? Yes; subprocess has only two convenience functions apart from the main class, in fact, and their names are quite short and simple. - It will also have the various advantages people have mentioned: - - * better error trapping; - * better post-fork behavior; - * multi-platform support; - - If this sort of thing goes in, I guess commands.* would then be - deprecated with a note saying go look at these similar commands in - subprocess, right? - - 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 commands completely. I'm happy to do it either way. - An additional function that I would personally like is: - - (status, output, errout) = subprocess.get_status_output_err(cmd) - - although the name is hideous. I'd like to change 'get_status_output' - to return a triple, but I'm not sure how big a change that would be - relative to the expected behavior from the ancestral commands function. - - Call it get_status_output_errors and you have my blessings. If at all - possible, get_status_output should *not* just concatenate the output - and errors from this API, but attempt to really *merge* the stdout and - stderr stream so that if they are interleaved they come out in the - right order. That's what the old getstatusoutput() did by putting - '21' around the command. I believe that this is what subprocess.Popen(..., stdout=subprocess.PIPE, stderr=subprocess.STDOUT) does, but I will check to be sure. --titus ___ 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
Re: [Python-Dev] [ 1673007 ] urllib2 requests history + HEAD
From: Facundo Batista [EMAIL PROTECTED] mailto:[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, because it can easily grow up to thousands and explode (a.k.a. consume too much memory). Fo example, I have a web service, running 7x24, and opening another web service, with around 10 requests per second. This means, keeping the history (around 50bytes each request), 1.2 GB of RAM in only a month! So, I'll close this patch as Rejected, for this reason, if anyone raises objections. Regards, -- . Facundo This is probably a misunderstanding. Request's history don't store in the module.They store in two places: 1) In Request object (for current request, so they would be destroyеd with it); 2) In HTTPConnection object (while request redirects). In HTTPConnection history stores only for current served Request. Even if You use the same HTTPConnection for many Requests, they (HTTPConnection) clear history every time when new Request starts. # from httplib HTTPConnection.putrequest patched str = '%s %s %s' % (method, url, self._http_vsn_str) self._output(str) self.sended_hdrs = [str] previous history die here ___Full history for all processed request didn't not stored in any place. P.S. This message may be duplicated - first copy i sent from gmail.com and it didn't reach mail list for some unknown for me reasons. --- KDanilov aka koder(aka koder_ua) ___ 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
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 well-specified algorithm on file names containing dots, but (except on certain file systems such as FAT) the extension does not uniquely exist. People and programs will disagree on the decomposition of file.tar.gz. On FAT file systems, it's defined incorrectly according to you. As IIRC glyph pointed out, if you're going to include either shell semantics (dotfiles) or content semantics (file type for a generic open anything command) in the specification of file extension, what I prefer is guess_file_type(), not splitext(). A more emphatic way to express this is, I would never use a library function whose semantics were defined as split a file name into the base and the extension because I would expect gratuitous backward incompatibility of the kind you have introduced (and it could go either way).[1] N.B. Backward compatibility can be defined by reference to an implementation (often denigrated as bug compatibility) or to a specification. This change is backward incompatible with respect to the implementation and the docstring specification. I would personally prefer the 2.4 definition of splitext(), merely because it's so simple. I would (absent this long discussionwink) always have to look up the treatment of dotfiles, anyway, and my own only use (in one function, 3 calls) of splitext is precisely def versioned_file_name (filename, version): base, ext = splitext (filename) return %s.%s%s % (base,version,ext) 2. Add an optional flag argument to enable the new behavior How would that help backwards compatibility? As Steve Holden points out, by preserving it if the flag is omitted. That is so obvious that I think merely asking that question is perverse. You seem to be granting official status to the unwritten and controversial intuitive specification that many programmers guess from the name. That is way out of line with any sane interpretation of compatibility with past versions of Python. I think all of the advocates of changing the function rather than the library reference are being very short-sighted. I agree with you that looking at this one case, it will be very expensive for all those who have (currently broken) code that expects splitext to treat dotfiles as having a base that starts with a dot (rather than an empty base) to change to use a new function. (I think the realistic solution for them is monkeypatching.) But using this to justify the backward incompatibility is like thinking you can eat just one potato chip, and so not go off your diet. The incompatibility costs of applying this greedy algorithm to all cases where the Python specification differs from common intuition will not merely be very expensive, they will be astronomically so -- but practically invisible because the cost will be in terms of developers who refuse to upgrade their applications to take advantage of new features of Python because their own library code gets broken. The only path I can see where it makes sense to make this change is as an appendix to glyph's PEP. The appendix could give a list of such changes and the decision, relative to some base version. Or it could specify that contributions to 2.6 can be backward incompatible, but not afterward. In that case the promise to eat only this one potato chip becomes credible. I prefer the explicit list approach, that would force the discussion to occur in one place, so that both proponents and opponents of each change would be made aware of how many such changes are being made. Footnotes: [1] ___ 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
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 have a single dot at the beginning? Yes. How many more times would you like me to answer this question? Just in case you'd like me to answer it three more times, here are the answers: Yes, yes, and yes. So that would be a yes, then. Perhaps you'd like to remind me that backward compatibilty includes the necessity to run new programs on old versions of Python, too? Then I can stop wasting everyone's time. Even though I am no fonder of code breakage than I was. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com See you at PyCon? http://us.pycon.org/TX2007 ___ 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
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 levels of backward compatibility: 1) If you are absolutely sure that the code in your program will never be used to work with filenames with leading dots, you are already finished! (Note that this goal is much easier to achieve if you don't release the source, or at least write it so badly that nobody will want to reuse the code.) 2) If you think that most users of your program won't use filenames with leading dots, and you don't plan on supporting it after a year or so, just make sure it works with 2.5. 3) Conversely, if you're not that bothered about leading dots, and don't think you'll have all the bugs out of your program for a year or so anyway, just wait for 2.6. (All the cool potential users of your program will be on the bleeding edge, anyway.) 4) Finally, if you're one of those Luddite sticklers who wants to try to ruin everybody's job security by writing code that works right now and doesn't need to be touched later, just write your own version of this function. I would have suggested that you could reuse the underlying functionality in conjunction with a version check, but it has been pointed out that the existence of tests and docstrings which perfectly match the code is no impediment to change, so Philip might get mad enough to change it back for 3.1, and then your version check would be obsolete. Then I can stop wasting everyone's time. Even though I am no fonder of code breakage than I was. Fortunately, for new code (at least for this particular change!), you don't have to worry about breakage. I'm sure this discussion has been so indelibly etched into your brain that you won't forget to check your filename management functions very carefully. Sorry, were you being sarcastic? I didn't realize that. Or am I prevaricating again? Regards, Pat ___ 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
[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.python.org does not exist anymore (2007-03-12) CLOSED http://python.org/sf/1678662 opened by Björn Lindqvist fix a bug mixing up 0.0 and-0.0 (2007-03-11) http://python.org/sf/1678668 opened by Alex Martelli Allow datetime in date (2007-03-12) CLOSED http://python.org/sf/1679204 opened by Collin Winter Documentation for fnmatch.translate() (2007-03-12) CLOSED http://python.org/sf/1679379 opened by Björn Lindqvist __slots__ tuple modified inplace if it contains unicode name (2007-03-13) CLOSED http://python.org/sf/1680015 opened by ?iga Seilnacht CGIHTTPServer doesn't handle path names with embeded space (2006-08-06) http://python.org/sf/1535504 reopened by htgoebel Add tests for pipes module (test_pipes) (2007-03-14) http://python.org/sf/1680959 opened by Alan McIntyre remove sys.exitfunc, rewrite atexit in C (2007-03-14) http://python.org/sf/1680961 opened by Georg Brandl Use alive instead of active in the docs for threading (2007-03-14) CLOSED http://python.org/sf/1680978 opened by Björn Lindqvist binary and new-style octal literals (2007-03-14) http://python.org/sf/1681002 opened by Thomas Wouters PEP 3115 patch (2007-03-14) http://python.org/sf/1681101 opened by Guido van Rossum Patch for [ 1603150 ] wave module forgets to close... (2007-03-15) CLOSED http://python.org/sf/1681153 opened by Patricio Olivares email.header unicode fix (2007-03-15) http://python.org/sf/1681333 opened by Tokio Kikuchi Add triangular distribution to random (2007-03-15) http://python.org/sf/1681432 opened by Wladmir splitext of dotfiles, incl backwards compat and migration (2007-03-16) http://python.org/sf/1681842 opened by Stephen Hansen Patches Closed __ Patch to 742342 Crash on recursive reload (2004-03-23) http://python.org/sf/922167 closed by collinwinter add optional CWD argument to os.path.abspath() (2003-01-30) http://python.org/sf/677890 closed by collinwinter ftp.python.org does not exist anymore (2007-03-11) http://python.org/sf/1678662 closed by collinwinter fix for external test regression in test.regrtest (2003-09-17) http://python.org/sf/808210 closed by collinwinter urllib2.URLError don't calll IOError.__init__ (2003-10-02) http://python.org/sf/816787 closed by collinwinter Refactor test_threadedtempfile.py to use unittest. (2007-02-28) http://python.org/sf/1670993 closed by collinwinter urllib2.urlopen() raises OSError instead of URLError (2007-02-24) http://python.org/sf/1668100 closed by gbrandl site.py small ?bug fix | change? (2007-03-10) http://python.org/sf/1677862 closed by loewis adding __dir__ (2006-11-06) http://python.org/sf/1591665 closed by gbrandl Refactor test_operations.py to use unittest. (2007-03-10) http://python.org/sf/1678088 closed by collinwinter Add current dir when running try_run test program (2005-03-21) http://python.org/sf/1168055 closed by collinwinter Allow datetime in date (2007-03-12) http://python.org/sf/1679204 closed by collinwinter Documentation for fnmatch.translate() (2007-03-12) http://python.org/sf/1679379 closed by gbrandl comments to clarify complexobject.c (2007-01-23) http://python.org/sf/1642844 closed by gbrandl Fix for bugs relating to ntpath.expanduser() (2004-05-20) http://python.org/sf/957650 closed by gbrandl Add %var% support to ntpath.expandvars (2006-10-10) http://python.org/sf/1574252 closed by gbrandl CSV DictWriter Errors (2007-01-15) http://python.org/sf/1635454 closed by gbrandl test_cmd_line fails on Windows (2006-09-15) http://python.org/sf/1559413 closed by loewis Performance enhancements. (2006-09-09) http://python.org/sf/1555098 closed by gbrandl Tweak pydoc to speak about with and CONTEXTMANAGERS (2006-08-18) http://python.org/sf/1542681 closed by gbrandl Fix building the source within exec_prefix (2006-10-03) http://python.org/sf/1569798 closed by gbrandl email.message.py charset can be unicode instance (2006-03-14) http://python.org/sf/1449244 closed by loewis Allow __class __ assignment for classes with __slots__ (2006-12-28) http://python.org/sf/1623563 closed by zseil __slots__ tuple modified inplace if it contains unicode name (2007-03-13) http://python.org/sf/1680015 closed by zseil ConfigParser does not quote % (2007-01-15) http://python.org/sf/1635639 closed by gbrandl Allow textwrap to preserve leading and trailing whitespace (2006-10-20)
