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
    gmane.comp.python.general:

    > 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://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
    HTTP://wlfraed.home.netcom.com/
    Dennis Lee Bieber, Jul 23, 2012
    #1
    1. Advertising

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
    Replies:
    3
    Views:
    949
  2. per9000
    Replies:
    7
    Views:
    398
    Magnus Lycka
    Feb 27, 2006
  3. Bruce Sherwood

    A thread import problem

    Bruce Sherwood, Jul 19, 2012, in forum: Python
    Replies:
    0
    Views:
    150
    Bruce Sherwood
    Jul 19, 2012
  4. Dennis Lee Bieber

    Re: A thread import problem

    Dennis Lee Bieber, Jul 19, 2012, in forum: Python
    Replies:
    0
    Views:
    166
    Dennis Lee Bieber
    Jul 19, 2012
  5. Dieter Maurer

    Re: A thread import problem

    Dieter Maurer, Jul 19, 2012, in forum: Python
    Replies:
    0
    Views:
    139
    Dieter Maurer
    Jul 19, 2012
Loading...

Share This Page