Re: A thread import problem

Discussion in 'Python' started by Bruce Sherwood, Jul 23, 2012.

  1. 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.

    Bruce Sherwood
    Bruce Sherwood, 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