[Python-Dev] Case-sensitive import

[Tim Peters]

[Steven D. Majewski]
> ...
> The intent was that it be *able* to compile on any unix-like platform --
> in particular, I was thinking LinuxPPC was the other case I could
> think of where someone might want to use a HFS+ filesystem - but
> that Darwin/MacOSX was likely to be the only system in which that was
> the default.

I don't care about LinuxPPC right now.  When someone steps up to champion
that platform, they can deal with it then.  What I am interested in is
supporting the platforms we *do* have warm bodies looking at, and not
regressing on any of them.  I'm surprised nobody on Linux already screamed.

>> Anyone, doesn't that trigger on straight Linux systems too (all I know is
>> that it's part of the Single UNIX Specification)?

> Yes. Barry added the _DIRENT_HAVE_D_NAMELINE to handle a difference in
> the linux dirent structs. ( I'm not sure if he caught my initial
> statement of intent either, but then the discussion veered into whether
> the patch should have been accepted at all, and then into the discussion
> of a general solution... )
>
> I'm not happy with the ineffeciency either, but, as I noted, I didn't
> expect that it would be enabled by default elsewhere when I submitted
> it.

I expect it's enabled everywhere the #ifdef's in the patch enabled it
<wink/frown>.  But I don't care about the past either, I want to straighten
it out *now*.

> ( And my goal for OSX was just to have a version that builds and
> doesn't crash much, so searching for a more effecient solution was
> going to be the next project. )

Then this is the right time.  Play along by pretending that OSX is the
special case that it is <0.9 wink>.

> ...
> The reason I started from scratch, you might recall, was that before I
> understood that the Windows semantics was intended to be different, I
> tried adding a Mac version of check_case, and it didn't do what I wanted.
> But that wasn't a problem with any of the existing check_case functions,
> but was due to how check_case was used.

check_case will be used differently now.

> ...
> One problem is that I'm aiming for a version that would work on both
> the open source Darwin distribution ( which is mach + BSD + some Apple
> extensions: Objective-C, CoreFoundation, Frameworks, ... but not most
> of the macosx Carbon and Cocoa libraries. ) and the full MacOSX.
> Thus the reason for a unix only implementation -- the info may be
> more easily available via MacOS FSSpec's but that's not available
> on vanilla Darwin. ( And I can't, for the life of me, thing of an
> effecient unix implementation -- UNIX file system API's + HFS+ filesystem
> semantics may be an unfortunate mixture! )

Please just solve the problem for the platforms you're actually running on --
case-insensitive filesystems are not "Unix only" in any meaningful sense of
that phrase, and each not-really-Unix platform is likely to have its own
stupid gimmicks for worming around this problem anyway.  For example, Cygwin
defers to the Windows API.  Great!  That solves the problem there.
Generalization is premature.

> In other words: I can rename the current version to  check_case and
> fix the args to match. (Although, I recall that the args to check_case
> were rather more awkward to handle, but I'll have to look again. )

Good!  I'm not going to wait for that, though.  I desperately need a nap, but
when I get up I'll check in changes that should be sufficient for the Windows
and Cygwin parts of this, without regressing on other platforms.  We'll then
have to figure out whatever #ifdef'ery is needed for your platform(s).

> getenv() works on OSX (it's the BSD unix implementation).

So it's *kind* of like Unix after all <wink>.

> ( I *think* that Jack has the MacPython get the variables from Pythoprefs
>   file settings. )

Haven't heard from him, but getenv() is used freely in the Python codebase
elsewhere, so I figure he's got *some* way to fake it.  So I'm not worried
about that anymore (until Jack screams about it).