Installing .TGZ File I Got From Python.org....

[Alex Martelli]

"Josh" <polopunk209 at hotmail.com> wrote in message
news:d0a9c74e.0108102115.47fa503d at posting.google.com...
> I need help installing the .TGZ file that's distributed at Python.org.
> I have the base .EXE running, but I'm stumped for answers concerning
> what to do with this file. I have WinZip 8.0, and my OS is Win98 SE.

The .TGZ file (a compacted form of .tar.gz: .tar is a traditional kind
of Unix archive, .gz refers to the gzip GNU compression utility) contains
the Python source distribution.  It's a good idea to unpack it and keep
it around, even if you don't intend to rebuild Python from sources,
because the C sources can be instructive anyway (if you can read C)
*and* (for reasons that totally escape me!) the pre-built distribution
omits an important and interesting directory called Demo which has
lots of Python-coded examples well worth studying.

In other words: you don't need the source-distribution around in
order to run Python, but I suggest you do keep it around for study
purposes, even if you don't know C and don't care to learn it.

The popular WinZip commercial program knows how to unpack .TGZ
files (I do wonder how, since this should imply it's a derived work of
GPL-covered gzip and therefore its sources should be available, but
I guess they've found some legal trick, or something).  A typical
Windows installation might use C:\Python21 as the main Python
directory, and C:\Python-2.1 for the source distribution, but of
course it's up to you (a general piece of advice is to avoid spaces
in directory names -- sure, sure, all tools are supposed to handle
them right, but then and again some problem keeps popping up:-).

> (I would be running Mandrake, but my parents are attached to Windows.
> The teenage years really are traumatic...)

Yep, but so are the adult ones -- I had to put Linux away and
go full-time Windows 5 years ago for professional reasons (as
Windows-guruhood was what I was being paid for, I really
needed full-immersion to absorb every bit of Windows lore).
But the times, they are a-changin', and now...

...now you CAN easily install Linux side by side with Windows,
by various means -- as long as your disk is large enough to hold
both, of course, but nowadays, with 40GB disks going for a
pittance, this typically isn't a problem.  If you're keen specifically
on Mandrake (and I well see why one would be, even though I'm
installing Redhat 7.1 myself on my new box at this time -- I had
to go fetch the Alsa drivers, build them, &c, since said box's audio
is AC97, but I hear Mandrake 8 comes with Alsa pre-installed...
just an example, but a significant one!), you may be in luck...

It seems Mandrake is developing a version that's optimized to be
installed next to Windows -- they variously refer to it as Lnx4Win
and Linux4Win.  It's still not completely packaged up and spiffied
up -- you have to place some files in the right places by hand, &c --
but you may think of that as providing even greater educational
value wrt the no-hassles click-and-go experience that's more
typical of installing Linux today:-).

A key issue is partitioning or otherwise: Lnx4Win builds a normal
Linux filesystem (ext2fs I believe) on what looks to Windows as
one BIG file on the Windows partition -- no repartitioning and
attendant hassles, but neither the performance and disk-space
waste hit of an umsdos installation.  All it takes is the disk space
to build the big file -- your parents can be running Windows SE
(or whatever) while you're booting back and forth between that
and Linux (well, not 'while' as in 'at the same instant of time' --
so you may want to use 'whereas' instead:-).

Me, I'm just waiting for Lnx4Win to mature a bit, then I'll give it a try
on my laptop -- I do have a spare gigabyte or so there.  On the
big box where I have now installed Redhat 7.1 (but I may yet
change my mind and go for Debian when woody's stable), I
think I'll try Win4Lin instead (if, as I assume, Wine proves too
immature yet to let me run Word97 -- I do need that! -- and
VC++6 -- ditto -- and try out Python programs).

Now all of the above may look like it's off-topic, but I don't
think it is.  Python is cross-platform, and unless one has to
stay within a single OS for some reason, there's typically an
educational advantage in operating in a cross-platform way,
with packages such as wxPython (or good old Tkinter)
giving you a chance to make extremely-portable Python apps.

So you may exploit the advantages of both platforms -- those
of Linux are obvious (no more blue screens!-), but one gains
an appreciation for those of Windows, too.  They're spelled
*COM* -- a family of technologies, infrastructure and 'social
norms' [a serious commercial Win application can't fail to
provide good COM support -- it would kill it in the market]
that in practice ensure you can use Python to script just about
ANYTHING under Windows with minimal hassles (on Linux,
there are some attempts such as bonobo and XPCOM, but
they're nowhere as pervasive as COM is on Windows).  Soon,
the advantages of Win might be spelled .NET Framework
(although I earnestly hope 'mono' and other .NET-cloning
attempts in the free software world keep Linux & friends
competitive on that score, I wouldn't bet my shirt on it) --
a sort of "COM is dead, long live COM" arrangement.  From
a technical, professional, cultural and Pythonic viewpoint,
keeping reasonably current on both Windows and Linux (or
other free-software alternatives) is really desirable -- let's
not kid ourselves, neither is going to kill the other any time
soon.  We live a cross-platform present AND future:-).


> Also, where do I unzip the Debug.zip file? Any help would be

That one, I would throw away, if I were you.  It's a collection
of debug-built versions of Python's components: you can use
it if you're developing Python extensions with Microsoft
Visual Studio and want to compile your extensions in debug
mode (specifically, the issue is using the runtime libraries
MSVCRTD.DLL &c vs the normal MSVCRT.DLL &c).  In practice,
when I develop extensions I compile them for debug EXCEPT
that I use the normal MSVCRT.DLL -- otherwise, I'd have to
keep MSVCRTD-using versions of EVERY Python extension I
need to coexist with... what a hassle!  Rather, I may build a
debug-except-MSVCRT version of everything relevant (and
specifically Python itself and its core accompanying .pyd's
and .dll's) from the source distribution (it's just a matter of
toggling one switch or two from Visual Studio).  I don't really
need to debug *the Microsoft C-Runtime libraries* specifically,
at least, not most of the time (I've had to do some such
debugging at work, and it's not exactly fun:-).

If you're not doing C development at this time, then you
definitely don't need anything in that file.

> appreciated, and I wouldn't be asking this question if the UseNet
> search had turned up anything helpful, so I apologize for polluting
> the board with lame questions.

There are no lame questions (well, there might be, but
yours weren't:-).  Maybe we need to work out a better
explanation of what each package it and whether one would
want it, what for, where to unpack it, &c.

> P.S. If you didn't gather this from my first post on the board, I'm a
> newbie.

Welcome, and many happy returns!


Alex

P.S., if you didn't gather this from this post, I'm an incurably
verbose chatterbox:-).