j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
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 :-)