I (don' ) will kill my Python

[Terry Reedy]

"Bruno Schaefer" <bup.schaefer at planet-interkom.de> wrote in message
(and Tim Peter already gave one reply)

> I'am still here ... and I don't want to kill  my Python.

Good.

> It was not my aim to hurt somebody and sorry to all.

Apology accepted on behalf of all who don't object to my doing so.

> But all the  replies to my message (which came from an outbreak of
frustrations)
> are very interesting.

> All aspects in short:
> 1. There are many Python users with similar problems

Let's define the problem as sharing Python code.  One solution is to bundle
the Python runtime and libraries (a few megabytes) with each piece of
Python code.  For a person who will get only one piece of Python code and
will never want to do anything directly with the interpreter, this might be
the best solution.  But for multiple chunks of code, I agree with Tim that
one open installation of Python is better than multiple closed copies.  (By
'closed', I mean only able to execute the one main module the system is
bundled with.)

What we 'need' is to persuade PC/Windows venders to pre-install Python the
same way many Linux venders do now and the way many microcomputer sellers
once did with MSBasic (around 20 years ago).

> 2. The Python developers have to do more in this direction

'Have to' can mean one of two things: 1) 'because I say so', which is
obviously irritating, and 2) 'because of the nature of the social-political
political universe we live in'.  Since statements of the latter can also
have a tone of 'because I say so', they can also be irritating.  As Tim
hinted, repeated demands (especially by newcomers) for free service,
unaccompanied by appreciation for the gift already received, and the
ongoing effort to improve it, occasionally leads to an 'outbreak of
frustration' (as you so aptly put it).

How about 'Many people would like the Python developers to do more in this
direction'.

As modified, this is now a true statement, but is easing the creation of
stand alone executables the right way to go?  People can honestly disagree.
One problem with sharing files is dependency on non-standard modules.
Suppose I write a picture database program using WxPython for the GUI, PIL
(Python Imaging Library) for the image manipulation, and Gadfly (In-memory
RDBM) for the database, all of which have their own binaries.  Asking a
friend to download and install three more packages (in addition to core
Python) is certainly a nuisance for him or her, but combining multiple
binaries, or the code they are compiled from, would be at least a major
nuisance for anyone, and I am not sure how far the process can be reliably
automated.  Besides which, any bug-fix or gotta-have upgrade in any package
requires a repetition of the entire process of bundling and distribution of
all.

Let those who believe in that direction proceed if they wish, but many
Python developers and volunteers are more interested making it easier to
add packages to a standard open installation.  This is the goal of the
disutils (distribution utilities) project.  What many of us would like
ultimately is a super import function that could handle URLs (such as
'python.org/download/packages'?) as part
of the search path and do whatever is needed to get the necessary text and
binary files onto the local machine so the program can continue
successfully.

One final note: the reason some people want to distribute a standalone
binary is to hide their Python code by burying it within the binary.  Such
people are free to do so, but the Python developers who freely share their
code do not 'have to' help others hide code.


> Young people, starting with programming, take their program on a disk
> and give it to their friends and will say "This is my program! I have
> created that by myself !!!"

This was a major part of the microcomputer revolution back when everyone
had some version of Basic.  The result was thousands of publicly available
programs.  I (and others) would like Python to play the same role in the
future: 'Basic for the 21st century', or 'Basic for the New Millenium'.

> And the reality is that most of beginners use M$soft products, that
means Win$.

Most is not all!  What if your best friend has a Mac?

Besides this, the pluralization of 'products' must also be applied to the
'Windowses' (arguably not grammatically correct, but such is the problem
arising from applying a single plural name to multiple singular entities).
Windows 3.1, 95, 98, 98SE, NTx.y, 2000, and ME are all different from each
other, and supposed upgrades and successors are not always compatible with
binaries that work with predecessors (ie, ME does not seem to run all 98
programs).    It's impressive that the (free) Python installers for
'Windows' work as widely as they do.

There is a real argument for swimming the river once (per Python version)
by installing an open Python system (and necessary compiled libraries) and
then exchanging standard text files.

> Is it the best solution for this problems to say : Go to VB or never
> come back, if Python users are angry about their problems ???

No. its to get Python installed on every machine, and make it easier to
install optional packages.

Terry J. Reedy