Mailing List Archive

> What are the thoughts on NumPy integration into the core?

he he - and while we are at it :-) mxDateTime would need to be a popular
choice for inclusion, and Guido has offered in-principle support for moving
some of the Win32 stuff into the core - particularly the Registry stuff and
the native Window Handle support...

How far do we go :-)

Personally, I would simply like to see the distutils SIG solve this problem
for us. (sure). Eg, the "build" or "install" process (depending on the
OS) could build a local HTML file with knowledge many "common" extensions -
a single click, and it is downloaded, configured and built. Oh well, back
to reality...

[.Which isnt to say I am opposed to NumPy and mxDateTime. Definately keen
on the win32 stuff tho :-]

Mark.

On Wed, 28 Apr 1999, Mark Hammond wrote:

> > What are the thoughts on NumPy integration into the core?
>
> he he - and while we are at it :-) mxDateTime would need to be a popular
> choice for inclusion, and Guido has offered in-principle support for moving
> some of the Win32 stuff into the core - particularly the Registry stuff and
> the native Window Handle support...

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. =)

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

--david

> 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.

Mark Hammond wrote:
>
> > What are the thoughts on NumPy integration into the core?
>
> he he - and while we are at it :-) mxDateTime would need to be a popular
> choice for inclusion, and Guido has offered in-principle support for moving
> some of the Win32 stuff into the core - particularly the Registry stuff and
> the native Window Handle support...
>
> How far do we go :-)
>
> Personally, I would simply like to see the distutils SIG solve this problem
> for us. (sure). Eg, the "build" or "install" process (depending on the
> OS) could build a local HTML file with knowledge many "common" extensions -
> a single click, and it is downloaded, configured and built. Oh well, back
> to reality...

You're talking about fast moving targets there... are you sure that
you want those in the standard distribution ?

Maybe we have two distributions: the standard one and a pro
edition with all the slick stuff included (together with a
proper setup script to get those references to external libs
and include files right).

Actually, this is something I've been wanting to do for nearly
a year now... just haven't found the time to really get things
the way I want them. It's a project called Python Power Tools
and includes many generic extensions (currently only ones that
don't rely on external libs).

If you're interested, have a look at an old version available at:

http://starship.skyport.net/~lemburg/PowerTools-0.2.zip

It includes the extensions BTree, mxDateTime, mxTools, mxStack,
Trie, avl and kjbuckets. NumPy should probably also be included.
The current setup uses a recursive Makefile approach (not too
elegant, but works). A distutils setup would be much better.

--
Marc-Andre Lemburg Y2000: 247 days left
---------------------------------------------------------------------
: Python Pages >>> http://starship.skyport.net/~lemburg/ :
---------------------------------------------------------

On 28 April 1999, Mark Hammond said:
> How far do we go :-)
>
> Personally, I would simply like to see the distutils SIG solve this problem
> for us. (sure). Eg, the "build" or "install" process (depending on the
> OS) could build a local HTML file with knowledge many "common" extensions -
> a single click, and it is downloaded, configured and built. Oh well, back
> to reality...

It's not impossible, it just takes a while. I think it took the Perl
community about three years to go from "hey! let's have a standard build
mechanism for modules!" to the point where I can install (almost) any
module from CPAN with one shell command:

perl -MCPAN -e 'install ("MIME::Base64");'

which is insanely cool. (It took about two minutes to do the above just
now; that included trying two CPAN mirrors that aren't being cooperative
this morning, finding one that was working, downloading the current
module list from it, determining that there is a more recent version
available than the one installed here, downloading it, unpacking it,
running "Makefile.PL" to generate the Makefile, running "make" [.which
compiles any extensions in the distribution, copies all the .pm files
around, and generates the documentation], "make test" [run the module's
self-test suite], and "make install" [install it in the "site-perl"
library directory]. Amount of user interaction required: typing the
above command line.)

It's *still* rough around the edges, though, especially when building a
new installation from scratch -- mainly because Perl doesn't ship with
ftp or http libraries, so the CPAN.pm module has to try downloading
stuff with lynx, ncftp, or plain ol' ftp until it has downloaded and
installed the libnet and libwww-perl distributions. That's one problem
we won't have with Python, at least. Oh yeah, and it all works *great*
under Unix... but the rest of the world lags behind.

Also, two major components of being able to do this -- the Perl Module
List and CPAN -- are still vapourware in Python-land. But hey, if we
can get to the "we *have* a standard build mechanism for modules!"
point, then all the rest becomes a lot more feasible.

Pep talk over...

Greg
--
Greg Ward - software developer gward@cnri.reston.va.us
Corporation for National Research Initiatives
1895 Preston White Drive voice: +1-703-620-8990
Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913

> [...] Guido has offered in-principle support for moving
> some of the Win32 stuff into the core - particularly the Registry stuff and
> the native Window Handle support...

I think it would be nice to put all the stuff that is shared between modules
(I think that's only PyWinTypes, but who am I to think I have a clue about the
windows port:-) into the core.

I just did the same for MacPython, and it makes life a whole lot easier.
--
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm