OS X import bug? (it gets worse)

[Steven Majewski]

On Fri, 25 Jan 2002, Pete Shinners wrote:

> there's more bugs in the OSX module loader. one of my OSX porters has
> fixed this himself, but i don't believe yet submitted anything. in any
> event i'm told it's a quick-fix, but here's the problem for you OSX
> maintainers...
>
> in my pygame package i have a "time" module. this is an extension
> library. this has not been a problem from python-1.5.2 and up on every
> different platform. users can easily choose between the stdlib time and
> the pygame time
>
> import time  #std
> import pygame.time  #mine
>
> problem is, on OSX the command "import time" is actually importing my
> time module, from inside my package (i'm not using PTH files or anything
> either).

 Actually, the behaviour I see when I try to reproduce this is that
whichever module you import first get's used for both, so in the
example above, pygame.time would refer to the standard time module;
swapping the order of the imports gives me the state you describe,
where both refer to your timemodule. Is that what you see ?
 The -v seems to show that it's finding the right module.
I think what's happening is that once 'inittime' is bound, it
stays bound. (I'm surprised that there's no error message, though!)

 I tried swapping the calls to NSLookupAndBindSymbol() to calls to
NSLookupSymbolInModule() [ which is what the dlcompat libs seem to
use instead ] but it didn't change the behaviour:

#define NSLookupAndBindSymbol( f )  NSLookupSymbolInModule( newmodule, f )


> of course, my time module doesn't have the same functions as the
> standard one. so when standard modules (like random) say "import time"
> they are getting the wrong module and raise a quick exception.
>
> i really hope this can get fixed for python-2.2.1. :]
>


 But I'll take a closer look at this.


-- Steve