Re: A thread import problem

Discussion in 'Python' started by Dennis Lee Bieber, Jul 23, 2012.

  1. On Sun, 22 Jul 2012 17:14:28 -0600, Bruce Sherwood
    <> declaimed the following in

    > On Sun, Jul 22, 2012 at 3:48 PM, Dennis Lee Bieber
    > <> wrote:
    > > On Sun, 22 Jul 2012 13:04:25 -0600, Bruce Sherwood
    > > <> 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://
    > >
    > > --
    > >

    > 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

    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
    Dennis Lee Bieber, Jul 23, 2012
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Stefan Seefeld
  2. per9000
    Magnus Lycka
    Feb 27, 2006
  3. Bruce Sherwood

    A thread import problem

    Bruce Sherwood, Jul 19, 2012, in forum: Python
    Bruce Sherwood
    Jul 19, 2012
  4. Dennis Lee Bieber

    Re: A thread import problem

    Dennis Lee Bieber, Jul 19, 2012, in forum: Python
    Dennis Lee Bieber
    Jul 19, 2012
  5. Dieter Maurer

    Re: A thread import problem

    Dieter Maurer, Jul 19, 2012, in forum: Python
    Dieter Maurer
    Jul 19, 2012

Share This Page