Time to bundle PythonWin

[Dave Benjamin]

Hey folks,

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.

There are many useful things that you ought to be able to do without
downloading third-party libraries. Terminating a process, for example.
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?

Mac libraries are bundled with Python's *standard library*. I'm not even
advocating merging the win32 extensions with the standard library. All I'm
saying is that when you install Python on Windows, it should ask you if
you want to install PythonWin too, and that this option be selected by
default.

I write applications that use COM and Tkinter to automate basic office
tasks. My users are thankfully benevolent enough to download and install
Python on their own. They don't know what PythonWin is, they aren't
remembering it, and frankly, I don't think it should be their concern.

It's time to bundle PythonWin.

 

[Robert Hicks]

No it isn't. It is a Windows only package. It needs to stay a separate
download.

Robert

 

[Dave Benjamin]

No it isn't. It is a Windows only package. It needs to stay a separate
download.

The Windows installer for Python is an MSI file. It's already Windows
only.

Dave

 

[John Bokma]

No it isn't.

Learn to quote when you use Google's Usenet garbage.

 

[Carl Banks]

No it isn't. It is a Windows only package. It needs to stay a separate
download.

The latest Python Library Reference has a section called "MS Windows
Specific Services", where it has several packages that work only on
Windows. There's also a section for SGI IRIX modules, and IRIX support
is scheduled to be dropped in Python 3000. There might be a good
reason why win32 isn't in Python base distro, but that it's
Windows-only isn't it.


Carl Banks

 

[Ten]

Hey folks,

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.

There are many useful things that you ought to be able to do without
downloading third-party libraries. Terminating a process, for example.
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?

There's a lot of omission on the windows platform, and that ain't python or
win32all's fault.

Mac libraries are bundled with Python's *standard library*. I'm not even
advocating merging the win32 extensions with the standard library. All I'm
saying is that when you install Python on Windows, it should ask you if
you want to install PythonWin too, and that this option be selected by
default.

I write applications that use COM and Tkinter to automate basic office
tasks. My users are thankfully benevolent enough to download and install
Python on their own. They don't know what PythonWin is, they aren't
remembering it, and frankly, I don't think it should be their concern.

Respectfully, that sounds like a reason for *you* to bundle pythonwin (and
python, to be honest ), not a reason for everyone else to have to download
an extra 40-50% of potentially superfluous cruft with their standard python
setup.

In more general terms I can see why it would be useful to some windows people
to have more winapi stuff available. I can still think of quite a few things
I'd rather be spending that extra download time on myself, though, like a
sexed-up tkinter or maybe even a new gui toolkit.

Still, it's not an either/or choice, I suppose.

 

[Ravi Teja]

I write applications that use COM and Tkinter to automate basic office

tasks. My users are thankfully benevolent enough to download and install
Python on their own. They don't know what PythonWin is, they aren't
remembering it, and frankly, I don't think it should be their concern.

It's time to bundle PythonWin.

Someone already has.
http://www.activestate.com/Products/ActivePython/

Mac libraries are bundled with Python's *standard library*.

Are they? Only the documentation stubs are (in ActivePython anyway). It
would be quite a feat to compile Mac libraries on Windows to distribute
;-).

 

[Alex Martelli]

It's time to bundle PythonWin.

No: the Python Standard Distribution, in 2.5, includes instead ctypes,
which is lower-level than PythonWin but more general (exists for other
platforms, lets you call other DLLs on Windows and not just those
wrapped for you by the author).


Alex

 

[Dave Benjamin]

No: the Python Standard Distribution, in 2.5, includes instead ctypes,
which is lower-level than PythonWin but more general (exists for other
platforms, lets you call other DLLs on Windows and not just those
wrapped for you by the author).

I didn't realize you could do COM with ctypes. Thanks for the tip! Are
there any caveats to this approach?

Dave

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

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]

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.

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.

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

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.

It's time to bundle PythonWin.

So go and work on that.

Regards,
Martin

 

[jUrner]

The ctypes.com package is no longer part of ctypes.
It has been split by Thomas Heller into a separate package comtypes.
See: http://sourceforge.net/projects/comtypes/

Still in its childhood but as easy as com can get, I guess, way easier
and better than pythonWin at least.

Juergen

 

[Dave Benjamin]

Respectfully, that sounds like a reason for *you* to bundle pythonwin (and
python, to be honest ), not a reason for everyone else to have to download
an extra 40-50% of potentially superfluous cruft with their standard python
setup.

Certainly, I could bundle Python and PythonWin myself. I'll even admit
that my little office utilities would be better distributed as frozen
..exe files with all the necessary libraries bundled inside. But my
original problem as stated was this:

1. I release a Python script (a .py file)
2. My user upgrades or switches computers
3. They (logically) download and install Python
4. My script still doesn't work
5. They ask me for help

At this point, I dig through four or five web sites to find where
PythonWin is hosted these days, and it's obvious that my user never
would have guessed to download it, or found the right place to retrieve
it. If the windows installer for Python came with PythonWin, they might
not have needed my help at all.

I realize that other people's needs aren't the same as mine, but this
scenario isn't contrived. This has happened numerous times. Bundling
PythonWin myself wouldn't solve this particular problem as stated.

In more general terms I can see why it would be useful to some windows people
to have more winapi stuff available. I can still think of quite a few things
I'd rather be spending that extra download time on myself, though, like a
sexed-up tkinter or maybe even a new gui toolkit.

I'd happily download a larger installer for any or all of these things.
In the time it took me to write this, I'd probably already have finished
the download anyway.

Still, it's not an either/or choice, I suppose.

Yep. =)

Cheers,
Dave

 

[Dave Benjamin]

The ctypes.com package is no longer part of ctypes.
It has been split by Thomas Heller into a separate package comtypes.
See: http://sourceforge.net/projects/comtypes/

Still in its childhood but as easy as com can get, I guess, way easier
and better than pythonWin at least.

What makes you say it's way easier? PythonWin is pretty darn easy, from
my experience.

If ctypes is going to be standard, and ctypes.com is pure-Python, I
really have no reason left to complain. I do have to rewrite some
scripts, but this isn't a big deal.

Dave

 

[Dave Benjamin]

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

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.

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

So go and work on that.

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

Dave

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

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.

That is technologically challenging. Contributions are welcome.

Regards,
Martin

 

[Tim N. van der Leeuw]

Learn to quote when you use Google's Usenet garbage.

I don't know why you consider it 'garbage', using it myself for this
'contribution', but quoting isn't hard using google groups. Just
clicking the right links instead of the 'reply' link beneath the
message.

On-Topic: I'd welcome PythonWin added to the Python Windows MSI
installer too, for purposes similar to the O-Ps.
Do not possess the necessary skill to write patches, but still voting
in favor.

--Tim

 

[Steve Holden]

Hey folks,

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.

Something that the other responders seem to have ignored is the
separation of development of the two systems. If Python for Windows were
to bundle win32all then there'd be less chance of Mark Hammond releasing
bugfixes separately from the Python distribution, and he would have to
synchronise his release cycles with those of the Python core.

It can be done (witness the forthcoming introduction of elementtree as a
standard library module), but I see little benefit in this case,
especially as there's little evidence that the majority of Windows
Python users need win32all.

regards
Steve

 

[John Bokma]

I don't know why you consider it 'garbage',

How many people use GG without quoting, annoying plenty of people on
Usenet a day? (Well, the answer is probably less and less since GG is in
general added to quite some kill files).

using it myself for this
'contribution', but quoting isn't hard using google groups. Just
clicking the right links instead of the 'reply' link beneath the
message.

Yet its well enough hidden for people to use it, or so it seems.