Time to bundle PythonWin

[Dave Benjamin]

Martin v. Löwis wrote:
> Dave Benjamin wrote:
>> Why is PythonWin (win32all) still a separate download from a third
>> party? Is it legal, technical, or what? I think it's about time it be
>> part of the standard distribution.
> 
> Both legal and technical. The PythonWin author and maintainer (Mark
> Hammond) hasn't contributed this package for inclusion into Python.
> Without him explicitly saying that he wants that to happen, and prefers
> that over maintaining it outside Python himself, there is no way it
> could ever get included. This is a basic rule of politeness in open
> source software: don't fork, not even if you are legally allowed to.
> [of course, forks happen, typically because people don't consider
>  it important enough to be polite to the original author]

Sure. I wasn't proposing that this be done behind Mark's back. I wasn't 
even proposing a fork; rather, just two installers bundled into one. The 
user, upon running the .msi file, would simply be asked if they'd like 
PythonWin also. PythonWin could be automatically combined into the 
installer by downloading the latest version from SourceForge, perhaps.

> Now, if Mark did indeed offer it for inclusion, I would request (and
> also work on if I find the time) that the structure of these libraries
> is revised. I know that the current structure tries to be "natural"
> in some sense, but I find the assignment of API functions to modules
> quite arbitrary. I also think that some of the API functions should
> be replaced with their *Ex versions that Microsoft added over time.

Well, I'm sure the structure could be improved, but there's really 
nothing else quite like PythonWin out there. And I could think of parts 
of Python's standard library that evolved organically (os.popen2 thru 12 
comes to mind ;-) ) which could stand some reorganization. But anyway, I 
digress...

> Coming back to organizational issues: it would surely help if people
> would actively contribute to PythonWin. I believe this still is
> primarily a one-man show, and that Mark does an excellent job should
> not be an excuse for you to not contribute.

If only I had his expertise on the win32 API...

>> There are many useful things that you ought to be able to do without
>> downloading third-party libraries. Terminating a process, for example.
> 
> You can use subprocess.TerminateProcess for that (in some limited way).

Good to know, although this requires Python 2.5. I'm getting rather 
excited about Python 2.5... looks like a lot of useful new tools are in 
the pipeline.

>> Communicating with other applications via a standard, common protocol
>> (COM). We demand these things from our UNIX environments--why do we
>> tolerate their omission on the Windows platform?
> 
> We tolerate them because they aren't omitted. They are readily
> available, and we are all lazy enough to never do more than just
> post to a newsgroup complaining about it.

Well, good, at least I'm not the only lazy complainer around here. =)

>> It's time to bundle PythonWin.
> 
> So go and work on that.

Nah. Sounds like the better option is to wait for ctypes in 2.5...

Dave