Glenn, great post and points! > > Andy seems to want an implementation of independent Python processes > implemented as threads within a single address space, that can be > coordinated by an outer application. This actually corresponds to the > model promulgated in the paper as being most likely to succeed.
Yeah, that's the idea--let the highest levels run and coordinate the show. > > It does seem simpler and more efficient to simply "copy" > data from one memory location to another, rather than send it in a > message, especially if the data are large. That's the rub... In our case, we're doing image and video manipulation--stuff not good to be messaging from address space to address space. The same argument holds for numerical processing with large data sets. The workers handing back huge data sets via messaging isn't very attractive. > One thing Andy hasn't yet explained (or I missed) is why any of his > application is coded in a language other than Python. Our software runs in real time (so performance is paramount), interacts with other static libraries, depends on worker threads to perform real-time image manipulation, and leverages Windows and Mac OS API concepts and features. Python's performance hits have generally been a huge challenge with our animators because they often have to go back and massage their python code to improve execution performance. So, in short, there are many reasons why we use python as a part rather than a whole. The other area of pain that I mentioned in one of my other posts is that what we ship, above all, can't be flaky. The lack of module cleanup (intended to be addressed by PEP 3121), using a duplicate copy of the python dynamic lib, and namespace black magic to achieve independent interpreters are all examples that have made using python for us much more challenging and time-consuming then we ever anticipated. Again, if it turns out nothing can be done about our needs (which appears to be more and more like the case), I think it's important for everyone here to consider the points raised here in the last week. Moreover, realize that the python dev community really stands to gain from making python usable as a tool (rather than a monolith). This fact alone has caused lua to *rapidly* rise in popularity with software companies looking to embed a powerful, lightweight interpreter in their software. As a python language fan an enthusiast, don't let lua win! (I say this endearingly of course--I have the utmost respect for both communities and I only want to see CPython be an attractive pick when a company is looking to embed a language that won't intrude upon their app's design). Andy -- http://mail.python.org/mailman/listinfo/python-list
