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.

--
.:[ dave benjamin -( ramen/sp00 )- http://spoomusic.com/ ]:.
"we control the sun" - toys that kill

[Robert Hicks]

Re: Time to bundle PythonWin

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

Robert

[Dave Benjamin]

Re: Time to bundle PythonWin

On Thu, 11 May 2006, Robert Hicks wrote:
[color=blue]
> No it isn't. It is a Windows only package. It needs to stay a separate
> download.[/color]

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

Dave

[John Bokma]

Re: Time to bundle PythonWin

"Robert Hicks" <sigzero@gmail. com> wrote:
[color=blue]
> No it isn't.[/color]

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

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

[Carl Banks]

Re: Time to bundle PythonWin

Robert Hicks wrote:[color=blue]
> No it isn't. It is a Windows only package. It needs to stay a separate
> download.[/color]

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]

Re: Time to bundle PythonWin

On Thursday 11 May 2006 23:09, Dave Benjamin wrote:[color=blue]
> 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?
>[/color]

There's a lot of omission on the windows platform, and that ain't python or
win32all's fault.
[color=blue]
> 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.
>[/color]

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.

--
There are 10 types of people in this world,
those who understand binary, and those who don't.

[Ravi Teja]

Re: Time to bundle PythonWin

> I write applications that use COM and Tkinter to automate basic office[color=blue]
> 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.[/color]
[color=blue]
> It's time to bundle PythonWin.[/color]

Someone already has.
http://www.activestate.com/Products/ActivePython/
[color=blue]
> Mac libraries are bundled with Python's *standard library*.[/color]

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]

Re: Time to bundle PythonWin

Dave Benjamin <ramen@lackingt alent.com> wrote:
...[color=blue]
> It's time to bundle PythonWin.[/color]

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]

Re: Time to bundle PythonWin

On Thu, 11 May 2006, Alex Martelli wrote:
[color=blue]
> Dave Benjamin <ramen@lackingt alent.com> wrote:
> ...[color=green]
>> It's time to bundle PythonWin.[/color]
>
> 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).[/color]

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

Dave

[Martin v. Löwis]

Re: Time to bundle PythonWin

Dave Benjamin wrote:[color=blue]
> 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.[/color]

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

You can use subprocess.Term inateProcess for that (in some limited way).
[color=blue]
> 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?[/color]

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.
[color=blue]
> It's time to bundle PythonWin.[/color]

So go and work on that.

Regards,
Martin

[jUrner@arcor.de]

Re: Time to bundle PythonWin


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]

Re: Time to bundle PythonWin

Ten wrote:[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> Still, it's not an either/or choice, I suppose.[/color]

Yep. =)

Cheers,
Dave

[Dave Benjamin]

Re: Time to bundle PythonWin

jUrner@arcor.de wrote:[color=blue]
> 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.[/color]

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]

Re: Time to bundle PythonWin

Martin v. Löwis wrote:[color=blue]
> Dave Benjamin wrote:[color=green]
>> 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.[/color]
>
> 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][/color]

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.
[color=blue]
> 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.[/color]

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...
[color=blue]
> 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.[/color]

If only I had his expertise on the win32 API...
[color=blue][color=green]
>> There are many useful things that you ought to be able to do without
>> downloading third-party libraries. Terminating a process, for example.[/color]
>
> You can use subprocess.Term inateProcess for that (in some limited way).[/color]

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.
[color=blue][color=green]
>> 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?[/color]
>
> 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.[/color]

Well, good, at least I'm not the only lazy complainer around here. =)
[color=blue][color=green]
>> It's time to bundle PythonWin.[/color]
>
> So go and work on that.[/color]

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

Dave

[Martin v. Löwis]

Re: Time to bundle PythonWin

Dave Benjamin wrote:[color=blue]
> 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.[/color]

That is technologically challenging. Contributions are welcome.

Regards,
Martin