2.6, 3.0, and truly independent intepreters

[Andy O'Meara]

On Oct 27, 10:55 pm, Glenn Linderman <v+pyt... at g.nevcal.com> 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