Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!goblin1!goblin.stu.neva.ru!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Dennis Lee Bieber <wlfraed@ix.netcom.com>
Subject: Re: A thread import problem
Date: Sun, 22 Jul 2012 23:40:10 -0400
Organization: > Bestiaria Support Staff <
References: <87a9yt7bw6.fsf@handshake.de> <CA+WuaSc0Rm5s0CXsm7q7-gfyw+jQxpAGkuajpgFyoAHnTP12sQ@mail.gmail.com> <2u8m085co3j3n97jorkl04o5hr1orqb7la@invalid.netcom.com> <CA+WuaSde=GntxGMVTScOUw4_a+jqQS+nme0VpZVgH_219Qo9jA@mail.gmail.com> <5gfm08htgbrum782hfv5fqkb4084qra7vq@invalid.netcom.com> <CA+WuaScB1jycdBNPosEePGUX=8n80Wst3tGv672TK2FVq-KAig@mail.gmail.com> <jrso08pf109ki94vjtqfcdifhcl455cq54@invalid.netcom.com> <CA+WuaSd3yPY7-uwGq9_6FR8zDd9zbRmXX4bwVqLnv3z-eEhojw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.2450.1343014811.4697.python-list@python.org>
Lines: 92
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:25837

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/