Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: A thread import problem

Reply
Thread Tools

Re: A thread import problem

 
 
Dennis Lee Bieber
Guest
Posts: n/a
 
      07-23-2012
On Sun, 22 Jul 2012 17:14:28 -0600, Bruce Sherwood
<(E-Mail Removed)> declaimed the following in
gmane.comp.python.general:

> On Sun, Jul 22, 2012 at 3:48 PM, Dennis Lee Bieber
> <(E-Mail Removed)> wrote:
> > On Sun, 22 Jul 2012 13:04:25 -0600, Bruce Sherwood
> > <(E-Mail Removed)> 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
> > http://www.velocityreviews.com/forums/(E-Mail Removed) 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
(E-Mail Removed) HTTP://wlfraed.home.netcom.com/

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: A thread import problem Dieter Maurer Python 0 07-19-2012 08:31 AM
Re: A thread import problem Dennis Lee Bieber Python 0 07-19-2012 12:47 AM
A thread import problem Bruce Sherwood Python 0 07-18-2012 11:03 PM
problem(s) with import from parent dir: "from ../brave.py import sir_robin" per9000 Python 7 02-27-2006 06:36 PM
Problem with import "from omniORB import CORBA, PortableServer" Stefan Seefeld Python 3 04-11-2005 08:54 PM



Advertisments