Ideally Google should provide empty modules for all Python std lib stuff. It looks like they've already built a few empty modules like socket, I'd imagine to keep Django or some related piece of code happy.
In the meantime it looks like sys.meta_path is available to play with in AppEngine. We could throw an importer in there that returns empty "stub" modules for all the missing standard lib modules. This way we can at least keep the mess in a single import fixer module until the modules are made available in AppEngine. Check out http://mike.verdone.ca/pymisc/appengine/stub_importer.py It's the simplest thing that works. So long as you import that module before anything else, and provide an empty module named "stub", you can import anything in the STUB_MODULES list and it won't complain. In other news, AppEngine's pastel purple, heliotrope, and pink tracebacks are rather charming. Mike. On Thu, Apr 10, 2008 at 2:00 AM, Ian Bicking <[EMAIL PROTECTED]> wrote: > > I gave Pylons a brief try, and got discouraged by the number of import > problems. While I was commenting on the relevant ticket > (http://code.google.com/p/googleappengine/issues/detail?id=33) it became > clear to me that the only way of making Pylons work is to provide all > the missing modules and functions. > > This probably isn't that hard. It would be a package that would add in > the modules that are missing (e.g., subprocess), and monkeypatch the > modules that are missing functions (e.g., os). Not everything would > have an implementation, many of the functions would just raise > exceptions if you actually tried to use them. But everything would be > importable. Most of the problems are with imports, not with actual code > being run. > > This probably applies equally to the urllib ticket: > http://code.google.com/p/googleappengine/issues/detail?id=61 -- > presumably this library would also provide those functions, as it's the > same basic issue. > > I don't know if this is or should be part of the core of app engine. > Well, actually I do know: it should definitely be part of the core of > app engine (even if it's something you have to specifically enable). > The scope is obvious: put stuff back that was taken out. The reason is > clear: without that stuff being importable (and usable when possible), > many libraries not written for appengine won't work. And changing the > libraries just doesn't make sense. I actively want to make my libraries > work with appengine, but still I'm very reluctant to make these kinds of > changes to my libraries. A lot of upstream developers will totally balk > at the kind of changes they'd have to make. > > My mind is pretty settled on this strategy. But there remains a > question of where and how should this project go forward? > > -- > Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en -~----------~----~----~----~------~----~------~--~---
