Re: [Python-Dev] splitext('.cshrc')
On 3/8/07, Tony Nelson [EMAIL PROTECTED] wrote: At 2:16 PM -0500 3/8/07, Phillip J. Eby wrote: The code in question was a type association handler that looked up loader functions based on file extension. This was specifically convenient for recognizing the difference between .htaccess files and other dotfiles that might appear in a web directory tree -- e.g. .htpasswd. The proposed change of splitext() would break that determination, because .htpasswd and .htaccess would both be considered files with empty extensions, and would be handled by the empty extension handler. So, .htaccess and foo.htaccess should be treated the same way? Is that what Apache does? I've never personally used foo.htaccess, but I have had files named, e.g. test1.htaccess, or backup.htaccess. And I don't know, but I assume a foo.htaccess would be an older or test version of a .htaccess file. So, my usecases say, yes, they should be treated the same. 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
Re: [Python-Dev] splitext('.cshrc')
Andrew Bennetts schrieb: Glyph's proposing that rather than risk breaking existing code (and in the worst possible way: silently, giving wrong answers rather than exceptions), we examine what benefits changing splitext would bring, and see if there's a way to get those benefits without that risk. I don't think that's an idea to dismiss out of hand. But I did list what I consider the benefits of the change to be, in http://mail.python.org/pipermail/python-dev/2007-March/071675.html (the message you are responding to). I don't see any other way of achieving these benefits without changing splitext, so I didn't propose any alternatives. I haven't seen any other proposal, either. At the moment you seem to be saying that because you're possibly fixing some currently buggy code, it's ok to possibly break some currently working code. I'm not sure that's a good idea, and I expect it will create headaches for someone trying to be compatible with both 2.5 and 2.6. I personally don't expect severe or massive breakage. It's a small detail. If the existing behaviour was clearly buggy by the existing documentation, rather than undefined, this would be less of a concern. The point about silent failures is an important one too. I see all these objections. I just don't see them outweigh the advantages. If splitext was removed and replaced with, say, a split_ext that behaves as you (and basically everyone, myself included) agrees it should behave, then code won't silently do the wrong thing. It will immediately and visibly fail, in an understandable way. Similarly, if split_ext was added side-by-side with splitext, and splitext changed to emit DeprecationWarnings for a release, there's minimal risk that existing code that works would break. I considered these alternatives, and rejected them. Outright removing splitext would break a lot of code, period. I can't see how this could possibly be better than the currently implemented change. Raising a DeprecationWarning would also break a lot code, although in a less aggressive way. Who is going to see these warnings? The end users, running Python applications and using libraries they have not written. Fixing them will involve a very large cost in the community (spread over many people). Raising a DeprecationWarning should not be taken lightly. OTOH, silently changing the current behavior might break some applications. Again, it is the users who will notice, but for this change, it will be less users, as I expect that breakage will be really uncommon. I wonder if First, do no harm should be an explicit guideline when it comes evaluating incompatible changes, even if they fix other things? If possible, sure. However, I don't see how this is possible here. All your proposed alternatives do more harm than the one implemented. All that said, I don't think I've ever used splitext myself, so I don't care so much about what happens to it. But I do worry about the general approach to backwards compatibility. It's not a general approach. It's a case-by-case decision. Please understand that *any* change is incompatible, in the sense that I can come up with an application that breaks under the change. Really. *ANY CHANGE*. So the only way to get 100% compatibility is to not change anything at all. 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] splitext('.cshrc')
Josiah Carlson schrieb: Because we should refuse the temptation to guess, what about: Rename the posix splitext to X (for some X), and offer a function with identical functionality to the posix variant under win32, also available as X for that platform. Rename the (current) win32 splitext to Y (for some Y) and offer a function with identical functionality to the posix platform as name Y. Offer a new splitext that uses X on posix and Y on win32, but causes a DeprecationWarning with pointers to the two renamed functions that are available on both platforms. See my comment to Andrew. This would cause severe harm: there are many applications of splitext which work just fine and won't see any behavior change; there are those which actually got fixed; and then there are those that break. With the change, you are putting a burden on all three cases, and more so, on the users of the software. In addition, splitext should not be deprecated. It is a fine function, and I really don't see a conceptual need for two versions of it: you will only ever need the current one. For people who want the old platform-specific functionality in previous and subsequent Pythons, offer the ability to disable the DeprecationWarning via a module global; at least until the function is removed in some future Python, at which point path.splitext would cause an AttributeError . That assumes there is a need for the old functionality. I really don't see it (pje claimed he needed it once, but I remain unconvinced, not having seen an actual fragment where the old behavior is helpful). 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] splitext('.cshrc')
Martin v. Löwis wrote:
Phillip J. Eby schrieb:
I consider it correct, or at the least, don't think it should be
changed, as it would make the behavior more difficult to reason about
and introduce yet another thing to worry about when writing
cross-version code.
Now it's becoming difficult: several people in favor, some opposed...
I'll wait a bit longer, but will still likely commit it, unless
opposition gets stronger: If the current behavior is incorrect
(in the sense that it contradicts wide-spread intuition), then
an application worrying about this detail should surely make the
2.6 behavior also appear in 2.5 and earlier.
I'm not sure what people actually use splitext for: I guess there
are two applications:
a) given a list of file names, give me all those belonging to a
hard-coded list of extensions (e.g. .py, .pyc, .c, .h). These
won't break, since they likely won't search for all files
ending in .bash_profile - there is only one per directory,
and if the want it, they use the entire filename.
b) given a list of file names, classify them for display (the
way the Windows explorer works, and similar file managers).
They use MIME databases and the like, and if they are unix-ish,
they probably reject the current splitext implementation already
as incorrect, and have work-arounds. As these files now show
up with no extension, I rather expect that the work-around
won't trigger, and the default behavior will be the correct one.
c) Given a filename, make an appropriately named associated file.
pyo_name = os.path.splitext(name)[0] + '.pyo'
This argues for os.path.splitext('.pythonrc') == ('.pythonrc','')
--
-- Scott David Daniels
[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] splitext('.cshrc')
On 3/7/07, Josiah Carlson [EMAIL PROTECTED] wrote:
Martin v. Löwis [EMAIL PROTECTED] wrote:
Now it's becoming difficult: several people in favor, some opposed...
What about changing the semantics of splitext and creating a new
function (available on all platforms) that does what the Windows version
currently does?
I don't understand only one thing, why do people need new functions?
You can anticipate the change today, and write functions that do
exactly what you need no matter which way (current or proposed) python
implements:
def ensurenew(path):
a,b = os.path.splitext(path)
if a == '': # also possibly check if a contains dots only
return b,a
return a,b
def ensureold(path):
a,b = os.path.splitext(path)
if b == '' and a.startswith('.'): # also possibly check if a
starts with multiple dots
return b,a
return a,b
Best regards,
Alexey.
___
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] splitext('.cshrc')
Scott David Daniels schrieb:
c) Given a filename, make an appropriately named associated file.
pyo_name = os.path.splitext(name)[0] + '.pyo'
This argues for os.path.splitext('.pythonrc') == ('.pythonrc','')
Indeed, somebody found that people apparently do
back_name = splitext(name[0]) + '.bak'
which would severely break if somebody tried to create backups of
dotfiles that way.
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] splitext('.cshrc')
On Thu, Mar 08, 2007 at 06:54:30PM +0100, Martin v. L?wis wrote: back_name = splitext(name[0]) + '.bak' back_name = splitext(name)[0] + '.bak' Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] splitext('.cshrc')
On 3/8/07, Alexey Borzenkov [EMAIL PROTECTED] wrote: On 3/7/07, Josiah Carlson [EMAIL PROTECTED] wrote: Martin v. Löwis [EMAIL PROTECTED] wrote: Now it's becoming difficult: several people in favor, some opposed... What about changing the semantics of splitext and creating a new function (available on all platforms) that does what the Windows version currently does? I don't understand only one thing, why do people need new functions? You can anticipate the change today, and write functions that do exactly what you need no matter which way (current or proposed) python implements: [...snip...] On second thought I completely forgot about path parts. Best regards, Alexey. ___ 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] splitext('.cshrc')
Alexey Borzenkov schrieb: I don't understand only one thing, why do people need new functions? You can anticipate the change today, and write functions that do exactly what you need no matter which way (current or proposed) python implements: Indeed, that's also true. When people actually care, they can easily achieve compatibility across 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] splitext('.cshrc')
At 11:53 AM 3/8/2007 +0100, Martin v. Löwis wrote: That assumes there is a need for the old functionality. I really don't see it (pje claimed he needed it once, but I remain unconvinced, not having seen an actual fragment where the old behavior is helpful). The code in question was a type association handler that looked up loader functions based on file extension. This was specifically convenient for recognizing the difference between .htaccess files and other dotfiles that might appear in a web directory tree -- e.g. .htpasswd. The proposed change of splitext() would break that determination, because .htpasswd and .htaccess would both be considered files with empty extensions, and would be handled by the empty extension handler. ___ 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] splitext('.cshrc')
On 8 Mar, 06:02 pm, [EMAIL PROTECTED] wrote: On Thu, Mar 08, 2007 at 06:54:30PM +0100, Martin v. L?wis wrote: back_name = splitext(name[0]) + '.bak' back_name = splitext(name)[0] + '.bak' This is really totally secondary to the point I actually care about, but seeing this antipattern bandied about as a reason to make the change is starting to bother me. There's no way to fix this idiom. Forget the corner case; what if you have a foobar.py and a foobar.txt in the same directory? This is not at all uncommon, and your backup function here will clobber those files in any case. Furthermore, although the module documentation is vague, the docstring for splitext specifically says either part may be empty and extension is everything from the last dot to the end. Again, this is a case of needing a function designed to perform a specific task, and instead relying on half-broken idioms which involve other functions. make_backup_filename(x) might *use* splitext, but it is not what splitext is *for*. A correct implementation which did use splitext would look like this: def make_backup_filename(filename): base, extension = splitext(filename) return base + '.bak' + extension although personally I would probably prefer this: def make_backup_filename(filename): return filename + '.bak' If the behavior of the old code is going to be buggy in any case, it might as well be buggy and consistent. Consider a program that periodically makes and then cleans up backup files, and uses the correct splitext-using function above. Perhaps .cshrc.bak makes more sense than .bak.cshrc to some people, but that means that on a system where python is upgraded, .bak.cshrc will be left around forever. Even on a program whose functionality is improved by this change, the incompatibility between versions might create problems. ___ 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] splitext('.cshrc')
I'm a long-term lurker and Python coder, and although I've never really
contributed much to the list, I do make a point to keep up on it so I'm
prepared at least when changes come through. This thread's gone on forever,
so I thought I'd offer my opinion :) Mwha.
Ahem.
First of all, I think the current behavior is clearly broken; .cshrc is a
file without an extension and marked as 'hidden' according to the
conventions of the operating system. I totally think it should be fixed; but
with others I'm worried about backwards compatability and more importantly
the possibility of silent failures. Although none of my company's code will
be hit (as I've always done fn.split('.')[-1] just... because it strikes me
as more natural -- then again I'm in a situation where I don't have
user-supplied filenames.), the thought that it's OK to make such changes
even in a 'major' release is a bit disconcerting.
Its not that I don't think there can be backwards-incompatible changes, but
if at all possible they should be done in such a way that the change causes
a hard failure or at least a clear warning in the offending code. I read
that someone (... No idea who) suggested an optional keyword argument, and
someone else objected to that on the grounds that it would let a second
argument be passed in to alter the signature, and it would no longer throw
an exception as people would be expecting.
Well, I think it was a great idea-- whoever said it :) And gives the
oppertunity to use the transitory period before 3.0 to loudly warn people
about this fix. I don't expect a lot of people will be hit by it, but isn't
that why this whole 2.6-to-3.0 thing is going on?
Why wouldn't this work? I could submit a patch with a doc modification and
tests even :P But it could begin the process of 'fixing' it, and warn people
of the upcoming breakage, and although it slightly complicates the
function... I think it only does it slightly :)
(BTW, it raises a TypeError if the allow_dotfile isn't specified
specifically, to address someone's objection that it would alter the
signature)
-
import warnings
def splitext(p, **kwargs):
allow_dotfile = kwargs.pop('allow_dotfile', False)
if kwargs:
raise TypeError, splitext() takes at most 2 arguments (%s given) %
(1 + len(kwargs))
i = p.rfind('.')
if i=max(p.rfind('/'), p.rfind('\\')):
fn, ext = p, ''
else:
fn, ext = p[:i], p[i:]
if allow_dotfile is False:
if p.find('.') == 0:
warnings.warn(FutureWarning('In Python 3.0, allow_dotfile
default will become True.'))
return fn, ext
else:
if p.find('.') == 0:
return ext, ''
else:
return fn, ext
-
___
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] splitext('.cshrc')
At 2:16 PM -0500 3/8/07, Phillip J. Eby wrote: At 11:53 AM 3/8/2007 +0100, Martin v. Löwis wrote: That assumes there is a need for the old functionality. I really don't see it (pje claimed he needed it once, but I remain unconvinced, not having seen an actual fragment where the old behavior is helpful). The code in question was a type association handler that looked up loader functions based on file extension. This was specifically convenient for recognizing the difference between .htaccess files and other dotfiles that might appear in a web directory tree -- e.g. .htpasswd. The proposed change of splitext() would break that determination, because .htpasswd and .htaccess would both be considered files with empty extensions, and would be handled by the empty extension handler. So, .htaccess and foo.htaccess should be treated the same way? Is that what Apache does? -- TonyN.:' mailto:[EMAIL PROTECTED] ' http://www.georgeanelson.com/ ___ 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] splitext('.cshrc')
[EMAIL PROTECTED] schrieb: More to the point, we know the cost, what's the benefit? Is there any sort of bug that it is likely to prevent in *new* code? Yes. People are more likely to classify the file as no extension, which more likely meets the user's expectation. Also, it won't happen that splitext gives an empty file name, which otherwise may cause crashes. It clearly isn't going to help any old code. That's not at all clear. Instead, old code will suddenly work correctly (in the user's point of view), where it before gave nonsensical results (which users have likely ignored). For example, from the standard library: py import pydoc py pydoc.importfile(/Users/loewis/.pythonrc) module '' from '/Users/loewis/.pythonrc' This is non-sensical: the module isn't an empty string. Instead, it should be '.pythonrc' - just as it would be 'pythonrc' if the file name was 'pythonrc'. So old code in the standard library will be improved. It seems there are people who see it both ways, and I haven't seen anything compelling to indicate that either behavior is particularly less surprising in the edge case. Maybe you aren't grounded so much in Unix history. It really feels wrong that a dotfile is considered as having an extension. In cases like this, historical context should be considered, even for a major overhaul like 3.0. Of course, if the newly proposed semantics provided a solution to a real problem or common error, compatibility might be determined to be a less important issue. All of these apply here. The use-cases being discussed here would be better served by having new APIs that do particular things and don't change existing semantics, though. For example, a guess_mime_type(path) function which could examine a path and figure out its mime type based on its extension (among other things). I disagree. The current behavior is incorrect (and always has been); the new behavior is clearly correct. 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] splitext('.cshrc')
Terry Jones schrieb: I do think the behavior can be improved, and that it should be fixed, but at a place where other incompatible changes will also be being made, Indeed, 2.6 is such a place. Any feature release can contain incompatible behavior, and any feature release did contain incompatible behavior. Just look at the porting to sections of past whatsnew files. 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] splitext('.cshrc')
Martin v. Löwis wrote: I never considered it an extension. Ask 10 people around you to see what a leading dot on Unix in a file name means, and I would be suprised if more than one answered it separates the file name from the extension. Most of them likely include hidden file in their answer, and the rest (of those who know anything about it) will say dotfiles, not displayed by ls, and not included in globbing. 10 Unix programmers, perhaps. Windows users may disagree; after all, the Windows Explorer considers both foo.bar and .bar to be BAR files, and considers .py to be an unnamed Python file. /F ___ 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] splitext('.cshrc') (and encouraging developers)
Martin v. Löwis wrote: Terry Jones schrieb: I do think the behavior can be improved, and that it should be fixed, but at a place where other incompatible changes will also be being made, Indeed, 2.6 is such a place. Any feature release can contain incompatible behavior, and any feature release did contain incompatible behavior. Just look at the porting to sections of past whatsnew files. Now that Martin has made the changes and rejected the original patch I remember that it was written by me. This raises a point which is related to the 'encouraging developers' thread. I created this patch as part of a Python bug day over a year ago. The bug day was trumpeted as being a good place for 'newbies' who wanted to contribute to Python could start, and implied that some kind of mentoring would be in place. I enthusiastically turned up on IRC and asked how to join in. I was told (more or less) to 'pick a bug and fix it'. That one seemed to be the only one on the list I could tackle alone (and I still managed to screw it up it seems!). I submitted the patch to sourceforge, posted to IRC that I had done this - and then kind of hung around a while waiting to see what would happen. There was no response and after a while of waiting and nothing much else happening either I returned to working on my own projects... The bug days do seem like an opportunity to involve new developers - but some kind of active engagement would seem appropriate... All the best, Michael Foord 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/fuzzyman%40voidspace.org.uk ___ 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] splitext('.cshrc')
Martin v. Löwis [EMAIL PROTECTED] wrote: Phillip J. Eby schrieb: I consider it correct, or at the least, don't think it should be changed, as it would make the behavior more difficult to reason about and introduce yet another thing to worry about when writing cross-version code. Now it's becoming difficult: several people in favor, some opposed... What about changing the semantics of splitext and creating a new function (available on all platforms) that does what the Windows version currently does? For people who want the one semantic on all platforms, they can pick their semantic explicitly. Alternatively, offer a flag argument in splitext to differentiate between the two cases. - Josiah ___ 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] splitext('.cshrc')
Martin v. Löwis [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | [EMAIL PROTECTED] schrieb: | Maybe you aren't grounded so much in Unix history. It really feels | wrong that a dotfile is considered as having an extension. I have not been on *nix for nearly 20 years and I agree that the current behavior is a bug. If I were to prepare a file list like name .ext I would be annoyed is .cshrc was stuck in the ext column instead of the name column. tjr ___ 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] splitext('.cshrc')
Josiah Carlson schrieb: Now it's becoming difficult: several people in favor, some opposed... What about changing the semantics of splitext and creating a new function (available on all platforms) that does what the Windows version currently does? For people who want the one semantic on all platforms, they can pick their semantic explicitly. Most people object because of the potential breakage; this change wouldn't remove the breakage (people asking for the old, compatible, behavior still need to change their code). Alternatively, offer a flag argument in splitext to differentiate between the two cases. This isn't compatible, either, as older versions will raise an exception because of the extra argument. 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] splitext('.cshrc')
Hi Martin, Martin v. Löwis wrote: [EMAIL PROTECTED] schrieb: [...] The use-cases being discussed here would be better served by having new APIs that do particular things and don't change existing semantics, though. For example, a guess_mime_type(path) function which could examine a path and figure out its mime type based on its extension (among other things). I disagree. The current behavior is incorrect (and always has been); the new behavior is clearly correct. Glyph's proposing that rather than risk breaking existing code (and in the worst possible way: silently, giving wrong answers rather than exceptions), we examine what benefits changing splitext would bring, and see if there's a way to get those benefits without that risk. I don't think that's an idea to dismiss out of hand. You silently omitted this part of glyph's objection: [EMAIL PROTECTED] wrote: [...] Incompatible changes may be *acceptable* for feature releases, but that doesn't mean they are desirable. The cost of incompatibility should be considered for every change. This cost is particularly bad when the incompatibility is of the silent breakage variety - the change being discussed here would not be the sort of thing that one could, say, produce a warning about or gently deprecate; anything relying on the old behavior would suddenly be incorrect, and any software wishing to straddle the 2.5-2.6 boundary would be better off just implementing their own splitext() than relying on the stdlib. At the moment you seem to be saying that because you're possibly fixing some currently buggy code, it's ok to possibly break some currently working code. I'm not sure that's a good idea, and I expect it will create headaches for someone trying to be compatible with both 2.5 and 2.6. If the existing behaviour was clearly buggy by the existing documentation, rather than undefined, this would be less of a concern. The point about silent failures is an important one too. This will cause some code that was working correctly to give wrong answers, rather than an exception or any indication that this previously correct use is now incorrect and causing bugs. If splitext was removed and replaced with, say, a split_ext that behaves as you (and basically everyone, myself included) agrees it should behave, then code won't silently do the wrong thing. It will immediately and visibly fail, in an understandable way. Similarly, if split_ext was added side-by-side with splitext, and splitext changed to emit DeprecationWarnings for a release, there's minimal risk that existing code that works would break. See also the comment at the bottom of http://sourcefrog.net/weblog/software/aesthetics/interface-levels.html about perverse interface design. I wonder if First, do no harm should be an explicit guideline when it comes evaluating incompatible changes, even if they fix other things? There seems to be the problem that all existing users of splitext that may encounter '.foo' will need to audit their code to see if they are relying on previously undefined behaviour that will change. I think it would be much more helpful for python to somehow help users discover this fact, than simply define the previously undefined behaviour to be different to what they might have been relying on. All that said, I don't think I've ever used splitext myself, so I don't care so much about what happens to it. But I do worry about the general approach to backwards compatibility. -Andrew. ___ 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] splitext('.cshrc')
Andrew Bennetts [EMAIL PROTECTED] wrote: Glyph's proposing that rather than risk breaking existing code (and in the worst possible way: silently, giving wrong answers rather than exceptions), we examine what benefits changing splitext would bring, and see if there's a way to get those benefits without that risk. I don't think that's an idea to dismiss out of hand. Because we should refuse the temptation to guess, what about: Rename the posix splitext to X (for some X), and offer a function with identical functionality to the posix variant under win32, also available as X for that platform. Rename the (current) win32 splitext to Y (for some Y) and offer a function with identical functionality to the posix platform as name Y. Offer a new splitext that uses X on posix and Y on win32, but causes a DeprecationWarning with pointers to the two renamed functions that are available on both platforms. For people who want the old platform-specific functionality in previous and subsequent Pythons, offer the ability to disable the DeprecationWarning via a module global; at least until the function is removed in some future Python, at which point path.splitext would cause an AttributeError . - Josiah ___ 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] splitext('.cshrc')
Josiah Carlson wrote:
[...]
Offer a new splitext that uses X on posix and Y on win32, but causes a
DeprecationWarning with pointers to the two renamed functions that are
available on both platforms.
For people who want the old platform-specific functionality in previous
and subsequent Pythons, offer the ability to disable the
DeprecationWarning via a module global; at least until the function is
removed in some future Python, at which point path.splitext would cause
an AttributeError .
It's not about cross-platform behaviour. It's already the same:
import posixpath, ntpath
ntpath.splitext('.cshrc')
('', '.cshrc')
posixpath.splitext('.cshrc')
('', '.cshrc')
And as I understand it, the current proposal would change this behaviour the
same way on win32 and POSIX, although I may not have kept up with that part of
the discussion enough. Is there a genuine desire for this to behave differently
on different platforms?
I think what I'd probably like to see is the existing undefined (but
well-understood and predictable) behaviour to be declared defined, and a warning
put in the documentation that it probably doesn't do what you expect for this
case. And then for those that want the new behaviour, provide a new function
(and prominently advertise it in the relevant part of the documentation). Yes
it sucks having two similar functions, which will inevitably have similar names,
but that's the price you pay for getting the interface wrong the first time
around.
-Andrew.
___
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] splitext('.cshrc')
Andrew Bennetts [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
[...]
Offer a new splitext that uses X on posix and Y on win32, but causes a
DeprecationWarning with pointers to the two renamed functions that are
available on both platforms.
For people who want the old platform-specific functionality in previous
and subsequent Pythons, offer the ability to disable the
DeprecationWarning via a module global; at least until the function is
removed in some future Python, at which point path.splitext would cause
an AttributeError .
It's not about cross-platform behaviour. It's already the same:
import posixpath, ntpath
ntpath.splitext('.cshrc')
('', '.cshrc')
posixpath.splitext('.cshrc')
('', '.cshrc')
And as I understand it, the current proposal would change this behaviour the
same way on win32 and POSIX, although I may not have kept up with that part of
the discussion enough. Is there a genuine desire for this to behave
differently
on different platforms?
Ahh, I thought that it was different on different platforms. Nevermind
then. Add a new function and be done with it.
- Josiah
___
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] splitext('.cshrc')
On 3/6/07, Martin v. Löwis [EMAIL PROTECTED] wrote: #1115886 complains that in the file name '.cshrc', the entire file name is treated as an extension, with no root. #1462106 contains a patch for that, changing the behavior so that there will always be a root file name (and no extension if the file is just a dotfile). Should this be changed? Opinions? +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] splitext('.cshrc')
On Tue, Mar 06, 2007 at 01:36:03PM +0100, Martin v. L?wis wrote: #1115886 complains that in the file name '.cshrc', the entire file name is treated as an extension, with no root. #1462106 contains a patch for that, changing the behavior so that there will always be a root file name (and no extension if the file is just a dotfile). Should this be changed? Opinions? Yes. In .pythonrc.py .pythonrc is the root, and .py is the extension. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] splitext('.cshrc')
Martin v. Löwis schrieb: #1115886 complains that in the file name '.cshrc', the entire file name is treated as an extension, with no root. #1462106 contains a patch for that, changing the behavior so that there will always be a root file name (and no extension if the file is just a dotfile). Should this be changed? Opinions? Since dotfiles can have extensions as well (e.g. ~/.fonts.conf), I'd say that the current behavior is wrong. Question is, is it worth possibly breaking compatibility... Georg ___ 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] splitext('.cshrc')
Am Dienstag, 06. März 2007 13:36 schrieb Martin v. Löwis: #1115886 complains that in the file name '.cshrc', the entire file name is treated as an extension, with no root. #1462106 contains a patch for that, changing the behavior so that there will always be a root file name (and no extension if the file is just a dotfile). Should this be changed? Opinions? +1 The current behavior is clearly a bug, since a leading dot does not start an extension, but marks a file as hidden. The latter is on UNIX, and while this is different on Windows, I cannot imagine that anyone would a) have dotfiles under that OS, or even then b) rely on the current behavior that their full filename counts as extension. Greetings, Hans ___ 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] splitext('.cshrc')
On Tue, Mar 06, 2007 at 02:44:52PM +0100, Hans Meine wrote: a leading dot does not start an extension, but marks a file as hidden. The latter is on UNIX, and while On Unix - I mean in the OS itself - there are no such things as roots, extensions and hidden files. All these are only conventions in the user programs. The current behaviour is not a bug in a strict sense, but it is inconvenient and hence should be changed. this is different on Windows, I cannot imagine that anyone would a) have dotfiles under that OS I have. (-: I often copy files from an ext3 partition to a FAT partition on my dual-booting desktop. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] splitext('.cshrc')
Oleg Broytmann wrote: [snip..] this is different on Windows, I cannot imagine that anyone would a) have dotfiles under that OS It is very common for cross platform programs to create configuration files which are dotfiles, whichever OS they are running on. Michael Foord ___ 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] splitext('.cshrc')
Oleg Broytmann schrieb: Should this be changed? Opinions? Yes. In .pythonrc.py .pythonrc is the root, and .py is the extension. Ah, it would do that already: with multiple dots, the last one always provides the extension. However, for .pythonrc, it would conclude that .pythonrc is the extension. 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] splitext('.cshrc')
On Tue, Mar 06, 2007 at 04:00:01PM +0100, Martin v. L?wis wrote: Yes. In .pythonrc.py .pythonrc is the root, and .py is the extension. Ah, it would do that already: with multiple dots, the last one always provides the extension. Ah, sorry. I messed it with .split(). Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] splitext('.cshrc')
Oleg Broytmann schrieb:
On Tue, Mar 06, 2007 at 04:00:01PM +0100, Martin v. L?wis wrote:
Yes. In .pythonrc.py .pythonrc is the root, and .py is the extension.
Ah, it would do that already: with multiple dots, the last one always
provides the extension.
Ah, sorry. I messed it with .split().
Ok - now I'm confused: do you consider this behavior
(splitext('.pythonrc') == ('', '.pythonrc')) correct
or not?
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] splitext('.cshrc')
On Tue, Mar 06, 2007 at 04:07:16PM +0100, Martin v. L?wis wrote:
Oleg Broytmann schrieb:
On Tue, Mar 06, 2007 at 04:00:01PM +0100, Martin v. L?wis wrote:
Yes. In .pythonrc.py .pythonrc is the root, and .py is the extension.
Ah, it would do that already: with multiple dots, the last one always
provides the extension.
Ah, sorry. I messed it with .split().
Ok - now I'm confused: do you consider this behavior
(splitext('.pythonrc') == ('', '.pythonrc')) correct
or not?
I messed this in the sense that I have ran .split('.pythonrc.py'), got
('', '.pythonrc.py') and thought there is a problem. .split() works fine.
Even .splitext() works fine with multiple dots:
os.path.splitext(/bin/.pythonrc.py)
('/bin/.pythonrc', '.py')
but
os.path.splitext(.pythonrc)
('', '.pythonrc')
and I think it should be
('.pythonrc', '')
Oleg.
--
Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
Programmers don't die, they just GOSUB without RETURN.
___
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] splitext('.cshrc')
Oleg Broytmann schrieb:
os.path.splitext(.pythonrc)
('', '.pythonrc')
and I think it should be
('.pythonrc', '')
Thanks, so it sounds like the patch should be accepted.
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] splitext('.cshrc')
At 04:07 PM 3/6/2007 +0100, Martin v. Löwis wrote:
Oleg Broytmann schrieb:
On Tue, Mar 06, 2007 at 04:00:01PM +0100, Martin v. L?wis wrote:
Yes. In .pythonrc.py .pythonrc is the root, and .py is the extension.
Ah, it would do that already: with multiple dots, the last one always
provides the extension.
Ah, sorry. I messed it with .split().
Ok - now I'm confused: do you consider this behavior
(splitext('.pythonrc') == ('', '.pythonrc')) correct
or not?
I consider it correct, or at the least, don't think it should be changed,
as it would make the behavior more difficult to reason about and introduce
yet another thing to worry about when writing cross-version code.
___
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] splitext('.cshrc')
On Tue, Mar 06, 2007, Phillip J. Eby wrote:
At 04:07 PM 3/6/2007 +0100, Martin v. L?wis wrote:
Ok - now I'm confused: do you consider this behavior
(splitext('.pythonrc') == ('', '.pythonrc')) correct
or not?
I consider it correct, or at the least, don't think it should be changed,
as it would make the behavior more difficult to reason about and introduce
yet another thing to worry about when writing cross-version code.
That's my primary concern, as well. I'm -0 WRT 2.x; +1 WRT 3.x.
--
Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/
I disrespectfully agree. --SJM
___
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] splitext('.cshrc')
On Tue, 6 Mar 2007, Hans Meine wrote: Am Dienstag, 06. M?rz 2007 13:36 schrieb Martin v. L?wis: #1115886 complains that in the file name '.cshrc', the entire file name is treated as an extension, with no root. The current behavior is clearly a bug, since a leading dot does not start an extension, but marks a file as hidden. It's not at all clear that current behaviour should be considered a bug . e.g, I think it's reasonable to expect that splitext( a+. + b) == (a, .b ) for any a,b which have no dots in them... The patch will break this assumption for empty a So, I'd classify dot files as a border case (either behaviour could be viewed as wrong/correct).. In which case backward compatibility should be the primary consideration IMHO Ilya Greetings, Hans ___ 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/ilya%40bluefir.net ___ 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] splitext('.cshrc')
On Tue, Mar 06, 2007 at 08:49:00AM -0800, Ilya Sandler wrote: I think it's reasonable to expect that splitext( a+. + b) == (a, .b ) for any a,b which have no dots in them... Except for an empty 'a', in what case 'b' is the name, not the extension. Well, 'a' cannot be empty because it's the name, but 'b' can be empty. For .pythonrc.py .pythonrc is the name and .py is the extension. For .pythonrc .pythonrc is the name and there is no extension. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] splitext('.cshrc')
On 3/6/07, Hans Meine [EMAIL PROTECTED] wrote: The current behavior is clearly a bug, since a leading dot does not start an extension, but marks a file as hidden. The latter is on UNIX, and while this is different on Windows, I cannot imagine that anyone would a) have dotfiles under that OS, or even then b) rely on the current behavior that their full filename counts as extension. FWIW, all of the standard Windows functions from the Microsoft CRT (_splitpath) to the Shell API (PathRemoveExtension) to the CLR (System.IO.Path.*) believe that .cshrc is the extension of the filename .cshrc. I'm not sure if that's an argument for or against the patch, though. -- Tim Lesher [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] splitext('.cshrc')
At 07:24 PM 3/6/2007 +0100, Martin v. Löwis wrote: given a list of file names, classify them for display (the way the Windows explorer works, and similar file managers). They use MIME databases and the like, and if they are unix-ish, they probably reject the current splitext implementation already as incorrect, and have work-arounds. I know I've written code like this that *depends* on the current behavior. It's *useful* to classify e.g. .svn directories or .*rc files by their extension, so I'm honestly baffled by the idea of wanting to treat such files as *not* having an extension (as opposed to a possibly-unrecognized one). ___ 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] splitext('.cshrc')
On 3/6/07, Phillip J. Eby [EMAIL PROTECTED] wrote: At 07:24 PM 3/6/2007 +0100, Martin v. Löwis wrote: given a list of file names, classify them for display (the way the Windows explorer works, and similar file managers). They use MIME databases and the like, and if they are unix-ish, they probably reject the current splitext implementation already as incorrect, and have work-arounds. I know I've written code like this that *depends* on the current behavior. It's *useful* to classify e.g. .svn directories or .*rc files by their extension, so I'm honestly baffled by the idea of wanting to treat such files as *not* having an extension (as opposed to a possibly-unrecognized one). My argument would be that the file is not 'unnamed', with an extension of 'cshrc'. The file is actually called 'cshrc', and the '.' is metadata that is attached to tell the shell to hide the file. Assuming that we want ot be ignorant of shell semantics (and I think we do), then the file is called '.cshrc', and it has no extension. The notion of an unnamed file with an extension I think would be very odd to most people. +1 to changing the behaviour to return .cshrc as the filename, with no extension. -- Nick ___ 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] splitext('.cshrc')
At 02:08 PM 3/6/2007 -0500, Nicholas Bastin wrote: The notion of an unnamed file with an extension I think would be very odd to most people. Clearly, we all think that most people are like ourselves. :) I think that for someone with a Windows/DOS background, that's *exactly* what .cshrc looks like! (IIRC in DOS, *every* file has an extension, such that 'foo' and 'foo.' refer to the same file.) ___ 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] splitext('.cshrc')
On 3/6/07, Phillip J. Eby [EMAIL PROTECTED] wrote:
It's *useful* to classify e.g. .svn directories or .*rc files by their
extension
I respectfully disagree. When trying to find directories named .svn or
files named .bashrc, I do
filename in ('.svn', '.bashrc')
because I don't expect filenames like foo.svn or bar.bashrc -- have
you ever seen one? These are not extensions for me.
___
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] splitext('.cshrc')
Phillip J. Eby [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I consider it correct, or at the least, don't think it should be changed, as it would make the behavior more difficult to reason about and introduce yet another thing to worry about when writing cross-version code. Windows did not allow .xxx as a filename in my attempts, so this case seems irrelevant there. tjr ___ 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] splitext('.cshrc')
Terry Reedy wrote: Phillip J. Eby [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I consider it correct, or at the least, don't think it should be changed, as it would make the behavior more difficult to reason about and introduce yet another thing to worry about when writing cross-version code. Windows did not allow .xxx as a filename in my attempts, so this case seems irrelevant there. Windows is a bit funny there. You can't create a .xxx filename in Explorer, but you can from Console/the API: code import os f = open (.xxx, w) f.close () os.path.isfile (.xxx) # True /code Not that this helps anything, really, but just to make the point :) TJG ___ 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] splitext('.cshrc')
Phillip J. Eby schrieb: I know I've written code like this that *depends* on the current behavior. It's *useful* to classify e.g. .svn directories or .*rc files by their extension, so I'm honestly baffled by the idea of wanting to treat such files as *not* having an extension (as opposed to a possibly-unrecognized one). I never considered it an extension. Ask 10 people around you to see what a leading dot on Unix in a file name means, and I would be suprised if more than one answered it separates the file name from the extension. Most of them likely include hidden file in their answer, and the rest (of those who know anything about it) will say dotfiles, not displayed by ls, and not included in globbing. It really is a *different* dot from the one that separates the file name from its extension. I also fail to see why it is useful to invoke splitext on a file name to find out whether it is .svn - I would rather check the file name itself. It's unfortunate, of course, that people apparently relied on this behavior (is the code you are referring to publicly available? If so, where?) 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] splitext('.cshrc')
At 02:55 PM 3/6/2007 -0500, Terry Reedy wrote: Phillip J. Eby [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I consider it correct, or at the least, don't think it should be changed, as it would make the behavior more difficult to reason about and introduce yet another thing to worry about when writing cross-version code. Windows did not allow .xxx as a filename in my attempts, so this case seems irrelevant there. Huh? .xyz files work fine on Windows. ___ 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] splitext('.cshrc')
Martin v. Löwis wrote:
Ok - now I'm confused: do you consider this behavior
(splitext('.pythonrc') == ('', '.pythonrc')) correct
or not?
+1 on the behavior. However, the patch is special-casing a leading dot;
it would still fail on splitext(..). If we're gonna fix the bug, I'd
rather we fixed it dead.
What follows is a cross-platform splitext(). It passes all the tests I
threw at it, also attached. If there is interest, I would be happy to
submit it as an alternate patch. If runtime speed is paramount, I could
lose the portability, and instead port my patch into all three *path.py
files natively (dropping os.sep and os.altsep).
Hope this helps,
/larry/
--
import os
def splitext(f):
sepIndex = f.rfind(os.sep)
if os.altsep:
altsepIndex = f.rfind(os.altsep)
sepIndex = max(sepIndex, altsepIndex)
dotIndex = f.rfind(.)
if dotIndex sepIndex:
# skip all leading dots
filenameIndex = sepIndex + 1
while filenameIndex dotIndex:
if f[filenameIndex] != '.':
return f[:dotIndex], f[dotIndex:]
filenameIndex += 1
return f, ''
def splitextTest(path, filename, ext):
assert splitext(path) == (filename, ext)
assert splitext(os.sep + path) == (os.sep + filename, ext)
assert splitext(abc + os.sep + path) == (abc + os.sep + filename, ext)
assert splitext(abc.def + os.sep + path) == (abc.def + os.sep +
filename, ext)
if os.altsep:
assert splitext(os.altsep + path) == (os.altsep + filename, ext)
assert splitext(abc + os.altsep + path) == (abc + os.altsep +
filename, ext)
assert splitext(abc.def + os.altsep + path) == (abc.def +
os.altsep + filename, ext)
splitextTest(foo.bar, foo, .bar)
splitextTest(foo.boo.bar, foo.boo, .bar)
splitextTest(foo.boo.biff.bar, foo.boo.biff, .bar)
splitextTest(.csh.rc, .csh, .rc)
splitextTest(nodots, nodots, )
splitextTest(.cshrc, .cshrc, )
splitextTest(...manydots, ...manydots, )
splitextTest(...manydots.ext, ...manydots, .ext)
splitextTest(., ., )
splitextTest(.., .., )
splitextTest(, , )
//
___
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] splitext('.cshrc')
Larry Hastings schrieb: Hope this helps, Indeed it does! After all this discussion, a documentation clarification is certainly in order, but I can work that out myself. Thanks, 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] splitext('.cshrc')
At 10:01 PM 3/6/2007 +0100, Martin v. Löwis wrote: It's unfortunate, of course, that people apparently relied on this behavior I was going to say it's the *documented* behavior, but I see that the documentation is actually such that it could be interpreted either way. However, since it's not documented more specifically, it seems perfectly reasonable to rely on the implementation's behavior to resolve the ambiguity. (is the code you are referring to publicly available? No, and I don't know if it's still being used, although it probably is. But it might also still be running on Python 2.2, and I'm not sure if any of its actual uses are actually affected by such dotted files, or whether the code will ever be upgraded to more recent Python versions. I haven't worked at the company in question for a few years now. ___ 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] splitext('.cshrc')
Phillip J. Eby schrieb: At 10:01 PM 3/6/2007 +0100, Martin v. Löwis wrote: It's unfortunate, of course, that people apparently relied on this behavior I was going to say it's the *documented* behavior, but I see that the documentation is actually such that it could be interpreted either way. However, since it's not documented more specifically, it seems perfectly reasonable to rely on the implementation's behavior to resolve the ambiguity. Sure, it is an incompatible change, no doubt. However, incompatible changes are ok for feature releases (not so fo bugfix releases). So this being an incompatible change alone is not a reason to reject the patch. Significant breakage in many applications might be, but I don't expect that for this change (which is really tiny). 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] splitext('.cshrc')
Phillip J. Eby [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | Windows did not allow .xxx as a filename in my attempts, so this case seems | irrelevant there. | | Huh? .xyz files work fine on Windows. Tim G. explained that Explorer, which I tried, is for whatever reason stricter that other interfaces. tjr ___ 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] splitext('.cshrc')
I think there are various good arguments that the current behavior of splitext isn't optimal. But. these don't feel strong enough to me to break existing code or to force people who happen to be in the know to go hunt down and review old code etc. I don't see the point in doing that, just to fix something that everyone seems to agree is quite marginal. There are about 500 hits for splitext\(lang:python at code.google.com. Many of these blindly use something like newname = splitext(filename)[0] + '.bak' You could convincingly argue that these would be fixed if the current behavior were changed. In fact, from looking at 30 examples or so, I suspect much more code would be fixed than broken. But changing the behavior of programs doesn't seem like a good idea - even if you can claim to have fixed them. (This reminds me of SUN adopting a newer malloc in the mid-90s - it had better internal fragmentation behavior for many requests, and thereby broke a bunch of working (but in fact buggy) code that was inadvertently relying on the slop in the older malloc). I do think the behavior can be improved, and that it should be fixed, but at a place where other incompatible changes will also be being made, and where people are already going to have to do serious code review. To me that argues for fixing it in Py3k. Arguing that it's just a minor change, and so therefore it can go straight in, seems to also lend support to the suggestion that it can wait. Terry ___ 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] splitext('.cshrc')
Tim Lesher wrote: FWIW, all of the standard Windows functions from the Microsoft CRT (_splitpath) to the Shell API (PathRemoveExtension) to the CLR (System.IO.Path.*) believe that .cshrc is the extension of the filename .cshrc. I'm not sure if that's an argument for or against the patch, though. It *might* be an argument for making the behaviour platform-dependent. -- 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] splitext('.cshrc')
On 10:18 pm, [EMAIL PROTECTED] wrote: Phillip J. Eby schrieb: At 10:01 PM 3/6/2007 +0100, Martin v. L�wis wrote: It's unfortunate, of course, that people apparently relied on this behavior I was going to say it's the *documented* behavior, but I see that the documentation is actually such that it could be interpreted either way. However, since it's not documented more specifically, it seems perfectly reasonable to rely on the implementation's behavior to resolve the ambiguity. Despite the generally quite good documentation, I've learned about how quite a lot of how the standard library works by messing around at the interactive interpreter. This is one cost of the incompatibility - having to re-train developers who thought they knew how something worked, or are continuing to write new software while experimenting with older VMs. Sure, it is an incompatible change, no doubt. However, incompatible changes are ok for feature releases (not so fo bugfix releases). Incompatible changes may be *acceptable* for feature releases, but that doesn't mean they are desirable. The cost of incompatibility should be considered for every change. This cost is particularly bad when the incompatibility is of the silent breakage variety - the change being discussed here would not be the sort of thing that one could, say, produce a warning about or gently deprecate; anything relying on the old behavior would suddenly be incorrect, and any software wishing to straddle the 2.5-2.6 boundary would be better off just implementing their own splitext() than relying on the stdlib. So this being an incompatible change alone is not a reason to reject the patch. Significant breakage in many applications might be, but I don't expect that for this change (which is really tiny). Software is a chaotic system. The size of the change is unrelated to how badly it might break things. More to the point, we know the cost, what's the benefit? Is there any sort of bug that it is likely to prevent in *new* code? It clearly isn't going to help any old code. It seems there are people who see it both ways, and I haven't seen anything compelling to indicate that either behavior is particularly less surprising in the edge case. In cases like this, historical context should be considered, even for a major overhaul like 3.0. Of course, if the newly proposed semantics provided a solution to a real problem or common error, compatibility might be determined to be a less important issue. The use-cases being discussed here would be better served by having new APIs that do particular things and don't change existing semantics, though. For example, a guess_mime_type(path) function which could examine a path and figure out its mime type based on its extension (among other things). ___ 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
