I guess I don't understand some people's determination to not have users install fully useable Python on their Windows machines.[snip]
To put it another way, needing a Python interpreter to run .py files is no different from, for instance, needing a movie player to run .mpg files, and all Windows users are or need to become familiar with that general concept.
Also, I think it a bit 'anti-social' to hide usage of Python. If all Python Windows programs ran with a normal, communally installed Python, then users would gradually get the idea that having Python installed is much like having Shockwave and other utility platforms installed, and that is is part of a 'fully loaded' Windows system to have a .py player installed.
If there is something about the default install of Python on Windows that makes it less desireable or less easy than other platforms, then maybe that can be fixed. To make installation easier, maybe someone could write a small .exe that could be frozen with scripts or run with installers and that would detect the presence/absence of the needed Python version and offer an auto download and install if needed.
I mostly agree with the sentiment, but it does break down a little in practice. At least currently it does - like you said, this is fixable, but nobody has signed up to fix it yet.
The main thing that's needed is a zero-input Python distribution - a Python runtime, if you will - that (1) gets installed to a "good" place (2) does so without asking the user to do anything, (3) can coexist with different versions of the runtime, and (4) is easily detectable by applications wanting to use it.
One other minor component is a small launcher executable, because on Windows it's non-trivial to find out which "python.exe" in the task manager is running which Python script. Anyway, each app would have a small launcher that bootstraps the actual Python script[1]. (Or, if there's some way to trick the task manager into displaying something besides "python.exe", that'd work too)
In order to "fit" into the expectations of a typical Windows user, an application installer needs the ability to check for the presence of a particular version of the Python runtime, and then install it if it's not present, and do so without asking the user to do anything.
With that much in place, a lot of the need for freezing Python apps goes away (definitely not all of it, but a lot of it). Here's stuff that still needs to be considered though:
1) A way for apps to specify their compatibility with different versions of the runtime - "I work with pyrt2.3.3 through 2.4.1"
2) A way for apps to register their dependency on that runtime, so that if the user uninstalls it, there is at least an indication of what programs might break.
3) (this is a nice-to-have, but not 100% required) A way to download additional libraries once and use them for multiple programs, e.g. the installer could see if ctypes is present, and if not, go get it. Later programs would take advantage of it already being installed. Like I said, not a 100% requirement, and some of the ongoing work with code CPAN-like code repositories would shoehorn into this.
4) The security implications, e.g. an innocent app installs pywin32 and enables Python client-side scripting in Internet Explorer, and later this is used as a big door for malicious users to use.
Most of these tasks don't require a lot of work; indeed this has been on my "one of these days" lists for awhile. The main reasons it hasn't been done yet:
1) The code freezing tools like py2exe are *very* good and convenient (especially since loading code from zip archives was added - even if you include all of Python, it's only a few files on disk, and now they're all in the same directory)
2) Storage space and download speeds continue to increase at a rate much faster than the rate at which the size of Python is growing - a download of a few MB isn't too bad these days, who cares if your app takes 4MB on disk, and so what if it doesn't fit on a floppy, for example.
3) As soon as you get started on such a project, almost immediately you will be overwhelmed with a desire to create a CPAN-like system while you're at it, at which point your project's status will shift from "making good progress!" to "in quagmire, developers MIA". :)
-Dave
[1] I built a hacky one of these launcher exe's for one project, and it was fairly reusable for apps in the same vein. Basically, the exe would would look to see what its name was, and then load a Python module of the same name. So if you have MyGame.py, you'd just take the generic launcher.exe, copy it to the same directory as your .py files, and rename it to MyGame.exe. On launch, it'd load the interpreter, load MyGame.py, and pass it the command-line args.
--
http://mail.python.org/mailman/listinfo/python-list
