[Steven D. Majewski]
... Is there any consensus on how to deal with this ?
No, else it would have been done already.
... So it appears that I don't understand the issues on other platforms and what CHECK_IMPORT_CASE intends to fix.
It started on Windows. The belief was that people (not developers -- your personal testimony doesn't count, and neither does mine <0.3 wink>) on case-insensitive file systems don't pay much attention to the case of names they type. So the belief was (perhaps it even happened -- I wasn't paying attention at the time, since I was a Unix Dweeb then) people would carelessly write, e.g., import String and then pick up some accidental String.py module instead of the builtin "string" they intended. So Python started checking for case-match on Windows, and griping if the *first* module name Windows returns didn't match case exactly. OK, it's actually more complicated than that, because some network filesystems used on Windows actually changed all filenames to uppercase. So there's an exception made for that wart too. Anyway, looks like a blind guess to me whether this actually does anyone any good. For efficiency, it *does* stop at the first, so if the user typed import string *intending* to import String.py, they'd never hear about their mistake. So it doesn't really address the whole (putative) problem regardless. It only gripes if the first case-insensitive match on the path doesn't match exactly. However, *if* it makes sense on Windows, then it makes exactly as much sense on "the standard filesystem ... Apple's HFS+, which is case preserving but case insensitive" -- same deal as Windows. I see no reason to believe that non-developer users on Macs are going to be more case-savvy than on Windows (or is there a reason to believe that?). Another wart is that it's easy to create Python modules that import fine on Unix, but blow up if you try to run them on Windows (or HFS+). That sucks too, and isn't just theoretical (although in practice it's a lot less common than tracking down binary files opened in text mode!). The Cygwin people have a related problem: they *are* trying to emulate Unix, but doing so on a Windows box, so, umm, enjoy the best of all worlds. I'd rather see the same rule used everywhere (keep going until finding an exact match), and tough beans to the person who writes import String on Windows (or Mac) intending "string". Windows probably still needs a unique wart to deal with case-destroying network filesystems, though. It's still terrible style to *rely* on case-sensitivity in file names, and all such crap should be purged from the Python distribution regardless. guido-will-agree-with-exactly-one-of-these-claims<wink>-ly y'rs - tim
On Fri, 2 Feb 2001, Tim Peters wrote:
I'd rather see the same rule used everywhere (keep going until finding an exact match), and tough beans to the person who writes
import String
on Windows (or Mac) intending "string". Windows probably still needs a unique wart to deal with case-destroying network filesystems, though.
I agree, and that's what my patch does for macosx.darwin (or any unixy system that happens to have a filesystem with similar semantics -- if there is any such beast.) If the issues for windows are different (and it sounds like they are) then I wanted to make sure (collectively) you were aware that this patch could be addressed independently, rather than waiting on a resolution of those other problems.
It's still terrible style to *rely* on case-sensitivity in file names, and all such crap should be purged from the Python distribution regardless.
I agree. However, even if we purged all only-case-differing file names, without a patch on macosx, you still can crash python with a miscase typo, as it'll try to import the same module twice under a different name:
import cStringIO import cstringio dyld: python2.0 multiple definitions of symbol _initcStringIO /usr/local/lib/python2.0/lib-dynload/cStringIO.so definition of _initcStringIO /usr/local/lib/python2.0/lib-dynload/cstringio.so definition of _initcStringIO
while with the patch, I get: ImportError: No module named cstringio
---| Steven D. Majewski (804-982-0831)
Tim> It's still terrible style to *rely* on case-sensitivity in file Tim> names, and all such crap should be purged from the Python Tim> distribution regardless. Then the Python directory or the python executable should be renamed. I sense some deja vu here... anyone-for-a.out?-ly y'rs, Skip
On Fri, 2 Feb 2001, Skip Montanaro wrote:
Tim> It's still terrible style to *rely* on case-sensitivity in file Tim> names, and all such crap should be purged from the Python Tim> distribution regardless.
Then the Python directory or the python executable should be renamed. I sense some deja vu here...
anyone-for-a.out?-ly y'rs,
I was going to suggest renaming the Python/ directory to Core/, but what happens when it tries to dump core ? -- Steve
On Fri, Feb 02, 2001 at 01:50:45PM -0500, Barry A. Warsaw wrote:
"SDM" == Steven D Majewski
writes: SDM> I was going to suggest renaming the Python/ directory to SDM> Core/, but what happens when it tries to dump core ?
Interpreter/ ??
If we do bite the bullet and make this change I vote for PyCore. Neil
Steve> I was going to suggest renaming the Python/ directory to Core/, Steve> but what happens when it tries to dump core ? PyCore? There was a thread on this recently, and Guido nixed the idea of renaming anything, but I can't remember what his rationale was. Something about breaking build instructions somewhere? Skip
It's been suggested (eg pyCore).... and shot down.... uhh, IIRC, due to "millions and millions of Python developers" (thanks Tim! <wink>) who don't want to change their directory structures and the fact that nobody wanted to lose the CVS log files/do the clean up... Alas, we gonna go around and around until we either decide to bite the bullet and "just do it" or allow a multitude of hacks to be put in place to work around the issue... it-may-be-painful-once-but-it's-a-lot-less-painful-than-a-thousand- times'ly yours, - Dan On Friday, February 2, 2001, at 10:46 AM, Steven D. Majewski wrote:
On Fri, 2 Feb 2001, Skip Montanaro wrote:
Tim> It's still terrible style to *rely* on case-sensitivity in file Tim> names, and all such crap should be purged from the Python Tim> distribution regardless.
Then the Python directory or the python executable should be renamed. I sense some deja vu here...
anyone-for-a.out?-ly y'rs,
I was going to suggest renaming the Python/ directory to Core/, but what happens when it tries to dump core ?
-- Steve
[Dan Wolfe]
It's been suggested (eg pyCore).... and shot down.... uhh, IIRC, due to "millions and millions of Python developers" (thanks Tim! <wink>) who don't want to change their directory structures and the fact that nobody wanted to lose the CVS log files/do the clean up...
Don't thank me, thank Bill Gates for creating a wonderful operating system where I get to ignore *all* the 57-varieties-of-Unix build headaches. That's the only reason I'm so cheerful about supporting unbounded damage to everyone else. But, it's a good reason <wink>. BTW, I didn't grok the CVS argument. You don't change the name of the directory, you change the name of the executable. And the obvious name is obvious to me: python.exe <wink>. no-need-to-rewrite-history-ly y'rs - tim
"TP" == Tim Peters
writes:
TP> Don't thank me, thank Bill Gates for creating a wonderful TP> operating system where I get to ignore *all* the TP> 57-varieties-of-Unix build headaches. And thank goodness for Un*x, where I get to ignore all the 69 different varieties of The One True Operating System -- all Windows OSes are created equal, right? :) TP> BTW, I didn't grok the CVS argument. You don't change the TP> name of the directory, you change the name of the executable. TP> And the obvious name is obvious to me: python.exe <wink>. Even a Un*x dweeb like myself would agree, if you have to change one of them, change the executable. I see no reason why on Un*x the build procedure couldn't drop a symlink from python.exe to python for backwards compatibility and convenience. -Barry
barry wrote:
Even a Un*x dweeb like myself would agree, if you have to change one of them, change the executable. I see no reason why on Un*x the build procedure couldn't drop a symlink from python.exe to python for backwards compatibility and convenience.
real Unix users will probably not care, but what do you think the Linux kiddies will think about Python when they find evil-empire- style executables in the build directory? Cheers /F
[Barry A. Warsaw]
And thank goodness for Un*x, where I get to ignore all the 69 different varieties of The One True Operating System -- all Windows OSes are created equal, right? :)
Yes, and every one of them perfect, albeit each in its own unique way <wink>. I wouldn't wish it on anyone, but, in the end, even you would have rather done the Win64 port from scratch than try to close the HPUX bugs still open. Heh heh.
Even a Un*x dweeb like myself would agree, if you have to change one of them, change the executable. I see no reason why on Un*x the build procedure couldn't drop a symlink from python.exe to python for backwards compatibility and convenience.
Of course I wasn't serious about that. To judge from a decade of Unix-newbie postings to c.l.py, we should rename the executable there to phyton. That's what they think the language is named anyway. always-eager-to-aid-my-unixoid-brethren-ly y'rs - tim
participants (7)
-
barry@digicool.com
-
Dan Wolfe
-
Fredrik Lundh
-
Neil Schemenauer
-
Skip Montanaro
-
Steven D. Majewski
-
Tim Peters