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
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
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 c
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 antipatter
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 assoc
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
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
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
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 = spl
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
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 becomi
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 sp
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 withou
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
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 subseque
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
> th
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
> >
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 semant
""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 t
"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
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,
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
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 incompati
[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
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 tha
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 th
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 fi
"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
stri
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 ei
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 d
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.pyt
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
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 th
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 oppo
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 wr
"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.
W
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
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 loo
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 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 imp
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 f
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 th
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
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
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,
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 alway
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
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, t
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 i
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:
>> 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 e
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
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 on
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
> e
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 d
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 (
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
> ext
#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? Opini
58 matches
Mail list logo
