A thread import problem

[Bruce Sherwood]

On Sun, Jul 22, 2012 at 3:48 PM, Dennis Lee Bieber
<wlfraed at ix.netcom.com> wrote:
> On Sun, 22 Jul 2012 13:04:25 -0600, Bruce Sherwood
> <bruce.sherwood at gmail.com> declaimed the following in
> gmane.comp.python.general:
>
>
>> Another way of saying this is that I'm not building an app, in which
>> case I would structure things in a simple and straightforward manner.
>> I am instead trying to maintain and update a library that allows
>> novice programmers to write programs that generate real-time navigable
>> 3D animations, writing minimalist programs that work cross-platform.
>>
>         I suspect you don't need to update the library so much as enforce a
> project style that prevents your import-thread-import cycle. In short,
> something like that hypothetical "runner()" design.
>
>         Oh, and document that style in detail: "importable modules shall
> only perform module level definition of entities during import -- no
> code that actually processes data"; "importable modules shall make use
> of the 'if __name__ == "__main__": main()' convention to identify when
> the module is being used stand-alone, and thereby invoke the main
> processing; otherwise the module.main() function is to be invoked only
> be the module doing the imports, after the import has completed"
> etc.
>
> --
>         Wulfraed                 Dennis Lee Bieber         AF6VN
>         wlfraed at ix.netcom.com    HTTP://wlfraed.home.netcom.com/
>
> --
> http://mail.python.org/mailman/listinfo/python-list

There's nothing wrong with the current VPython architecture, which
does use good style, but there are two absolute, conflicting
requirements that I have to meet.

(1) The simple program API I've shown must be preserved, because there
exist a large number of such programs in existence, used by lots of
people. I can't change the API. Among other uses, every semester there
are about 5000 students in introductory college science courses,
especially physics, who do computational modeling with 3D
visualizations based on instructional materials that teach the
existing API. There is also a large number of instructors who depend
on existing VPython demo programs to continue working even if the
college upgrades Python and VPython. This isn't some little project
where I'm able to teach my small group of collaborators how they
should structure programs.

(2) My hand is forced by Apple no longer supporting Carbon. Among
other aspects of this, Carbon can't be used with 64-bit Python, and
more and more Mac users of VPython want to use 64-bit Python. So there
has to be a version of VPython that is based on Cocoa, but Cocoa is
required to be the primary thread. This requirement, combined with the
absolute requirement that the VPython API cannot be changed, is the
problem I face. I have to turn the architecture inside out,
independent of whether the solution meets all criteria for good Python
programming style.

Bruce Sherwood