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
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
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
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
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
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 =
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
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
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
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
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
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
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
[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
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
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
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
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.
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
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
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
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
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
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
#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?
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
57 matches
Mail list logo
