RE: [Python-Dev] Another 1.6 wish

My first Python-Dev post. :-)
We had some discussion a while back about enabling thread support by default, if the underlying OS supports it obviously.
What's the consensus about Python microthreads -- a likely candidate for incorporation in 1.6 (or later)? Also, we have a couple minor convenience functions for Python in an MSDEV environment, an exposure of OutputDebugString for writing to the DevStudio log window and a means of tripping DevStudio C/C++ layer breakpoints from Python code (currently experimental). The msvcrt module seems like a likely candidate for these, would these be welcome additions? Thanks, Jason Asbahr Origin Systems, Inc. jasbahr@origin.ea.com

On Fri, 19 Nov 1999, Asbahr, Jason wrote:
microthreads? eh?
Sure. I don't see why not. I know that I've use OutputDebugString a bazillion times from the Python layer. The breakpoint thingy... dunno, but I don't see a reason to exclude it. Cheers, -g -- Greg Stein, http://www.lyra.org/

These are both available in the win32api module. They dont really fit in the "msvcrt" module, as they are not part of the C runtime library, but the win32 API itself. This is really a pointer to the fact that some or all of the win32api should be moved into the core - registry access is the thing people most want, but there are plenty of other useful things that people reguarly use... Guido objects to the coding style, but hopefully that wont be a big issue. IMO, the coding style isnt "bad" - it is just more an "MS" flavour than a "Python" flavour - presumably people reading the code will have some experience with Windows, so it wont look completely foreign to them. The good thing about taking it "as-is" is that it has been fairly well bashed on over a few years, so is really quite stable. The final "coding style" issue is that there are no "doc strings" - all documentation is embedded in C comments, and extracted using a tool called "autoduck" (similar to "autodoc"). However, Im sure we can arrange something there, too. Mark.

That's a good summary of the status quo. I would appreciate it if win32all could become part of the core. However the coding style issues need to be addressed (I also believe that it needs to be compiled in C++ mode). One concern that Mark doesn't mention is that there are some safety issues -- you can abuse some of the calls to cause segfaults, whether intentional or by mistake, and that's not a good thing. --Guido van Rossum (home page: http://www.python.org/~guido/)

My first Python-Dev post. :-)
Welcome!
We had some discussion a while back about enabling thread support by default, if the underlying OS supports it obviously.
I agree with this. MacOS seems to be the only OS without threads these days.
What's the consensus about Python microthreads -- a likely candidate for incorporation in 1.6 (or later)?
What are microthreads? If you think about threads implemented in the Python VM instead of in the OS, forget it.
Sure -- send patches. --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum [guido@CNRI.Reston.VA.US] wrote:
I believe the new GUISI package has pthread-API compatible threads implemented, which talk to the underlying ThreadManager. With MacOSX being impending before 1.6 (i.e. early 2000), I'd say this is a good way to go. Threads are VERY useful for a lot of problem domains. Chris -- | Christopher Petrilli | petrilli@amber.org

What's GUISI? The son of GUSI? --Guido van Rossum (home page: http://www.python.org/~guido/)

I hadn't seen Mark Hammond's response -- I take it back. --Guido van Rossum (home page: http://www.python.org/~guido/)

On Fri, 19 Nov 1999, Asbahr, Jason wrote:
microthreads? eh?
Sure. I don't see why not. I know that I've use OutputDebugString a bazillion times from the Python layer. The breakpoint thingy... dunno, but I don't see a reason to exclude it. Cheers, -g -- Greg Stein, http://www.lyra.org/

These are both available in the win32api module. They dont really fit in the "msvcrt" module, as they are not part of the C runtime library, but the win32 API itself. This is really a pointer to the fact that some or all of the win32api should be moved into the core - registry access is the thing people most want, but there are plenty of other useful things that people reguarly use... Guido objects to the coding style, but hopefully that wont be a big issue. IMO, the coding style isnt "bad" - it is just more an "MS" flavour than a "Python" flavour - presumably people reading the code will have some experience with Windows, so it wont look completely foreign to them. The good thing about taking it "as-is" is that it has been fairly well bashed on over a few years, so is really quite stable. The final "coding style" issue is that there are no "doc strings" - all documentation is embedded in C comments, and extracted using a tool called "autoduck" (similar to "autodoc"). However, Im sure we can arrange something there, too. Mark.

That's a good summary of the status quo. I would appreciate it if win32all could become part of the core. However the coding style issues need to be addressed (I also believe that it needs to be compiled in C++ mode). One concern that Mark doesn't mention is that there are some safety issues -- you can abuse some of the calls to cause segfaults, whether intentional or by mistake, and that's not a good thing. --Guido van Rossum (home page: http://www.python.org/~guido/)

My first Python-Dev post. :-)
Welcome!
We had some discussion a while back about enabling thread support by default, if the underlying OS supports it obviously.
I agree with this. MacOS seems to be the only OS without threads these days.
What's the consensus about Python microthreads -- a likely candidate for incorporation in 1.6 (or later)?
What are microthreads? If you think about threads implemented in the Python VM instead of in the OS, forget it.
Sure -- send patches. --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum [guido@CNRI.Reston.VA.US] wrote:
I believe the new GUISI package has pthread-API compatible threads implemented, which talk to the underlying ThreadManager. With MacOSX being impending before 1.6 (i.e. early 2000), I'd say this is a good way to go. Threads are VERY useful for a lot of problem domains. Chris -- | Christopher Petrilli | petrilli@amber.org

What's GUISI? The son of GUSI? --Guido van Rossum (home page: http://www.python.org/~guido/)

I hadn't seen Mark Hammond's response -- I take it back. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (5)
-
Asbahr, Jason
-
Christopher Petrilli
-
Greg Stein
-
Guido van Rossum
-
Mark Hammond