On 12/04/2013 22:15, Larry Hastings wrote:
On 04/12/2013 10:05 AM, Guido van Rossum wrote:
On Fri, Apr 12, 2013 at 1:39 AM, Antoine Pitrou
wrote:
I think we want glob("*.py") to find
"SETUP.PY" under Windows. Anything else will probably be surprising to
users of that platform.
Yeah, I suppos
On 04/12/2013 10:05 AM, Guido van Rossum wrote:
On Fri, Apr 12, 2013 at 1:39 AM, Antoine Pitrou wrote:
I think we want glob("*.py") to find
"SETUP.PY" under Windows. Anything else will probably be surprising to
users of that platform.
Yeah, I suppose so. But there are more crazy details. E.g.
On Fri, 12 Apr 2013 19:42:25 +0200
Ralf Schmitt wrote:
> Guido van Rossum writes:
>
> > Actually, I've heard of code that dynamically falls back on short
> > names when paths using long names exceed the system limit for path
> > length (either 256 or 1024 IIRC). But short names pretty much requi
Guido van Rossum writes:
> Actually, I've heard of code that dynamically falls back on short
> names when paths using long names exceed the system limit for path
> length (either 256 or 1024 IIRC). But short names pretty much require
> consulting the filesystem, so we can probably ignore them.
T
On Fri, Apr 12, 2013 at 1:39 AM, Antoine Pitrou wrote:
> Ok, I've taken a look at the code. Right now lower() is used for two
> purposes:
>
> 1. comparisons (__eq__ and __ne__)
> 2. globbing and matching
>
> While (1) could be dropped, for (2) I think we want glob("*.py") to find
> "SETUP.PY" unde
On 12 Apr, 2013, at 16:59, Antoine Pitrou wrote:
> Le Fri, 12 Apr 2013 14:43:42 +0200,
> Ronald Oussoren a écrit :
>>
>> On 12 Apr, 2013, at 10:39, Antoine Pitrou wrote:
Perhaps it would be best if the code never called lower() or
upper() (not even indirectly via os.path
Le Fri, 12 Apr 2013 14:43:42 +0200,
Ronald Oussoren a écrit :
>
> On 12 Apr, 2013, at 10:39, Antoine Pitrou wrote:
> >>
> >>
> >> Perhaps it would be best if the code never called lower() or
> >> upper() (not even indirectly via os.path.normcase()). Then any
> >> case-folding and path-normaliz
On 12 Apr, 2013, at 15:00, Christian Heimes wrote:
> Am 12.04.2013 14:43, schrieb Ronald Oussoren:
>> At least for OSX the kernel will normalize names for you, at least for HFS+,
>> and therefore two names that don't compare equal with '==' can refer to the
>> same file (for example the NFKD and
Am 12.04.2013 14:43, schrieb Ronald Oussoren:
> At least for OSX the kernel will normalize names for you, at least for HFS+,
> and therefore two names that don't compare equal with '==' can refer to the
> same file (for example the NFKD and NFKC forms of Löwe).
>
> Isn't unicode fun :-)
Seriousl
On 12 Apr, 2013, at 10:39, Antoine Pitrou wrote:
>>
>>
>> Perhaps it would be best if the code never called lower() or upper()
>> (not even indirectly via os.path.normcase()). Then any case-folding
>> and path-normalization bugs are the responsibility of the application,
>> and we won't have to
Le Fri, 12 Apr 2013 08:06:37 -0400,
Devin Jeanpierre a écrit :
> On Fri, Apr 12, 2013 at 4:39 AM, Antoine Pitrou
> wrote:
> > Ok, I've taken a look at the code. Right now lower() is used for two
> > purposes:
> >
> > 1. comparisons (__eq__ and __ne__)
> > 2. globbing and matching
> >
> > While (1
On Fri, Apr 12, 2013 at 4:39 AM, Antoine Pitrou wrote:
> Ok, I've taken a look at the code. Right now lower() is used for two
> purposes:
>
> 1. comparisons (__eq__ and __ne__)
> 2. globbing and matching
>
> While (1) could be dropped, for (2) I think we want glob("*.py") to find
> "SETUP.PY" unde
On 12 April 2013 09:39, Antoine Pitrou wrote:
> Ok, I've taken a look at the code. Right now lower() is used for two
> purposes:
>
> 1. comparisons (__eq__ and __ne__)
> 2. globbing and matching
>
> While (1) could be dropped, for (2) I think we want glob("*.py") to find
> "SETUP.PY" under Window
Le Thu, 11 Apr 2013 15:42:00 -0700,
Guido van Rossum a écrit :
> On Thu, Apr 11, 2013 at 2:27 PM, Antoine Pitrou
> wrote:
> > On Thu, 11 Apr 2013 14:11:21 -0700
> > Guido van Rossum wrote:
> >> Hey Antoine,
> >>
> >> Some of my Dropbox colleagues just drew my attention to the
> >> occurrence of
On Thu, Apr 11, 2013 at 11:27 PM, Antoine Pitrou wrote:
> Hmm, I think I'm tending towards the latter right now.
You might also want to look at what Mercurial does. As a
cross-platform filesystem-oriented tool, it has some interesting
issues in the department of casefolding.
Cheers,
Dirkjan
___
On 11Apr2013 16:23, Guido van Rossum wrote:
| On Thu, Apr 11, 2013 at 4:09 PM, Cameron Simpson wrote:
| > On 11Apr2013 14:11, Guido van Rossum wrote:
| > | Some of my Dropbox colleagues just drew my attention to the occurrence
| > | of case folding in pathlib.py. Basically, case folding as an ap
On Thu, Apr 11, 2013 at 4:09 PM, Cameron Simpson wrote:
> On 11Apr2013 14:11, Guido van Rossum wrote:
> | Some of my Dropbox colleagues just drew my attention to the occurrence
> | of case folding in pathlib.py. Basically, case folding as an approach
> | to comparing pathnames is fatally flawed.
On 11Apr2013 14:11, Guido van Rossum wrote:
| Some of my Dropbox colleagues just drew my attention to the occurrence
| of case folding in pathlib.py. Basically, case folding as an approach
| to comparing pathnames is fatally flawed. The issues include:
|
| - most OSes these days allow the mountin
On Thu, Apr 11, 2013 at 2:27 PM, Antoine Pitrou wrote:
> On Thu, 11 Apr 2013 14:11:21 -0700
> Guido van Rossum wrote:
>> Hey Antoine,
>>
>> Some of my Dropbox colleagues just drew my attention to the occurrence
>> of case folding in pathlib.py. Basically, case folding as an approach
>> to compari
On Fri, Apr 12, 2013 at 09:29:44AM +1200, Robert Collins
wrote:
> On 12 April 2013 09:18, Oleg Broytman wrote:
> > On Thu, Apr 11, 2013 at 02:11:21PM -0700, Guido van Rossum
> > wrote:
> >> - the case-folding algorithm on some filesystems is burned into the
> >> disk when the disk is formatted
On 12 April 2013 09:18, Oleg Broytman wrote:
> On Thu, Apr 11, 2013 at 02:11:21PM -0700, Guido van Rossum
> wrote:
>> - the case-folding algorithm on some filesystems is burned into the
>> disk when the disk is formatted
>
>Into the partition, I guess, not the physical disc?
CDROMs - Joliet
On Thu, 11 Apr 2013 14:11:21 -0700
Guido van Rossum wrote:
> Hey Antoine,
>
> Some of my Dropbox colleagues just drew my attention to the occurrence
> of case folding in pathlib.py. Basically, case folding as an approach
> to comparing pathnames is fatally flawed. The issues include:
>
> - most
On Thu, Apr 11, 2013 at 02:11:21PM -0700, Guido van Rossum
wrote:
> - the case-folding algorithm on some filesystems is burned into the
> disk when the disk is formatted
Into the partition, I guess, not the physical disc?
Oleg.
--
Oleg Broytmanhttp://phdru.name/
Hey Antoine,
Some of my Dropbox colleagues just drew my attention to the occurrence
of case folding in pathlib.py. Basically, case folding as an approach
to comparing pathnames is fatally flawed. The issues include:
- most OSes these days allow the mounting of both case-sensitive and
case-insensi
24 matches
Mail list logo
