Python 2.4 killing commercial Windows Python development ?

Discussion in 'Python' started by Michael Kearns, Apr 11, 2005.

  1. I've been using python to write a simple 'launcher' for one of our Java
    applications for quite a while now. I recently updated it to use python
    2.4, and all seemed well.

    Today, one of my colleagues noted that on her machine the launcher would
    complain it was missing a DLL - msvcr71.dll

    However, there's a very grey area concerning the redistribution of said DLL.

    If you've been keeping up with the dev list, and some other web
    discussions, you'll see that this has cropped up several times, but with
    no conclusion in a legal fashion other than 'investigate it on your own
    legal terms'.

    I'm now going to have step back to using 2.3 until this issue is solved,
    but judging by the way the dev list discussion just faded, I get the
    impression that it may be a long wait.

    I can't see how any company (or individual) can distribute an
    application written in python, and then 'frozen' (I used py2exe) in any
    way if they rely on the python24.dll that ships as standard. This is
    surely a step backwards in usability.

    I have no idea concerning the issues of rebuilding a different version
    of python24.dll to be linked against the common msvcr.dll or whatever,
    or changing the 'freeze' applications to do some magic, but I can't
    believe it should be down to the end user to jump through legal or
    compilation hoops when they're trying to use the language.

    Apologies if this seems more aggressive than I intended it to be - I'm
    just frustrated at having to stop following my language of choice for
    the foreseeable future so far as my work is concerned.

    Michael.
     
    Michael Kearns, Apr 11, 2005
    #1
    1. Advertising

  2. Michael Kearns <> writes:

    > I've been using python to write a simple 'launcher' for one of our
    > Java applications for quite a while now. I recently updated it to use
    > python 2.4, and all seemed well.
    >
    > Today, one of my colleagues noted that on her machine the launcher
    > would complain it was missing a DLL - msvcr71.dll
    >
    > However, there's a very grey area concerning the redistribution of said DLL.
    >
    > If you've been keeping up with the dev list, and some other web
    > discussions, you'll see that this has cropped up several times, but
    > with no conclusion in a legal fashion other than 'investigate it on
    > your own legal terms'.
    >
    > I'm now going to have step back to using 2.3 until this issue is
    > solved, but judging by the way the dev list discussion just faded, I
    > get the impression that it may be a long wait.
    >
    > I can't see how any company (or individual) can distribute an
    > application written in python, and then 'frozen' (I used py2exe) in
    > any way if they rely on the python24.dll that ships as standard. This
    > is surely a step backwards in usability.


    For commercial development, it should not be a problem to buy a license
    for MSVC 7.1, which gives you the right to distribute msvcrt71.dll.

    And maybe that's the reason that few people care about this issue?

    Thomas
     
    Thomas Heller, Apr 11, 2005
    #2
    1. Advertising

  3. Thomas Heller wrote:

    > For commercial development, it should not be a problem to buy a license
    > for MSVC 7.1, which gives you the right to distribute msvcrt71.dll.
    >
    > And maybe that's the reason that few people care about this issue?


    Hi Thomas,

    There are a few problems with this as I see it. In theory, the 'cost' of
    MSVC 7.1 shouldn't be a problem for a big organisation. However, I
    wouldn't expect to have to go and buy it purely because I'm developing
    (perhaps) a shareware application using python - this isn't my case, but
    I wasn't looking at it from just a big organisation perspective.

    Also, I don't believe that just 'owning' MSVC 7.1 is enough. From
    cursory glances at the various redist files, I would also have to ship
    the EULA, and as an end-user (of python) I can't just redistribute the
    files - perhaps I could write a place holder application in MSVC to
    suggest that I was no longer an end-user, but this seems ridiculous as a
    workaround.

    There even seem to be 'exclude' clauses to redistribution concerning
    open-source material, but IANAL and ran from the various paragraphs.

    I would like to think that python would encourage as many folk as
    possible to use the language wherever it fits best (and perhaps even
    beyond) and yet this is going in the opposite direction.

    Would it be so difficult for a 'no legalese attached' version to be
    provided on windows, or at the very least, some kind of statement
    regarding what is and isn't allowed ? There seems nothing within the
    python distribution stating the redistribution rights of the dll
    (correct me if I'm wrong) which already seems contrary to the MS
    requirements.

    As much as I'd like to continue using it, because of the vague legal
    situation, I can't, and that's unfortunate.

    Michael.
     
    Michael Kearns, Apr 11, 2005
    #3
  4. Michael Kearns

    Tim Peters Guest

    [Michael Kearns]
    > ...
    > Also, I don't believe that just 'owning' MSVC 7.1 is enough. From
    > cursory glances at the various redist files, I would also have to ship
    > the EULA, and as an end-user (of python) I can't just redistribute the
    > files - perhaps I could write a place holder application in MSVC to
    > suggest that I was no longer an end-user, but this seems ridiculous as a
    > workaround.
    >
    > There even seem to be 'exclude' clauses to redistribution concerning
    > open-source material, but IANAL and ran from the various paragraphs.
    >
    > I would like to think that python would encourage as many folk as
    > possible to use the language wherever it fits best (and perhaps even
    > beyond) and yet this is going in the opposite direction.
    >
    > Would it be so difficult for a 'no legalese attached' version to be
    > provided on windows, or at the very least, some kind of statement
    > regarding what is and isn't allowed ?


    I think it would be difficult. "We" (the Python developers) didn't
    write Microsoft's license, have no special insight wrt it, and aren't
    lawyers either. If you want legally binding clarifications or
    exemptions, I think they have to come from Microsoft (it's their
    license).

    It would be cool if commercial users got together, pursued this with
    MS, and shared what they learned. Of course it would also be cool if
    someone with no commercial MS interests did so, but the chance of that
    happening seems nil.

    > There seems nothing within the python distribution stating the redistribution
    > rights of the dll (correct me if I'm wrong) which already seems contrary to the
    > MS requirements.


    That's possible too. MS hasn't complained to the PSF yet, but that's
    no guarantee they won't.

    > As much as I'd like to continue using it, because of the vague legal
    > situation, I can't, and that's unfortunate.


    Maybe the Python Business Forum could take this on? I don't know
    whether they're still active, and their site isn't working today (at
    least not for me):

    http://www.python-in-business.org/

    If someone(s) volunteered to do the work, it's also possible (not
    certain) that the PSF would pay for lawyer time.
     
    Tim Peters, Apr 11, 2005
    #4
  5. Michael Kearns

    Nemesis Guest

    Mentre io pensavo ad una intro simpatica "Michael Kearns" scriveva:

    > I've been using python to write a simple 'launcher' for one of our Java
    > applications for quite a while now. I recently updated it to use python
    > 2.4, and all seemed well.
    > Today, one of my colleagues noted that on her machine the launcher would
    > complain it was missing a DLL - msvcr71.dll


    I have the same problem. But I have a doubt, does Python installer ship
    this dll?
    What happens if I try to install Python2.4 on a system wich doesn't have
    the dll?

    --
    The complete lack of evidence is the surest sign that the conspiracy is
    working.

    |\ | |HomePage : http://nem01.altervista.org
    | \|emesis |XPN (my nr): http://xpn.altervista.org
     
    Nemesis, Apr 11, 2005
    #5
  6. Hi !

    This DLL come also with MS-JVM engine, who is free. Therefore...

    --
    Michel Claveau
     
    Do Re Mi chel La Si Do, Apr 11, 2005
    #6
  7. And, also, with dotNET-framework
     
    Do Re Mi chel La Si Do, Apr 11, 2005
    #7
  8. Michael Kearns wrote:
    > There are a few problems with this as I see it. In theory, the 'cost' of
    > MSVC 7.1 shouldn't be a problem for a big organisation. However, I
    > wouldn't expect to have to go and buy it purely because I'm developing
    > (perhaps) a shareware application using python - this isn't my case, but
    > I wasn't looking at it from just a big organisation perspective.


    For developers that need msvcr71.dll on the target system which don't
    have a license to distribute it, the solution is simple: they just need
    to advise their users to install python-2.4.1.msi. This comes with
    msvcr71.dll included.

    Regards,
    Martin
     
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Apr 11, 2005
    #8
  9. Nemesis wrote:
    > I have the same problem. But I have a doubt, does Python installer ship
    > this dll?


    It sure does.

    > What happens if I try to install Python2.4 on a system wich doesn't have
    > the dll?


    It will just work. Python installs the DLL if it is missing, and leaves
    it alone (just incrementing the refcount) if it is present on the target
    system.

    Regards,
    Martin
     
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Apr 11, 2005
    #9
  10. Michael Kearns

    Peter Hansen Guest

    Martin v. Löwis wrote:
    > Michael Kearns wrote:
    >>There are a few problems with this as I see it. In theory, the 'cost' of
    >>MSVC 7.1 shouldn't be a problem for a big organisation. However, I
    >>wouldn't expect to have to go and buy it purely because I'm developing
    >>(perhaps) a shareware application using python - this isn't my case, but
    >>I wasn't looking at it from just a big organisation perspective.

    >
    > For developers that need msvcr71.dll on the target system which don't
    > have a license to distribute it, the solution is simple: they just need
    > to advise their users to install python-2.4.1.msi. This comes with
    > msvcr71.dll included.


    I believe there are no restrictions on us redistributing
    python-2.4.1.msi either, which would suggest that it
    could simply be included in an installer package, and
    perhaps the relevant DLLs could even be extracted from
    the msi file without having to install it... I seem
    to recall someone ;-) was making progress on an msi
    package for Python which might be capable of this
    too.

    Of course then you'd need Python installed already in
    order to install your application. On the other hand,
    you could always include a copy of Python 2.3 as well,
    and use that to extract the DLLs from the MSI.

    Or other equally insane approaches ...

    -Peter
     
    Peter Hansen, Apr 12, 2005
    #10
  11. Martin v. Löwis wrote:

    > For developers that need msvcr71.dll on the target system which don't
    > have a license to distribute it, the solution is simple: they just need
    > to advise their users to install python-2.4.1.msi. This comes with
    > msvcr71.dll included.


    I understand this, and it's obviously a solution. Unfortunately it
    defeats the whole point of me 'freezing' my code in the first place.

    The main feature (for me) of the way I could use this, was to create a
    simple Java launcher that didn't require the user to install anything
    extra, or end up with a whole stack of unused data on their machine.

    They would see a .exe file, a dll and a pyd, and then the actual
    application files, and that was it. It may be fine for a 'knowledgeable'
    user to install python etc., but not for everyone.

    Michael.
     
    Michael Kearns, Apr 12, 2005
    #11
  12. Do Re Mi chel La Si Do wrote:
    > Hi !
    >
    > This DLL come also with MS-JVM engine, who is free. Therefore...
    >


    This is very true (and the .NET suggestion as well). However, why should
    I require an end-user to install MS-JVM or the .NET framework, purely
    for a simple little launcher application ?

    The main application it launches is Java, but there's no way it would
    run on the MS-JVM, and .NET just gives a load more technology that we
    don't really need (and is a bigger install than the entire application).

    Michael.
     
    Michael Kearns, Apr 12, 2005
    #12
  13. Martin v. Löwis wrote:

    >> What happens if I try to install Python2.4 on a system wich doesn't have
    >> the dll?

    >
    > It will just work. Python installs the DLL if it is missing, and leaves
    > it alone (just incrementing the refcount) if it is present on the target
    > system.


    installs it where? the MS docs seem to indicate that they want you to install
    it in the program directory, rather than in a "shared" location:

    http://support.microsoft.com/default.aspx?scid=kb;en-us;326922

    </F>
     
    Fredrik Lundh, Apr 12, 2005
    #13
  14. Michael Kearns

    Jeff Epler Guest

    Why won't someone step up and make use of the Free tools (was Re:python 2.4 killing commercial Windows Python development ?)

    I'm sorry that this is going to come out sounding like a flame, but it
    seems to me that there today only a few technical problems remaining
    with Python when built with mingw32.

    If one of the people who has expressed such deep concern about this
    "msvcr71.dll" problem would simply install the Free tools and start
    putting patches on sourceforge, it's quite possible that for the next
    2.4.x release the mingw32 "port" could be a first-rate one, and suitable
    for the uses that the posters in this thread have mentioned.

    Since mingw32 is Free (gpl and other licenses for tools, public domain
    libraries and copyrighted headers with "no restrictions for programs"
    built using the headers) anyone can install and use these tools and
    mingw creates no new problems with distribution of the resulting binary,
    whether the final product is Free or proprietary.

    (Admittedly I don't know anything about whether "win32all" builds under
    mingw32, and it's not clear whether binary compatibility with extensions
    built by microsoft compilers is an easy goal either)

    http://www.mingw.org/

    Jeff

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.1 (GNU/Linux)

    iD8DBQFCW9BaJd01MZaTXX0RAjSUAJ9rQ9iPncKGReearcIiAGaiE2pVCgCfbx39
    eRPFXirdDedIlhyhXrs42RU=
    =QgCW
    -----END PGP SIGNATURE-----
     
    Jeff Epler, Apr 12, 2005
    #14
  15. Michael Kearns

    Terry Reedy Guest

    "Michael Kearns" <> wrote in message
    news:425b8948$0$38045$...
    >I understand this, and it's obviously a solution. Unfortunately it defeats
    >the whole point of me 'freezing' my code in the first place.


    >The main feature (for me) of the way I could use this, was to create a
    >simple Java launcher that didn't require the user to install anything
    >extra, or end up with a whole stack of unused data on their machine.


    I guess I don't understand some people's determination to not have users
    install fully useable Python on their Windows machines. Doing so seems no
    different to me than having to install (or upgrade) Shockwave, or Apple's
    Quicksomething for Windows (not used so much anymore), or RealPlayer, or
    the lastest upgrade for DirectX, or DivX, or a zip decoder, or any other
    3rd party software, to run .xxx files or specialized .exe programs. (And I
    left out the most direct analogy of a java system.)

    In other words, it seems to me that most Windows users should be familiar
    with the idea of having to install a player or platform to run something
    built on top of that player or platform. Bundling a private Python
    interpreter with every Python script is much like bundling a private
    Shockwave player with every Schockwave script. I think most people would
    prefer having one copy of each.

    To put it another way, needing a Python interpreter to run .py files is no
    different from, for instance, needing a movie player to run .mpg files, and
    all Windows users are or need to become familiar with that general concept.

    Also, I think it a bit 'anti-social' to hide usage of Python. If all
    Python Windows programs ran with a normal, communally installed Python,
    then users would gradually get the idea that having Python installed is
    much like having Shockwave and other utility platforms installed, and that
    is is part of a 'fully loaded' Windows system to have a .py player
    installed.

    If there is something about the default install of Python on Windows that
    makes it less desireable or less easy than other platforms, then maybe that
    can be fixed. To make installation easier, maybe someone could write a
    small .exe that could be frozen with scripts or run with installers and
    that would detect the presence/absence of the needed Python version and
    offer an auto download and install if needed.

    At least one thing in Python's favor is the lack of having to 'register'
    before downloading (or after installation) and the ability to redistribute
    the installer free and without special license.

    Terry J. Reedy
     
    Terry Reedy, Apr 12, 2005
    #15
  16. "Terry Reedy" <> writes:

    [...]
    > Also, I think it a bit 'anti-social' to hide usage of Python. If all
    > Python Windows programs ran with a normal, communally installed Python,
    > then users would gradually get the idea that having Python installed is
    > much like having Shockwave and other utility platforms installed, and that
    > is is part of a 'fully loaded' Windows system to have a .py player
    > installed.


    Isn't it a bit harsh to call this 'anti-social'?

    >
    > If there is something about the default install of Python on Windows that
    > makes it less desireable or less easy than other platforms, then maybe that
    > can be fixed. To make installation easier, maybe someone could write a
    > small .exe that could be frozen with scripts or run with installers and
    > that would detect the presence/absence of the needed Python version and
    > offer an auto download and install if needed.


    Sure. Someone.

    >
    > At least one thing in Python's favor is the lack of having to 'register'
    > before downloading (or after installation) and the ability to redistribute
    > the installer free and without special license.


    Thomas
     
    Thomas Heller, Apr 12, 2005
    #16
  17. Michael Kearns

    Dave Brueck Guest

    Terry Reedy wrote:
    > I guess I don't understand some people's determination to not have users
    > install fully useable Python on their Windows machines.

    [snip]
    > To put it another way, needing a Python interpreter to run .py files is no
    > different from, for instance, needing a movie player to run .mpg files, and
    > all Windows users are or need to become familiar with that general concept.
    >
    > Also, I think it a bit 'anti-social' to hide usage of Python. If all
    > Python Windows programs ran with a normal, communally installed Python,
    > then users would gradually get the idea that having Python installed is
    > much like having Shockwave and other utility platforms installed, and that
    > is is part of a 'fully loaded' Windows system to have a .py player
    > installed.
    >
    > If there is something about the default install of Python on Windows that
    > makes it less desireable or less easy than other platforms, then maybe that
    > can be fixed. To make installation easier, maybe someone could write a
    > small .exe that could be frozen with scripts or run with installers and
    > that would detect the presence/absence of the needed Python version and
    > offer an auto download and install if needed.


    I mostly agree with the sentiment, but it does break down a little in practice.
    At least currently it does - like you said, this is fixable, but nobody has
    signed up to fix it yet.

    The main thing that's needed is a zero-input Python distribution - a Python
    runtime, if you will - that (1) gets installed to a "good" place (2) does so
    without asking the user to do anything, (3) can coexist with different versions
    of the runtime, and (4) is easily detectable by applications wanting to use it.

    One other minor component is a small launcher executable, because on Windows
    it's non-trivial to find out which "python.exe" in the task manager is running
    which Python script. Anyway, each app would have a small launcher that
    bootstraps the actual Python script[1]. (Or, if there's some way to trick the
    task manager into displaying something besides "python.exe", that'd work too)

    In order to "fit" into the expectations of a typical Windows user, an
    application installer needs the ability to check for the presence of a
    particular version of the Python runtime, and then install it if it's not
    present, and do so without asking the user to do anything.

    With that much in place, a lot of the need for freezing Python apps goes away
    (definitely not all of it, but a lot of it). Here's stuff that still needs to be
    considered though:

    1) A way for apps to specify their compatibility with different versions of the
    runtime - "I work with pyrt2.3.3 through 2.4.1"

    2) A way for apps to register their dependency on that runtime, so that if the
    user uninstalls it, there is at least an indication of what programs might break.

    3) (this is a nice-to-have, but not 100% required) A way to download additional
    libraries once and use them for multiple programs, e.g. the installer could see
    if ctypes is present, and if not, go get it. Later programs would take advantage
    of it already being installed. Like I said, not a 100% requirement, and some of
    the ongoing work with code CPAN-like code repositories would shoehorn into this.

    4) The security implications, e.g. an innocent app installs pywin32 and enables
    Python client-side scripting in Internet Explorer, and later this is used as a
    big door for malicious users to use.

    Most of these tasks don't require a lot of work; indeed this has been on my "one
    of these days" lists for awhile. The main reasons it hasn't been done yet:

    1) The code freezing tools like py2exe are *very* good and convenient
    (especially since loading code from zip archives was added - even if you include
    all of Python, it's only a few files on disk, and now they're all in the same
    directory)

    2) Storage space and download speeds continue to increase at a rate much faster
    than the rate at which the size of Python is growing - a download of a few MB
    isn't too bad these days, who cares if your app takes 4MB on disk, and so what
    if it doesn't fit on a floppy, for example.

    3) As soon as you get started on such a project, almost immediately you will be
    overwhelmed with a desire to create a CPAN-like system while you're at it, at
    which point your project's status will shift from "making good progress!" to "in
    quagmire, developers MIA". :)

    -Dave

    [1] I built a hacky one of these launcher exe's for one project, and it was
    fairly reusable for apps in the same vein. Basically, the exe would would look
    to see what its name was, and then load a Python module of the same name. So if
    you have MyGame.py, you'd just take the generic launcher.exe, copy it to the
    same directory as your .py files, and rename it to MyGame.exe. On launch, it'd
    load the interpreter, load MyGame.py, and pass it the command-line args.
     
    Dave Brueck, Apr 12, 2005
    #17
  18. Dave Brueck <> writes:

    > Terry Reedy wrote:
    >> If there is something about the default install of Python on Windows
    >> that makes it less desireable or less easy than other platforms,
    >> then maybe that can be fixed. To make installation easier, maybe
    >> someone could write a small .exe that could be frozen with scripts
    >> or run with installers and that would detect the presence/absence of
    >> the needed Python version and offer an auto download and install if
    >> needed.

    >
    > I mostly agree with the sentiment, but it does break down a little in
    > practice. At least currently it does - like you said, this is fixable,
    > but nobody has signed up to fix it yet.
    >
    > The main thing that's needed is a zero-input Python distribution - a
    > Python runtime, if you will - that (1) gets installed to a "good"
    > place (2) does so without asking the user to do anything, (3) can
    > coexist with different versions of the runtime, and (4) is easily
    > detectable by applications wanting to use it.


    The effbot.exe platform (or how it's called) ?

    > One other minor component is a small launcher executable, because on
    > Windows it's non-trivial to find out which "python.exe" in the task
    > manager is running which Python script. Anyway, each app would have a
    > small launcher that bootstraps the actual Python script[1]. (Or, if
    > there's some way to trick the task manager into displaying something
    > besides "python.exe", that'd work too)


    exemaker?

    Thomas
     
    Thomas Heller, Apr 12, 2005
    #18
  19. Michael Kearns

    Dave Brueck Guest

    Thomas Heller wrote:
    > Dave Brueck <> writes:
    >>Terry Reedy wrote:
    >>>If there is something about the default install of Python on Windows
    >>>that makes it less desireable or less easy than other platforms,
    >>>then maybe that can be fixed. To make installation easier, maybe
    >>>someone could write a small .exe that could be frozen with scripts
    >>>or run with installers and that would detect the presence/absence of
    >>>the needed Python version and offer an auto download and install if
    >>>needed.

    >>
    >>I mostly agree with the sentiment, but it does break down a little in
    >>practice. At least currently it does - like you said, this is fixable,
    >>but nobody has signed up to fix it yet.
    >>
    >>The main thing that's needed is a zero-input Python distribution - a
    >>Python runtime, if you will - that (1) gets installed to a "good"
    >>place (2) does so without asking the user to do anything, (3) can
    >>coexist with different versions of the runtime, and (4) is easily
    >>detectable by applications wanting to use it.

    >
    >
    > The effbot.exe platform (or how it's called) ?


    Yep - something along those lines, plus some docs for app developers. I don't
    know if it installs all the stdlib, or just what effbot apps need, but I assume
    the former.

    >>One other minor component is a small launcher executable, because on
    >>Windows it's non-trivial to find out which "python.exe" in the task
    >>manager is running which Python script. Anyway, each app would have a
    >>small launcher that bootstraps the actual Python script[1]. (Or, if
    >>there's some way to trick the task manager into displaying something
    >>besides "python.exe", that'd work too)

    >
    >
    > exemaker?


    Something similar to that, yes. You'd need an option to generate a console
    launcher or a Windows app launcher (maybe his latest version already has this?),
    and a way to figure out which version of the runtime to use (rather than specify
    the path ahead of time, you'd specify version requirements, and then at runtime
    use registry entries to figure out where that runtime is), but the general idea
    is the same.

    -Dave
     
    Dave Brueck, Apr 12, 2005
    #19
  20. Michael Kearns

    Nemesis Guest

    Mentre io pensavo ad una intro simpatica "Martin v. Löwis" scriveva:

    >> What happens if I try to install Python2.4 on a system wich doesn't have
    >> the dll?

    > It will just work. Python installs the DLL if it is missing, and leaves
    > it alone (just incrementing the refcount) if it is present on the target
    > system.


    OK, so the python installer _does_ ship this dll. So also the win
    installer has the redistribution problem, or does they pay for
    redistributing msvcr71.dll?

    --
    Computers follow your orders, not your intentions.

    |\ | |HomePage : http://nem01.altervista.org
    | \|emesis |XPN (my nr): http://xpn.altervista.org
     
    Nemesis, Apr 12, 2005
    #20
    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. Replies:
    0
    Views:
    509
  2. Sting

    killing a process in ms windows - newbie

    Sting, Dec 28, 2003, in forum: C Programming
    Replies:
    2
    Views:
    345
    Richard Bos
    Dec 29, 2003
  3. Stephen Boulet

    killing a process in windows

    Stephen Boulet, Oct 17, 2003, in forum: Python
    Replies:
    1
    Views:
    353
    Stephen Boulet
    Oct 17, 2003
  4. Tony Meyer
    Replies:
    8
    Views:
    543
    Robin Becker
    Apr 13, 2005
  5. Don Garrett

    Killing threads during development.

    Don Garrett, Jun 5, 2005, in forum: Python
    Replies:
    0
    Views:
    320
    Don Garrett
    Jun 5, 2005
Loading...

Share This Page