On Sun, Jul 22, 2012 at 3:48 PM, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote: > On Sun, 22 Jul 2012 13:04:25 -0600, Bruce Sherwood > <bruce.sherw...@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 > wlfr...@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 -- http://mail.python.org/mailman/listinfo/python-list
