Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #25837

Re: A thread import problem

Show key headers only | View raw

On Sun, 22 Jul 2012 17:14:28 -0600, Bruce Sherwood
<bruce.sherwood@gmail.com> declaimed the following in
gmane.comp.python.general:

> On Sun, Jul 22, 2012 at 3:48 PM, Dennis Lee Bieber
> <wlfraed@ix.netcom.com> wrote:
> > On Sun, 22 Jul 2012 13:04:25 -0600, Bruce Sherwood
> > <bruce.sherwood@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@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.
>
	As has been shown -- anything that spawns a thread during an import
is liable to cause a problem.

	The only viable solution that I've been able to see is to ensure
that any existing program is tweaked to make it "import safe" -- which,
so far, appears to be using the "if __name__..." scheme to prevent
running dangerous logic during an import.

	Using this scheme does not change the program behavior when used
stand-alone (as they currently exist); but does make them viable when
wrapped for your "inside out" architecture (import, THEN spawn the main
process as a thread, or maybe even just run it as a direct function).

	For NEW programs (those generated by your "...novice programmers to
write programs..."), specifying a coding style to use "if __name__..."
would make new programs usable without the headaches existing programs
bring.

	I see NO viable means to have an outside program magically be able
to load/execute one of these existing programs unless it is able to
parse the source file and wrap the dangerous executable statements into
a function for later calling after the import. And if you can write such
a wrapper, you could have it edit all the programs to use the "if
__name__ ..." scheme in a batch, and then generate a modified main
program to import/start the rewritten program.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread

Thread

Re: A thread import problem Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-07-22 23:40 -0400

csiph-web