On Oct 27, 10:55 pm, Glenn Linderman <[EMAIL PROTECTED]> wrote:
> And I think we still are miscommunicating! Or maybe communicating anyway! > > So when you said "object", I actually don't know whether you meant > Python object or something else. I assumed Python object, which may not > have been correct... but read on, I think the stuff below clears it up. > > > Then when you mentioned thousands of objects, I imagined thousands of > Python objects, and somehow transforming the blob into same... and back > again. My apologies to you and others here on my use of "objects" -- I'm use the term generically and mean it to *not* refer to python objects (for the all the reasons discussed here). Python only makes up a small part of our app, hence my habit of "objects" to refer to other APIs' allocated and opaque objects (including our own and OS APIs). For all the reasons we've discussed, in our world, python objects don't travel around outside of our python C modules -- when python objects need to be passed to other parts of the app, they're converted into their non- python (portable) equivalents (ints, floats, buffers, etc--but most of the time, the objects are PyCObjects, so they can enter and leave a python context with negligible overhead). I venture to say this is pretty standard when any industry app uses a package (such as python), for various reasons: - Portability/Future (e.g. if we do decode to drop Python and go with Lua, the changes are limited to only one region of code). - Sanity (having any API's objects show up in places "far away" goes against easy-to-follow code). - MT flexibility (because we always never use static/global storage, we have all kinds of options when it comes to multithreading). For example, recall that by throwing python in multiple dynamic libs, we were able to achieve the GIL-less interpreter independence that we want (albeit ghetto and a pain). Andy -- http://mail.python.org/mailman/listinfo/python-list