[Python-Dev] numpy

[Mark Hammond]

> It may seem strange, but I'll argue for the win32 registry
> calls before
> the NumPy stuff.  That could be because I've looked at NumPy
> code and not
> the win32 code.  Not Jim's cleanest code. =)

he he - and I can even get out of the Win32 stuff - I wrote a string-only
first version, and Bill Tutt rehashed it into what it is today, handling
all the registry types.

OTOH, there could also be a case for moving "win32api" completely to "core
status" (whether that means truly core or simply a standard .pyd).  For
example, ntpath.py now has code that attempts to use
"win32api.GetFullPathName()".

The down-side is that win32api has nowhere near complete coverage, and is
really a mixed bag of bits and pieces.  Most later efforts where complete
API sets are given coverage have different names - eg, win32file has the
complete Win32 file API wrapped up - even if there are overlaps with
existing functions in win32api.

Im not sure what the answer is - my guess is a new core module with Win32
features deemed absolutely necessary for the core - stuff like the
registry, and a few assorted other functions, such as GetFullPathName, but
stopping well short of the full win32api set.

> Mark, can you describe 'native Window Handle' support?

Sure!  We have a very light-weight "handle" object, representing a Win32
handle.  It has no methods, and a single property for returning the
underlying win32 handle as an integer.  When the object destructs, it calls
"CloseHandle()".  Thats about it!

It has no methods, so is passed as an argument.  There has been no attempt
to implement things like "handle.Read()" to represent "ReadFile(handle,
...)".  There are 2 reasons for this:
1) Handles are fairly general purpose, and not restricted to IO operations.
A handle is also used to represent a Mutex/Semaphores and
threads/processes - certainly doesnt make sense to have a "Read()" method
for those handles.
2) IMO, this should be done at the .py level anyway.  The Win32 Handle
support is pure C++ at the moment.

A simple complication is that there are 3 types of handles in use at the
moment - those that call "CloseHandle", those that call "RegCloseHandle"
(registry handles) and a 3rd I cant recall.  This is currently implemented
using C++ inheritance.  But even if the current implementation is not
favoured, the object is so small that a rewrite would not be a problem.

And for those that can be bothered to read this far, some more background:
Some time ago, Greg and I decided to implement a "pywintypes" module.  This
defines what we considered "core types" for the Win32 world.  All our
extension modules (including win32api, COM; basically win32*.pyd) use this
module.  The objects it supports are: Unicode, Handles, Win32 Time, IIDs,
Overlapped IO objects, 3 NT security related objects and importantly a
standard Win32 exception and functions for filling it.

Moving the registry stuff is dependant on the core having the Exception,
Handle and Registry support (hence this discussion).  We have our own Time
object, but mxDateTime would be fine.  One day, we hope to remove this
pywintypes entirely, as the core will have it all :-)

Mark.