On Sat, Apr 17, 2010 at 1:33 AM, Joe Wreschnig <[email protected]> wrote: > pyglet's delayed imports seem to be having some very nasty > side-effects on execution time. For example, sprite.py contains "from > pyglet import image". If this runs before image is imported and used, > this results in image being a reference to the ModuleProxy. The first > time it accesses (e.g.) image.Animation, it will correctly add > pyglet.image to sys.modules, but because the image variable bind is > local to sprite.py, it won't change update it. This results in all > future access being proxied by a __getattr__, which is much slower. > > In practice, this only seems to be a problem in sprite.py, which > checks a sprite's texture's class against image.Animation, but it's > still a really surprising (and if you're changing sprite textures a > lot, bad) side effect. > > I have to say I've never really been enamored with pyglet's lazy > module loading. It felt like a hack because someone didn't want to > make their import requirements explicit, or didn't want to clean up > unused imports which pyglet seems to have a ton of. Even with it, > pyglet's startup time is too long to feel "instant", and once it's not > "instant" you have a pretty long period of time before something feels > "too slow". Maybe it's a system that's outlived its usefulness?
My understanding was that most of the import trickery was to work around circular import problems, but I could be wrong in this case. -Casey -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
