killing thread ?
jacob at cd.chalmers.se
Mon Jan 27 11:23:17 CET 2003
In article <7xd6mme5dn.fsf at ruckus.brouhaha.com>,
Paul Rubin <phr-n2003b at NOSPAMnightsong.com> wrote:
>Peter Hansen <peter at engcorp.com> writes:
>> It's not a question of right or wrong: Python was intended to be very
>> cross-platform, as opposed to many other languages which try to provide
>> support for every nuance of every different platform which results in a
>> situation in which programs are absolutely *not* cross-platform because
>> even relatively simple programs, e.g. those using threads, cannot run
>> the same on more than one supported platform.
>Deciding whether to use features that arespecific to a particular OS
>should be the prerogative of the application designer, not the
>programming language. The reason we have OS wars all the time and
>everyone has opinions about what OS is best, is that OS's are not all
>the same. And if your favorite OS has some advantage over other OS's,
>but Python won't let you use your OS's advantage to make your
>application better, that kind of defeats the idea of Python as a
>platform for writing the best applications that you can.
Local optimisation without regard to global optimisation is usually
a bad idea. You argue that reaping the benefits of being able to
use OS specific features is worth the price of not being able to run
your software on other platforms.
I think you should reconsider this argument, if you have ever used a
single part of the Python library, or somebody elses Python software.
It worked on your platform _because_ the Python philosophy is to be
As an aside, threading is not part of the Python language. You are free
to build your own thread library that is very platform specific. However,
it will be your design decision and your package to maintain.
>All kinds of stuff like process control, file i/o operations, etc.
>are OS dependent and Python supports OS specific calls to deal with
>those things. Why on earth should threads have to get a bigger dose
>of OS-independence religion than ioctl gets? This just baffles me.
You have things backwards. Ioctl is a deplorable example of when OS
independence was too hard to achieve. If it can reasonably be redone in
an OS independent way it should. The functionality itself is way too
important to rip out.
More information about the Python-list