Re: [Python-Dev] These csv test cases seem incorrect to me...
Hi Skip,
On 2007-03-12 03:01, [EMAIL PROTECTED] wrote:
> I decided it would be worthwhile to have a csv module written in Python (no
> C underpinnings) for a number of reasons:
>
> * It will probably be easier to add Unicode support to a Python version
>
> * More people will be able to read/grok/modify/fix bugs in a Python
> implementation than in the current mixed Python/C implementation.
>
> * With alternative implementations of Python available (PyPy,
> IronPython, Jython) it makes sense to have a Python version they can
> use.
Lots of good reasons :-)
I've written a Python-only Unicode aware CSV module for a client (mostly
because CSV data tends to be quirky and I needed a quick way of dealing
with corner cases). Perhaps I can get them to donate it to the PSF...
> I'm far from having anything which will pass the current test suite, but in
> diagnosing some of my current failures I noticed a couple test cases which
> seem wrong. In the TestDialectExcel class I see these two questionable
> tests:
>
> def test_quotes_and_more(self):
> self.readerAssertEqual('"a"b', [['ab']])
>
> def test_quote_and_quote(self):
> self.readerAssertEqual('"a" "b"', [['a "b"']])
>
> It seems to me that if a field starts with a quote it *has* to be a quoted
> field. Any quotes appearing within a quoted field have to be escaped and
> the field has to end with a quote. Both of these test cases fail on or the
> other assumption. If they are indeed both correct and I'm just looking at
> things crosseyed I think they at least deserve comments explaining why they
> are correct.
>
> Both test cases date from the first checkin. I performed the checkin
> because of the group developing the module I believe I was the only one with
> checkin privileges at the time, not because I wrote the test cases.
>
> Any ideas about why these test cases are in there? I can't imagine Excel
> generating either one.
My recommendation: Let the module do whatever Excel does with such data.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Mar 14 2007)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free !
___
Python-Dev mailing list
[email protected]
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: > What does that buy us? subprocess offers better error-trapping, I think, and additional features such as closing all file descriptors after forking. At work, I found this fixed a number of bugs in our daemons code because if you were starting something long-running, it might keep a socket open and cause problems later. --amk ___ Python-Dev mailing list [email protected] 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()
Guido van Rossum wrote: >> What about reimplementing commands.* using subprocess? Or providing a >> commands.*-compatible interface in the subprocess module? > > What does that buy us? multi-platform support? (commands is Unixoid only, right?) ___ Python-Dev mailing list [email protected] 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()
Alright already! It wasn't a thetorical question, and I'm convinced! :-) On 3/14/07, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > >> What about reimplementing commands.* using subprocess? Or providing a > >> commands.*-compatible interface in the subprocess module? > > > > What does that buy us? > > multi-platform support? (commands is Unixoid only, right?) > > > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] thread safe SMTP module
A couple of weeks ago, I posted a message titled "thread safe SMTP module" on python-list. It's oddly split in the archive: http://mail.python.org/pipermail/python-list/2007-March/429067.html http://mail.python.org/pipermail/python-list/2007-March/429172.html A while ago, I wrote an address validation function using smtplib.SMTP for use in a a threaded application. In practice, I found that the application locked up rather frequently. I scratched my head for a while before concluding that the caveat mentioned in the thread module's documentation, noting that some built-in functions may block all threads, was probably at fault. I then subclassed smtplib.SMTP and replaced all of the blocking I/O operations with nonblocking ones, and the function began working properly. After some discussion, Aahz suggested that I discuss the problem here, on python-dev. He seemed to think that the problem I saw may have been an indication of a bug in python. Could anyone take a look at that thread and say whether it looks like a bug, or working with non-blocking sockets was the right thing to do? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Proposal to revert r54204 (splitext change)
In addition to being made in the face of controversy and opposition, this change is an alteration to *documented and tested* behavior and thus cannot reasonably be considered a mere bug fix. In addition to the prior behavior being explicitly documented in the function docstrings, r54204 shows that it was also *tested* as behaving that way by test_macpath, test_ntpath, and test_posixpath. When combined with the explicit docstrings, this must be considered incontrovertible proof that the previous behavior was either explicitly intended, or at the very least a known, expected, and *accepted* behavior. This backwards-incompatible change is therefore contrary to policy and should be reverted, pending a proper transition plan for the change (such as introduction of an alternative API and deprecation of the existing one.) Some relevant links: http://svn.python.org/view?rev=54204&view=rev http://mail.python.org/pipermail/python-dev/2007-March/071762.html http://mail.python.org/pipermail/python-dev/2007-March/071798.html ___ Python-Dev mailing list [email protected] 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: > This backwards-incompatible change is therefore contrary to policy and > should be reverted, pending a proper transition plan for the change > (such as introduction of an alternative API and deprecation of the > existing one.) I'm clearly opposed to this proposal, or else I wouldn't have committed the change in the first place. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] thread safe SMTP module
Gordon Messmer <[EMAIL PROTECTED]> wrote: > After some discussion, Aahz suggested that I discuss the problem here, > on python-dev. He seemed to think that the problem I saw may have been > an indication of a bug in python. Could anyone take a look at that > thread and say whether it looks like a bug, or working with non-blocking > sockets was the right thing to do? Well, not having to faff around with non-blocking IO is one of the major advantages of threading, so if blocking IO is indeed the cause of your problem then it certainly sounds like a bug in Python, or possibly your operating system. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] thread safe SMTP module
On Wed, Mar 14, 2007, Jon Ribbens wrote: > Gordon Messmer <[EMAIL PROTECTED]> wrote: >> >> After some discussion, Aahz suggested that I discuss the problem here, >> on python-dev. He seemed to think that the problem I saw may have been >> an indication of a bug in python. Could anyone take a look at that >> thread and say whether it looks like a bug, or working with non-blocking >> sockets was the right thing to do? > > Well, not having to faff around with non-blocking IO is one of the > major advantages of threading, so if blocking IO is indeed the cause > of your problem then it certainly sounds like a bug in Python, or > possibly your operating system. One small wrinkle (and the reason I suggested bringing this to python-dev): I suspect that the problem is not a bug, but simply the occasional failure of sockets. When that happens in a threaded app without timeouts, eventually threads "die" (block forever). But you apparently can't use timeouts with file-wrapped sockets, so if that's the problem, we need to pick one of: * switch to non-wrapped sockets * switch to non-blocking I/O for smtplib * make file-wrapped sockets work with timeouts (And please note that if my analysis is correct, we need to make the fix for non-threaded apps, it's just more unusual to encounter the problem there.) This level of design decision is beyond my capabilities. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "I disrespectfully agree." --SJM ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] thread safe SMTP module
Gordon Messmer <[EMAIL PROTECTED]> wrote: > After some discussion, Aahz suggested that I discuss the problem here, > on python-dev. He seemed to think that the problem I saw may have been > an indication of a bug in python. Could anyone take a look at that > thread and say whether it looks like a bug, or working with non-blocking > sockets was the right thing to do? His most recent message in that thread actually said, "No, at this point I think this is neither bug nor about thread blocking on I/O. I think it's about sockets dying and the inability of sockets in blocking mode to recover. I have seen this kind of behavior in single-threaded systems." I would concur with Aahz, more or less. I have also seen this behavior on single-threaded blocking systems. The real issue may be related to blocking sockets breaking coupled with socket.makefile(...).readline() not being able to handle the breakage. If you can, try to dig into the file object implementation returned by socket.makefile(). If you don't want to (I would understand), try replacing smtplib's use of 'self.file.readline()' with a Python variant that handles failures more gracefully. Heck, you could even add timeouts (which are being added to httplib and either urllib or urllib2). - Josiah As an aside, for even minimally loaded systems, I've noticed that file.readline() isn't any faster than just using a while loop with socket.recv() and checking for '\n'. I believe that it would make sense to replace certain libraries' (poplib, smtplib, etc.) use of file.readline() with that of a _readline() method that has a default implementation using either a file.readline() or sock.recv() in a loop. By pulling it out into a single method, the user could easily override it if it isn't doing what they want/expect. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] thread safe SMTP module
Aahz <[EMAIL PROTECTED]> wrote: > One small wrinkle (and the reason I suggested bringing this to > python-dev): I suspect that the problem is not a bug, but simply the > occasional failure of sockets. When that happens in a threaded app > without timeouts, eventually threads "die" (block forever). But you > apparently can't use timeouts with file-wrapped sockets, so if that's the > problem, we need to pick one of: > > * switch to non-wrapped sockets > * switch to non-blocking I/O for smtplib > * make file-wrapped sockets work with timeouts In case it's helpful, I've put the file-like-sockets-with-timeouts code that I wrote up here: http://www.unequivocal.co.uk/dl/socketutils.py This is a pure-Python implementation that provides a file-like interface to a socket, with timeouts, that definitely works with threaded programs. Note it was written in 2002, so any part of the Python 'file' interface which was added since then is not in there. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] thread safe SMTP module
Aahz wrote: > > One small wrinkle (and the reason I suggested bringing this to > python-dev): I suspect that the problem is not a bug, but simply the > occasional failure of sockets. When that happens in a threaded app > without timeouts, eventually threads "die" (block forever). IIRC, my whole process was locking up, not just individual threads. Tonight I should have time to pull an old copy of the code out of CVS and recreate the test script that I used. Once I have, it should be a matter of feeding a big list of email addresses to the script and waiting a couple of minutes for the script to lock up. The last time I looked, the problem was very easy to observe. ___ Python-Dev mailing list [email protected] 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 06:47 PM 3/14/2007 +0100, Martin v. Löwis wrote: >Phillip J. Eby schrieb: > > This backwards-incompatible change is therefore contrary to policy and > > should be reverted, pending a proper transition plan for the change > > (such as introduction of an alternative API and deprecation of the > > existing one.) > >I'm clearly opposed to this proposal, or else I wouldn't have committed >the change in the first place. That much is obvious. But I haven't seen any explanation as to why explicitly-documented and explicitly-tested behavior should be treated as a bug in policy terms, just because people don't like the documented and tested behavior. So far, the only policy justification I've seen you give was along the lines of, "I volunteered to do it, so I get to decide". If this statement were actually a valid policy, then I suppose I could simply volunteer to decide to revert the change. But if it's *not* a valid policy, then there is no policy justification for the change, and therefore it should be reverted. Thus, either way, there needs to be some *other* justification for the original change. ___ Python-Dev mailing list [email protected] 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 06:47 PM 3/14/2007 +0100, Martin v. Löwis wrote: > >> Phillip J. Eby schrieb: >> >>> This backwards-incompatible change is therefore contrary to policy and >>> should be reverted, pending a proper transition plan for the change >>> (such as introduction of an alternative API and deprecation of the >>> existing one.) >>> >> I'm clearly opposed to this proposal, or else I wouldn't have committed >> the change in the first place. >> > > That much is obvious. But I haven't seen any explanation as to why > explicitly-documented and explicitly-tested behavior should be treated as a > bug in policy terms, just because people don't like the documented and > tested behavior. > > Because it's clearly a bug and has even been shown to fix bugs in current code ? Honestly it is this sort of pointless prevarication that gives python-dev a bad name. Michael Foord ___ Python-Dev mailing list [email protected] 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, Michael Foord <[EMAIL PROTECTED]> wrote: Phillip J. Eby wrote: > At 06:47 PM 3/14/2007 +0100, Martin v. Löwis wrote: > >> Phillip J. Eby schrieb: >> >>> This backwards-incompatible change is therefore contrary to policy and >>> should be reverted, pending a proper transition plan for the change >>> (such as introduction of an alternative API and deprecation of the >>> existing one.) >>> >> I'm clearly opposed to this proposal, or else I wouldn't have committed >> the change in the first place. >> > > That much is obvious. But I haven't seen any explanation as to why > explicitly-documented and explicitly-tested behavior should be treated as a > bug in policy terms, just because people don't like the documented and > tested behavior. > > Because it's clearly a bug and has even been shown to fix bugs in current code ? Honestly it is this sort of pointless prevarication that gives python-dev a bad name. 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. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] 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: > In addition to being made in the face of controversy and opposition, > this > change is an alteration to *documented and tested* behavior and thus > cannot reasonably be considered a mere bug fix. FWIW, I support Phillip on this. There can be no question that the old behaviour was expected. IMO this is just gratuitous breakage. The only fix that shold be made is to the splitext documentation to match the docstring. A change to the documented behaviour should require a __future__ import for at least one version. That's even assuming that the change is desireable (I don't believe so). We have multiple anecdotes of actual, existing code that *will* break with this change. So far I haven't seen any actual code posted that is currently broken by the existing behaviour. Tim Delaney ___ Python-Dev mailing list [email protected] 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 08:30 AM 3/15/2007 +1100, Delaney, Timothy (Tim) wrote: >Phillip J. Eby wrote: > > > In addition to being made in the face of controversy and opposition, > > this > > change is an alteration to *documented and tested* behavior and thus > > cannot reasonably be considered a mere bug fix. > >FWIW, I support Phillip on this. There can be no question that the old >behaviour was expected. > >IMO this is just gratuitous breakage. The only fix that shold be made is >to the splitext documentation to match the docstring. > >A change to the documented behaviour should require a __future__ import >for at least one version. That's even assuming that the change is >desireable (I don't believe so). We have multiple anecdotes of actual, >existing code that *will* break with this change. So far I haven't seen >any actual code posted that is currently broken by the existing behaviour. FWIW, I think that, were we writing splitext() *now*, we should go with the proposed behavior. It's reasonable and justifiable even on Windows (even though Windows Explorer agrees with the current splitext() behavior.) But, that doesn't actually have any bearing on the current discussion, since splitext()'s behavior is existing and documented. Certainly, there *is* code that's broken by the existing behavior -- otherwise the patch would never have been submitted in the first place. However, that doesn't automatically make it a Python bug, especially if the existing behavior is documented and covered by regression tests. I just want to clarify this point, because I don't wish to enter another round of discussion about the merits of one behavior or the other: the merits one way or the other are pretty much irrelevant to the policy issue at hand. ___ Python-Dev mailing list [email protected] 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)
Delaney, Timothy (Tim) wrote: > Phillip J. Eby wrote: > > >> In addition to being made in the face of controversy and opposition, >> this >> change is an alteration to *documented and tested* behavior and thus >> cannot reasonably be considered a mere bug fix. >> > > FWIW, I support Phillip on this. There can be no question that the old > behaviour was expected. > > Expected ? It's perverse. :-) > IMO this is just gratuitous breakage. The only fix that shold be made is to > the splitext documentation to match the docstring. > > Agreed. > A change to the documented behaviour should require a __future__ import for > at least one version. That's even assuming that the change is desireable (I > don't believe so). We have multiple anecdotes of actual, existing code that > *will* break with this change. So far I haven't seen any actual code posted > that is currently broken by the existing behaviour. > There was code posted that used the (almost entirely sane) pattern : new_filename = os.path.splitext(old_filename)[1] + '.bak' That was broken but is now fixed. It follows the entirely natural assumption that filename without an extension would not have the filename put in the extension half of the tuple. The documentation (not the docstring) actually says : 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. Even the docstring only states that either part may be empty, hardly documenting what is clearly a misfeature. Michael Foord > Tim Delaney > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > > ___ Python-Dev mailing list [email protected] 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 08:30 AM 3/15/2007 +1100, Delaney, Timothy (Tim) wrote: > >> Phillip J. Eby wrote: >> >> >>> In addition to being made in the face of controversy and opposition, >>> this >>> change is an alteration to *documented and tested* behavior and thus >>> cannot reasonably be considered a mere bug fix. >>> >> FWIW, I support Phillip on this. There can be no question that the old >> behaviour was expected. >> >> IMO this is just gratuitous breakage. The only fix that shold be made is >> to the splitext documentation to match the docstring. >> >> A change to the documented behaviour should require a __future__ import >> for at least one version. That's even assuming that the change is >> desireable (I don't believe so). We have multiple anecdotes of actual, >> existing code that *will* break with this change. So far I haven't seen >> any actual code posted that is currently broken by the existing behaviour. >> > > FWIW, I think that, were we writing splitext() *now*, we should go with the > proposed behavior. It's reasonable and justifiable even on Windows (even > though Windows Explorer agrees with the current splitext() behavior.) > > But, that doesn't actually have any bearing on the current discussion, > since splitext()'s behavior is existing and documented. > > Certainly, there *is* code that's broken by the existing behavior -- > otherwise the patch would never have been submitted in the first > place. However, that doesn't automatically make it a Python bug, > especially if the existing behavior is documented and covered by regression > tests. > > I just want to clarify this point, because I don't wish to enter another > round of discussion about the merits of one behavior or the other: the > merits one way or the other are pretty much irrelevant to the policy issue > at hand. > It looks to me like a clear bugfix (the fact that there were unit tests for the insane behaviour doesn't make it any less a bug). The current docstring that states that the first element may be empty hardly counts as it being a 'documented feature'. At the least it is a grey area and not a policy reversal. The policy is that bugfixes can go in with warnings. So, as a debatable issue whether it is a bug (I think it is fairly clear), then it doesn't change or contravene policy. Michael Foord > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > > ___ Python-Dev mailing list [email protected] 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)
Michael Foord wrote: > There was code posted that used the (almost entirely sane) pattern : > > new_filename = os.path.splitext(old_filename)[1] + '.bak' > > That was broken but is now fixed. It follows the entirely natural > assumption that filename without an extension would not have the > filename put in the extension half of the tuple. Well, I'd argue the sanity of it, but you're right - it was posted. > The documentation (not the docstring) actually says : > > 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. > > Even the docstring only states that either part may be empty, hardly > documenting what is clearly a misfeature. splitext(p) Split the extension from a pathname. Extension is everything from the last dot to the end. ^ Return (root, ext), either part may be empty. That's pretty explicit. Tim Delaney ___ Python-Dev mailing list [email protected] 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)
Delaney, Timothy (Tim) wrote: > [snip..] >> >> Even the docstring only states that either part may be empty, hardly >> documenting what is clearly a misfeature. >> > > splitext(p) > Split the extension from a pathname. > > Extension is everything from the last dot to the end. > ^ > Return (root, ext), either part may be empty. > > That's pretty explicit. > > Hmm... mis-memory on my part. Apologies. Michael > Tim Delaney > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > > ___ Python-Dev mailing list [email protected] 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: > That much is obvious. But I haven't seen any explanation as to why > explicitly-documented and explicitly-tested behavior should be treated > as a bug in policy terms, just because people don't like the documented > and tested behavior. It's not "just" that people disliked the behavior. The majority of those that commented agreed that the current behavior is incorrect. Some also observed that the online documentation was underspecified, and indeed allowed for that change. So this is a bug fix, even though the old test case explicitly tested for the presence of the bug, and even though the doc string explicitly documented the old behavior. They were all consistent, but they were consistently wrong. The bug fix may also break existing applications. Hence it cannot go into 2.5.1 but has to wait for 2.6. > So far, the only policy justification I've seen you give was along the > lines of, "I volunteered to do it, so I get to decide". It's more than that. I conducted a poll, and here people were largely in favor of that change. Had they been largely in opposition, I would have rejected the patch. However, *some* action is necessary. The patch was sitting there for a long time already, and it is unfair to the submitter to not act just because you cannot decide. The bug report was even older. > Thus, either way, there needs to be some *other* justification for the > original change. But I said that many times. I changed it because the old behavior (and the old documentation) was buggy, and the (revised version of) the patch fixed that bug. Regards, Martin P.S. If you apply the same effort to all changes that are constantly being made to Python, you will find that you will need to revert many of them. ___ Python-Dev mailing list [email protected] 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, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > This backwards-incompatible change is therefore contrary to policy and > should be reverted, pending a proper transition plan for the change (such > as introduction of an alternative API and deprecation of the existing one.) I think the original behavior is simpler, thus easier to document and understand, but even if we want to change the behavior, the fact is that the new behavior can break some old code. As I mentioned in an earlier email, I don't think this is a corner case -- I bet there is a ton of Python code out there which deals with hidden files and directories. Pat ___ Python-Dev mailing list [email protected] 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: > 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). 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? Regards, Martin ___ Python-Dev mailing list [email protected] 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)
Delaney, Timothy (Tim) schrieb: > A change to the documented behaviour should require a __future__ > import for at least one version. That's even assuming that the change > is desireable (I don't believe so). We have multiple anecdotes of > actual, existing code that *will* break with this change. So far I > haven't seen any actual code posted that is currently broken by the > existing behaviour. Can you please point to them? I'm only aware of a single anecdote (about software that likely will never see Python 2.6). Regards, Martin ___ Python-Dev mailing list [email protected] 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:
> It's not "just" that people disliked the behavior. The majority of
> those
> that commented agreed that the current behavior is incorrect. Some
> also
> observed that the online documentation was underspecified, and indeed
> allowed for that change. So this is a bug fix, even though the old
> test
> case explicitly tested for the presence of the bug, and even though
> the
> doc string explicitly documented the old behavior. They were all
> consistent, but they were consistently wrong.
The patch special-cases one edge case where an "extension" does not indicate
the type of the file, but metadata on a particular platform.
Here's a couple of other edge cases that are not addressed by the patch:
On Mac OS (including Mac OS X) you can have a file without an extension, where
the type is specified in the metadata. However, such a file could also happen
to contain a dot in the file name:
splitext("Version 1.2") -> ("Version 1", "2")
Also, quite often you have multiple extensions:
splitext("file.tar.gz") -> ("file.tar", "gz")
To me, the "extension" there is "tar.gz".
Basically, changing the behaviour of splitext() is simply trying to make it "do
what I mean" (DWIM). But it's never going to DWIM. I think the best we can do
is have a simple, unambiguous rule, with no exceptions - which is what the
existing behaviour does.
Tim Delaney
___
Python-Dev mailing list
[email protected]
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 10:54 PM 3/14/2007 +0100, Martin v. Löwis wrote: >Phillip J. Eby schrieb: > > That much is obvious. But I haven't seen any explanation as to why > > explicitly-documented and explicitly-tested behavior should be treated > > as a bug in policy terms, just because people don't like the documented > > and tested behavior. > >It's not "just" that people disliked the behavior. The majority of those >that commented agreed that the current behavior is incorrect. And yet, that "incorrect" behavior was clearly intended by the author(s) of the code, test, and docstrings. As it happens, Guido wrote that code (16 years ago) and the docstring (9 years ago), in the case of the posixpath module at least. And in an amusing twist, it appears that you yourself checked in the test, 4 years ago! If this behavior was so *obviously* buggy, why didn't you ask Guido or "fix" it then? But wait, it gets better! Five years ago, you also recommended *rejection* of a similar patch: """I also dislike this patch. The current behaviour completely matches the documented behaviour; changing it might break existing applications. If you need a different behaviour, write a different function.""" http://python.org/sf/536120 So, why is it obviously broken now, but not five years ago? > > So far, the only policy justification I've seen you give was along the > > lines of, "I volunteered to do it, so I get to decide". > >It's more than that. I conducted a poll, and here people were largely >in favor of that change. Had they been largely in opposition, I would >have rejected the patch. By this logic, I could conduct a popularity poll for say, "fixing" the distutils by changing its behavior to match that of setuptools, and go ahead with it if the majority agreed with me that the distutils' behavior was clearly incorrect by retroactive comparison -- despite it being documented and tested behavior, and despite objections of backward incompatibility being presented on Python-Dev. So, I don't understand your reasoning here at all. >However, *some* action is necessary. The patch was sitting there for >a long time already, and it is unfair to the submitter to not act just >because you cannot decide. The bug report was even older. So reject it, or propose to add a new API. >P.S. If you apply the same effort to all changes that are constantly >being made to Python, you will find that you will need to revert many >of them. Then I'm amazed that there is so much desire to *increase* the number of changes being made to Python, if we can't even manage to follow our policies *now*. ___ Python-Dev mailing list [email protected] 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)
Hi Martin, On Wed, Mar 14, 2007 at 10:54:41PM +0100, "Martin v. L?wis" wrote: > So this is a bug fix, even though the old test > case explicitly tested for the presence of the bug FWIW, when developing PyPy we found quite a number of tests in CPython that were checking not just obscure implementation details, but things known to be of the kind "don't do that you fool" or "let's check for exactly one of the many things that could reasonably occur here". CPython's test suite should not be regarded as a behavior definition; only the documentation should. I consider this case similarly debatable, and to this debate I will contribute a +1 on keeping Martin's patch. A bientot, Armin ___ Python-Dev mailing list [email protected] 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, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 06:47 PM 3/14/2007 +0100, Martin v. Löwis wrote: > >Phillip J. Eby schrieb: > > > This backwards-incompatible change is therefore contrary to policy and > > > should be reverted, pending a proper transition plan for the change > > > (such as introduction of an alternative API and deprecation of the > > > existing one.) > > > >I'm clearly opposed to this proposal, or else I wouldn't have committed > >the change in the first place. > > That much is obvious. But I haven't seen any explanation as to why > explicitly-documented and explicitly-tested behavior should be treated as a > bug in policy terms, just because people don't like the documented and > tested behavior. > > So far, the only policy justification I've seen you give was along the > lines of, "I volunteered to do it, so I get to decide". I guess it maybe also had something to do with that the bug had been left open on the bug tracker for almost two years and the persons favoring the change had a 2:1 advantage (3:1 if you count the patch contributor). There was plenty of time to voice your dissent. I also think that which ever behavior splitext has, it does not matter much in the grand scheme of things. There are bigger fishes to fry. -- mvh Björn ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] thread safe SMTP module
Gordon Messmer <[EMAIL PROTECTED]> wrote: > Tonight I should have time to pull an old copy of the code out of CVS > and recreate the test script that I used. Once I have, it should be a > matter of feeding a big list of email addresses to the script and > waiting a couple of minutes for the script to lock up. The last time I > looked, the problem was very easy to observe. Try it using the alternative makefile code I posted and see if it makes a difference... ___ Python-Dev mailing list [email protected] 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 14 Mar, 05:08 pm, [EMAIL PROTECTED] wrote: In addition to the prior behavior being explicitly documented in the function docstrings, r54204 shows that it was also *tested* as behaving that way by test_macpath, test_ntpath, and test_posixpath. When combined with the explicit docstrings, this must be considered incontrovertible proof that the previous behavior was either explicitly intended, or at the very least a known, expected, and *accepted* behavior. I (obviously, I think) agree with all of that. This backwards-incompatible change is therefore contrary to policy and should be reverted, pending a proper transition plan for the change (such as introduction of an alternative API and deprecation of the existing one.) I hope that this is true, but *is* this "policy" documented as required somewhere yet? I think it should be reverted regardless, and such a policy instated if one does not exist, but it is my understanding at this point that it is an informal consensus rather than a policy. ___ Python-Dev mailing list [email protected] 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 Thursday 15 March 2007 08:54, Martin v. Löwis wrote: > The bug fix may also break existing applications. Hence it cannot > go into 2.5.1 but has to wait for 2.6. Steering clear of the rest of the discussion, I'd just like to give a hearty "+1" for this not going into 2.5.x in any way shape or form. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backports of standard library modules
> :) is that, when I go to the downloads page for Python 2.3, in > addition to downloading Python, I could download all the > compatible libraries which were included in later versions as a > single installable file. When 2.6 comes out, this "extras" > package would be upgraded to include any new modules in 2.6. > > Not a lot of fun for people who live on the bleeding edge, but > very useful for people who are stuck with an older version for > political or other reasons. If you, or someone else, is willing to do the work to do this, I don't think anyone would mind. There is (as Martin also stated) zero chance that I will do this additional work. It scratches no itches for me, and has the potential to add an enormous amount to my workload of doing a new release. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] 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)
Anthony> On Thursday 15 March 2007 08:54, Martin v. Löwis wrote: >> The bug fix may also break existing applications. Hence it cannot go >> into 2.5.1 but has to wait for 2.6. Anthony> Steering clear of the rest of the discussion, I'd just like to Anthony> give a hearty "+1" for this not going into 2.5.x in any way Anthony> shape or form. Given that the topic seems so contentious, maybe it should wait until 3.x. Skip ___ Python-Dev mailing list [email protected] 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, Anthony Baxter <[EMAIL PROTECTED]> wrote: > Steering clear of the rest of the discussion, I'd just like to give > a hearty "+1" for this not going into 2.5.x in any way shape or > form. Agreed. I'd further vote for keeping this change out until 3.x because it is a behavior change in a corner case predicated on a value judgement. Yes I find the idea of an extension without a filename to be silly. However this change punishes he who checked the corner cases to help he who did not. If this change is primarily geared to help in the case where people want to retrieve the file name without the extension, we should add a function to return this basic name. Who would rather see os.path.dropext(path)? Michael -- Michael Urman http://www.tortall.net/mu/blog ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] pypy's interpreter/highlevel backend features
Hello Python-dev! we have a document on PyPy's interpreter and translation features that might be of interest to you - we target it at language implementors in general: Includes a discussion on our .NET and also the emerging Java backends, as well as our RPython -> Javascript webapp generating experiments, on security relevant taint propagation and transparent proxies ... IOW quite a bag :) We'd be very happy about feedback and opinions/questions (preferably until Monday, 19th March) http://codespeak.net/pypy/extradoc/eu-report/D12.1_H-L-Backends_and_Feature_Prototypes-interim-2007-03-12.pdf best, Holger -- merlinux GmbH Steinbergstr. 4231139 Hildesheim http://merlinux.de tel +49 5121 20800 75 (fax 77) ___ Python-Dev mailing list [email protected] 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)
Michael Urman wrote: > Who would rather see os.path.dropext(path)? I'd like to see such a function, and also maybe replaceext(path, new_ext). I often end up coding things like these myself, since indexing the result of splitext all the time is rather ugly. To round off the set, I suggest path.dropext(path) # returns the base name path.getext(path) # returns the extension path.replaceext(path, newext) # adds or replaces the extension -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pypy's interpreter/highlevel backend features
"holger krekel" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | We'd be very happy about feedback and opinions/questions | (preferably until Monday, 19th March) | | http://codespeak.net/pypy/extradoc/eu-report/D12.1_H-L-Backends_and_Feature_Prototypes-interim-2007-03-12.pdf As of this moment, this is not loading. -- times out ___ Python-Dev mailing list [email protected] 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)
Good, we have gotten around to discussing a little annoyance I've noticed. I think this should behave similar to the way a Unix admin who is familiar with basename(1) would behave: $ basename -s .py /tmp/foo.py foo $ $ basename /tmp/foo.py .py foo $ basename /tmp/foo.py /tmp/f.py foo.py $ basename -a /tmp/foo.py /tmp/f.py foo.py f.py $ basename -a /tmp/foo.py /tmp/f.py .py foo.py f.py .py $ basename -s .py -a /tmp/foo.py /tmp/f.py .py foo f .py $ basename -s .py -a /tmp/foo.py /tmp/f.py foo f $ Changing the function name shouldn't be the solution, imho. Changing the arguments, however, should be. Compare the documentation yourself: - MANPAGE DOCUMENTATION NAME basename, dirname -- return filename or directory portion of pathname SYNOPSIS basename string [suffix] basename [-a] [-s suffix] string [...] dirname string - - PYTHON DOCUMENTATION: Help on function basename in module posixpath: basename(p) Returns the final component of a pathname - Greg Ewing wrote: Michael Urman wrote: Who would rather see os.path.dropext(path)? I'd like to see such a function, and also maybe replaceext(path, new_ext). I often end up coding things like these myself, since indexing the result of splitext all the time is rather ugly. To round off the set, I suggest path.dropext(path) # returns the base name path.getext(path) # returns the extension path.r
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
Phillip J. Eby schrieb:
> And yet, that "incorrect" behavior was clearly intended by the author(s)
> of the code, test, and docstrings.
>
> As it happens, Guido wrote that code (16 years ago) and the docstring (9
> years ago), in the case of the posixpath module at least.
I don't find it that clear that it was the intention, AFAICT, it could
have been an accident also. Guido added the doc strings as a
contribution from Charles G. Waldman; he may just have documented the
implemented behavior.
In r4493, Sjoerd Mullender changed splitext (in an incompatible way)
so that it would split off only the last extension, before, foo.tar.gz
would be split into 'foo', '.tar.gz'. So it's clear that the intention
was always to "split off the extension", whether or not the behavior
on dotfiles was considered I cannot tell.
As for Doc/lib, in r6524 Guido changed it to document the actual
behavior, from
the last component of \var{root} contains no periods,
and \var{ext} is empty or begins with a period.
to
and \var{ext} is empty or begins with a period and contains
at most one period.
So it seems the original (Guido's) intention was that it splits
of all extensions; Sjoerd then changed it to split off only the
last extension.
> And in an amusing twist, it appears that you yourself checked in the
> test, 4 years ago! If this behavior was so *obviously* buggy, why
> didn't you ask Guido or "fix" it then?
If you look at #536661, you'll see that I committed that as a
contribution of Sebastian Keim. The intention here was to rigorously
test the implemented behavior, after a failed attempt of challenging
it.
> But wait, it gets better! Five years ago, you also recommended
> *rejection* of a similar patch:
>
> """I also dislike this patch. The current behaviour completely
> matches the documented behaviour; changing it might break
> existing applications. If you need a different behaviour,
> write a different function."""
>
> http://python.org/sf/536120
>
> So, why is it obviously broken now, but not five years ago?
I apparently took the same position that you now take back then,
whereas I'm now leaning towards (or going beyond) the position
Tim had back then, who wrote "BTW, if it *weren't* for the code
breakage, I'd be in favor of doing this."
I now believe that this should be done *despite* having been
documented and tested (which, as you can see, was documented
and tested only match the implemented behavior). That it keeps
popping up is proof that the old behavior is deemed incorrect
by many people.
>> It's more than that. I conducted a poll, and here people were largely
>> in favor of that change. Had they been largely in opposition, I would
>> have rejected the patch.
>
> By this logic, I could conduct a popularity poll for say, "fixing" the
> distutils by changing its behavior to match that of setuptools, and go
> ahead with it if the majority agreed with me that the distutils'
> behavior was clearly incorrect by retroactive comparison -- despite it
> being documented and tested behavior, and despite objections of backward
> incompatibility being presented on Python-Dev.
And indeed, when you go back to the last discussion on distutils, this
is precisely what I recommend you to do, instead of putting layers
into setuptools to work around what you consider quirks in distutils.
> So reject it, or propose to add a new API.
Neither is a solution. Rejecting it means it will keep popping up
forever. The amount of Python code yet to be written is hopefully larger
than the code already written (paraphrasing Guido), so in the long run,
it should show the right behavior, not the historical one.
Adding a new API has a very high cost: it should ultimately involve
removing the old API, so *all* usage of splitext will eventually break,
not just those cases which happen to break under the current change.
Also, books need to be updated, etc. Furthermore, nobody has proposed
a name for a new API, yet.
>> P.S. If you apply the same effort to all changes that are constantly
>> being made to Python, you will find that you will need to revert many
>> of them.
>
> Then I'm amazed that there is so much desire to *increase* the number of
> changes being made to Python, if we can't even manage to follow our
> policies *now*.
It seems that we disagree on what the policies are. 100% backwards
compatibility is none of them. Feature releases may include incompatible
changes, and this is just one of them (and a minor one, too). What
policy do you think is this change violating?
Regards,
Martin
___
Python-Dev mailing list
[email protected]
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)
[EMAIL PROTECTED] schrieb: > >This backwards-incompatible change is therefore contrary to policy and > >should be reverted, pending a proper transition plan for the change (such > >as introduction of an alternative API and deprecation of the existing > one.) > > I hope that this is true, but *is* this "policy" documented as required > somewhere yet? I think it should be reverted regardless, and such a > policy instated if one does not exist, but it is my understanding at > this point that it is an informal consensus rather than a policy. I'm not quite sure what "it" is, here. If "it" is that there be no incompatible changes in Python: this is not policy, and not even consensus. Instead, policy (as enforced by the release manager), and consensus is that bug fix releases (2.x.y) must not show incompatible behavior. For feature releases (2.x), incompatible behavior is acceptable (at least this is what I thought consensus is, but apparently I'm wrong). Regards, Martin ___ Python-Dev mailing list [email protected] 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 2007-03-15 07:45, Martin v. Löwis wrote:
> Phillip J. Eby schrieb:
>> And yet, that "incorrect" behavior was clearly intended by the author(s)
>> of the code, test, and docstrings.
>>
>> As it happens, Guido wrote that code (16 years ago) and the docstring (9
>> years ago), in the case of the posixpath module at least.
>
> I don't find it that clear that it was the intention, AFAICT, it could
> have been an accident also. Guido added the doc strings as a
> contribution from Charles G. Waldman; he may just have documented the
> implemented behavior.
>
> In r4493, Sjoerd Mullender changed splitext (in an incompatible way)
> so that it would split off only the last extension, before, foo.tar.gz
> would be split into 'foo', '.tar.gz'. So it's clear that the intention
> was always to "split off the extension", whether or not the behavior
> on dotfiles was considered I cannot tell.
>
> As for Doc/lib, in r6524 Guido changed it to document the actual
> behavior, from
>
> the last component of \var{root} contains no periods,
> and \var{ext} is empty or begins with a period.
>
> to
>
> and \var{ext} is empty or begins with a period and contains
> at most one period.
>
> So it seems the original (Guido's) intention was that it splits
> of all extensions; Sjoerd then changed it to split off only the
> last extension.
Whatever the intention was or has been: the term "extension"
itself is not well-defined, so there's no obvious right way
to implement an API that splits off an extension.
E.g. in some cases, .tar.gz is considered an extension, in others,
the .gz part is just a transfer encoding and .tar the extension.
Then you have .tgz which is a bit of both. It also depends on the
platform, e.g. on Windows, only the very last part of a filename
is used as extension by the OS to determine the (MIME) type of
a file.
As always, it's best to just right your own application-specific
code to get defined behavior.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Mar 15 2007)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free !
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
