Python 2.4 killing commercial Windows Python development ?

[Jimmy Retzlaff]

Terry Reedy wrote:
> I guess I don't understand some people's determination to not have
users
> install fully useable Python on their Windows machines.  Doing so
seems no
> different to me than having to install (or upgrade) Shockwave, or
Apple's
> Quicksomething for Windows (not used so much anymore), or RealPlayer,
or
> the lastest upgrade for DirectX, or DivX, or a zip decoder, or any
other
> 3rd party software, to run .xxx files or specialized .exe programs.
(And
> I left out the most direct analogy of a java system.)

The Windows application that I develop and distribute relies on Python
plus 14 other packages (wxPython, pywin32all, ctypes, Numeric, PIL,
etc.). My customers typically install the application on 20-100 user
machines within their organization at one time so it's mandatory that I
make an automated silent installer available. That's a lot easier to do
with py2exe and a Windows installer than it is to do with Python's MSI
and 14 other packages. It's also more robust - the installer is much
simpler and my application is always used with exactly the same Python
environment that was used for QA.

There are also significant hurdles to clear before software can be put
on user machines in an organization like this. The reviews with the IT
groups go much more smoothly since I can state that my installer will
only write files to one folder of the IT group's choosing, put an icon
in the Start Menu, and will only touch the registry to register an
uninstaller. If there were 15 installers being run (even if automated)
we'd have to review each of those individually and my product would
almost never be approved.

I don't actively hide the fact that I use Python, but my customers are
rarely interested in my toolbox - they are too focused on their own
business. Some groups will ask what language I use, and the following
question will always be something like "If we need it to, can it
interact with Java?" or C# or ...  that's their only interest in the
language I use. If they open themselves up by asking then I can't help
but badger them with the virtues of Python for a while. :)

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

Many of my users don't have a concept of a "file" unless it's something
they ask their assistant to get from a cabinet. They are typically
corporate executives for very big companies and if they have a computer
problem then a team of IT people get paged to fix it immediately. They
don't "need" to become familiar with anything on a computer - their job
is managing many billions of dollars worth of business every year. They
can use almost every feature of my application if they can move the
mouse and click the left button. That requires training for some of
them, and I feel honored they'll take the time to learn that much in
order to use my software.

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

I feel the opposite. I've skipped evaluating a number of applications
because they didn't come with their own dedicated JVM. I've spent way
too much of my own time trying to use applications with conflicting JVM
requirements only to give up in the end. It's just a new form of DLL
hell.

As a user, I only want to think about how well an application does what
I need it to do. The more time I spend dealing with supporting
technologies, the less time I spend on the intended task.

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

Something like Flash is quite special purposed and you don't have tons
of large extension modules that are in common use. You just use the base
system and it is very tightly controlled by one organization to maintain
backwards compatibility. And it is primarily used to augment/replace
HTML pages, so you don't want to download/install the engine each time
you come across another page with Flash content. Applications are
different, you acquire them once and use them over and over and the
runtime environment is much more variable from app to app. You don't
just have to worry about the backward compatibility of Python itself,
but of every extension module in common use and all the combinations
that arise out of that. Again look at the pain of shared JVM use. I
think Microsoft is on the right track to addressing DLL hell now by
recommending that DLLs be installed in the application folder, not the
system folder. That's analogous to using application specific JVMs and
things like py2exe or cx_freeze for Python.

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

My users only get access to "approved" sites (nothing else shows up in
their DNS). It's hard enough to get my own domain added to the ordained
list, much less a long list like python.org, sourceforge.net,
effbot.org, etc.

All this isn't just for my clients. I have a number of automated
processes that I run on my server that are written in Python. When I
need a new version of some module for one of those processes, I don't
want to spend the time testing it with each of the others to make sure
it didn't break anything. So I build single file executables from my
Python scripts so they are completely self-contained. When I want to
modify a module, then I can test/correct the impact of any new modules
at that point since I'll be in the code anyway. Before I started doing
this, the version of Python and the various extension modules in use on
my server was a couple of years older than the version on my development
machine because I almost never upgraded for fear of breaking several
processes.

Hard drive space is cheap and building exes is easy and I like the
benefits.

Jimmy

p.s. - on the original topic of this thread - I also buy development
tools from Microsoft that ensure I have the right to distribute the
needed DLLs so it's not a concern in my case.