On 08 Oct, 2010,at 11:38 AM, Michael Foord wrote: On 08/10/2010 09:41, Chris Withers wrote:
4. Return the case of a filename in some arbitrarily-chosen
canonical form which does not depend on the file system? AFAIK this is what the function is supposed to do: return a platform-dependent
On 08/10/2010 09:41, Chris Withers wrote:
On 05/10/2010 12:04, Steven D'Aprano wrote:
On Tue, 5 Oct 2010 07:21:15 pm Chris Withers wrote:
On 25/09/2010 04:25, Steven D'Aprano wrote:
[snip...]
FWIW, the use case that setuptools has (and
for which it currently incorrectly uses normpath) is numbe
On 05/10/2010 12:04, Steven D'Aprano wrote:
On Tue, 5 Oct 2010 07:21:15 pm Chris Withers wrote:
On 25/09/2010 04:25, Steven D'Aprano wrote:
1. Return the case of a filename in some canonical form which
depends on the file system?
2. Return the case of a filename as it is actually stored on disk
On Tue, 5 Oct 2010 07:21:15 pm Chris Withers wrote:
> On 25/09/2010 04:25, Steven D'Aprano wrote:
> > 1. Return the case of a filename in some canonical form which
> > depends on the file system?
> > 2. Return the case of a filename as it is actually stored on disk?
>
> How do 1 and 2 differ?
Case
On 25/09/2010 15:45, Guido van Rossum wrote:
The solution may well be OS specific. Solutions for Windows and OS X
have already been pointed out. If it can't be done for other Unix
versions, I think returning the input unchanged on those platform is a
fine fallback (as it is for non-existent filen
On 25/09/2010 04:25, Steven D'Aprano wrote:
1. Return the case of a filename in some canonical form which depends
on the file system?
2. Return the case of a filename as it is actually stored on disk?
How do 1 and 2 differ? FWIW, the use case that setuptools has (and for
which it currently
On Oct 3, 2010, at 9:18 AM, Dan Villiom Podlaski Christiansen wrote:
> A simpler alternative would probably be the F_GETPATH fcntl. An example:
That requires that you have permission to open the file (and to actually do so
which might have other effects), while the File Manager's FSRef method doe
On 3 Oct 2010, at 02:35, Nir Soffer wrote:
On Sat, Sep 25, 2010 at 1:36 AM, James Y Knight wrote:
An OSX code sketch is available here (summary: call FSPathMakeRef
to get an
FSRef from a path string, then FSRefMakePath to make it back into a
path,
which will then have the correct case). A
On Sat, Sep 25, 2010 at 1:36 AM, James Y Knight wrote:
>
> An OSX code sketch is available here (summary: call FSPathMakeRef to get an
> FSRef from a path string, then FSRefMakePath to make it back into a path,
> which will then have the correct case). And note that it only works if the
> file act
On Sun, Sep 26, 2010 at 06:36, Paul Moore wrote:
> On 26 September 2010 09:01, Paul Moore wrote:
> > On 25 September 2010 23:57, Greg Ewing
> wrote:
> >> Paul Moore wrote:
> >>
> >>> Windows has (I believe) user definable filesystems, too, but the OS
> >>> has "get me the real filename" style c
On 26 September 2010 13:37, James Y Knight wrote:
>
> Were you thinking of SHGetFileInfo?
>
> http://stackoverflow.com/questions/74451/getting-actual-file-name-with-proper-casing-on-windows
It wasn't, but it looks possible. Only gives the last component,
though, so you still have to walk up the p
On Sep 26, 2010, at 7:36 AM, Paul Moore wrote:
> On 26 September 2010 09:01, Paul Moore wrote:
>> On 25 September 2010 23:57, Greg Ewing wrote:
>>> Paul Moore wrote:
>>>
Windows has (I believe) user definable filesystems, too, but the OS
has "get me the real filename" style calls,
>>
On Sun, Sep 26, 2010 at 13:36, Paul Moore wrote:
> Hmm, I can't find the one I was thinking of. GetLongFileName correctly
> sets the case of all but the final part, and FindFile can be used to
> find the last part, but that's not what I recall.
>
> GetFinalPathNameByHandle works, and is documented
On 26 September 2010 09:01, Paul Moore wrote:
> On 25 September 2010 23:57, Greg Ewing wrote:
>> Paul Moore wrote:
>>
>>> Windows has (I believe) user definable filesystems, too, but the OS
>>> has "get me the real filename" style calls,
>>
>> Does it really, though? The suggestions I've seen for
On 25 September 2010 23:57, Greg Ewing wrote:
> Paul Moore wrote:
>
>> Windows has (I believe) user definable filesystems, too, but the OS
>> has "get me the real filename" style calls,
>
> Does it really, though? The suggestions I've seen for doing
> this involve abusing the short/long filename t
Paul Moore wrote:
Windows has (I believe) user definable filesystems, too, but the OS
has "get me the real filename" style calls,
Does it really, though? The suggestions I've seen for doing
this involve abusing the short/long filename translation
machinery, and I'm not sure they're guaranteed
On Fri, Sep 24, 2010 at 8:25 PM, Steven D'Aprano wrote:
> On Sat, 25 Sep 2010 09:22:47 am Guido van Rossum wrote:
>
>> I think that, like os.path.realpath(), it should not fail if the file
>> does not exist.
>>
>> Maybe the API could be called os.path.unnormpath(), since it is in a
>> sense the op
Paul Moore writes:
> In fact, with userfs, I believe it's possible to do massively
> pathological things like having a filesystem which treats anagrams
> as the same file (foo is the same file as oof or ofo). (More
> realistically, MacOS does Unicode normalisation).
Nitpick: Mac OS X doesn't
On 24 September 2010 23:43, Glenn Linderman wrote:
> Hmm. There is no need for the function on a case sensitive file system,
> because the name had better be spelled with matching case: that is, if it is
> spelled with non-matching case it is an attempt to reference a non-existent
> file (or at l
On Sat, 25 Sep 2010 09:22:47 am Guido van Rossum wrote:
> I think that, like os.path.realpath(), it should not fail if the file
> does not exist.
>
> Maybe the API could be called os.path.unnormpath(), since it is in a
> sense the opposite of normpath() (which removes case) ? But I would
> want to
Guido van Rossum wrote:
Maybe the API could be called os.path.unnormpath(), since it is in a
sense the opposite of normpath() (which removes case) ?
Cute, but not very intuitive. Something like actualpath()
might be better -- although that's somewhat arbitrarily
different from realpath().
--
On Sep 24, 2010, at 10:53 AM, Paul Moore wrote:
> On 24 September 2010 15:29, Guido van Rossum wrote:
>> I don't think we should try to reimplement what the filesystem does. I
>> think we should just ask the filesystem (how exactly I haven't figured
>> out yet but I expect it will be more OS-speci
I think that, like os.path.realpath(), it should not fail if the file
does not exist.
Maybe the API could be called os.path.unnormpath(), since it is in a
sense the opposite of normpath() (which removes case) ? But I would
want to write it so that even on Unix it scans the filesystem, in case
the
On 9/24/2010 3:10 PM, Greg Ewing wrote:
Paul Moore wrote:
I dug into this once, and as far as I could tell, it's possible to get
the information on Windows, but there's no way on Linux to "ask the
filesystem".
Maybe we could use a heuristic such as:
1) Search the directory for an exact matc
Paul Moore wrote:
I dug into this once, and as far as I could tell, it's possible to get
the information on Windows, but there's no way on Linux to "ask the
filesystem".
Maybe we could use a heuristic such as:
1) Search the directory for an exact match to the name given,
return it if found.
On 24 September 2010 15:29, Guido van Rossum wrote:
> I don't think we should try to reimplement what the filesystem does. I
> think we should just ask the filesystem (how exactly I haven't figured
> out yet but I expect it will be more OS-specific than
> filesystem-specific). It will have to be a
On Fri, 24 Sep 2010 07:29:40 -0700
Guido van Rossum wrote:
> It will have to be a new API -- normcase() at
> least is *intended* to return a case-flattened name on OSes where
> case-preserving filesystems are the default, and changing it to look
> at the filesystem would break too much code. For a
On Fri, Sep 24, 2010 at 5:17 AM, R. David Murray wrote:
> On Fri, 24 Sep 2010 11:13:46 +0100, Chris Withers
> wrote:
>> On 18/09/2010 23:36, Guido van Rossum wrote:
>> > course, exists() and isdir() etc. do, and so does realpath(), but the
>> > pure parsing functions don't.
>>
>> Yes, but:
>>
>>
On Fri, 24 Sep 2010 11:13:46 +0100, Chris Withers
wrote:
> On 18/09/2010 23:36, Guido van Rossum wrote:
> > course, exists() and isdir() etc. do, and so does realpath(), but the
> > pure parsing functions don't.
>
> Yes, but:
>
> H:\>echo foo > TeSt.txt
> ...>>> import os.path
> >>> os.path.re
On 9/24/2010 6:13 AM, Chris Withers wrote:
On 18/09/2010 23:36, Guido van Rossum wrote:
course, exists() and isdir() etc. do, and so does realpath(), but the
pure parsing functions don't.
Yes, but:
H:\>echo foo > TeSt.txt
...>>> import os.path
>>> os.path.realpath('test.txt')
'H:\\test.txt'
On 18/09/2010 23:36, Guido van Rossum wrote:
course, exists() and isdir() etc. do, and so does realpath(), but the
pure parsing functions don't.
Yes, but:
H:\>echo foo > TeSt.txt
...>>> import os.path
>>> os.path.realpath('test.txt')
'H:\\test.txt'
>>> os.path.normcase('TeSt.txt')
'test.txt'
On Sat, Sep 18, 2010 at 2:39 PM, Chris Withers wrote:
> I'm curious as to why, with a file called "Foo.txt" on a case descriminating
> but case insensitive filesystem, os.path.normcase('FoO.txt') will return
> "foo.txt" rather than "Foo.txt"?
>
> Yes, I know the behaviour is documented, but I'm wo
32 matches
Mail list logo
