Python packages on OS X vs Windows

[Kenneth McDonald]

At the moment I'm doing most of my stuff on a Mac, but I've been
considering also getting
a Windows laptop. One of the reasons is that I've found it very
difficult to get certain
Python related things running on the Mac; for example, if one wants
to use the most
up-to-date Python on the mac, rather than the one installed by Apple,
things can get
a bit hairy, and then if one wants to go PyQT/wxPy/etc, it can get
even worse with
trying to get all the compiling/linking to work.

On the other hand, it seems like most of this stuff is just available
as installers for PCs.
Am I being naive to think that installation of most of this stuff
(including getting it working)
will be much easier in the PC world?

And on a somewhat related note, do people find ipython to be a decent
replacement
on Windows for the fact that the Windows shell is braindead?

Thanks,
Ken

[Dan Sommers]

On Wed, 14 Dec 2005 20:50:47 -0600,
Kenneth McDonald <ke************ ****@sbcglobal. net> wrote:

... I've found it very difficult to get certain Python related things
running on the Mac ... if one wants to go PyQT/wxPy/etc, it can get
even worse with trying to get all the compiling/linking to work.
Have you tried fink (<http://fink.sf.net>)?
On the other hand, it seems like most of this stuff is just available
as installers for PCs. Am I being naive to think that installation of
most of this stuff (including getting it working) will be much easier
in the PC world?

It can be like falling off a log in the Linux world.

Regards,
Dan

--
Dan Sommers
<http://www.tombstoneze ro.net/dan/>

[Mike Meyer]

Kenneth McDonald <ke************ ****@sbcglobal. net> writes:

At the moment I'm doing most of my stuff on a Mac, but I've been
considering also getting
a Windows laptop. One of the reasons is that I've found it very
difficult to get certain
Python related things running on the Mac; for example, if one wants
to use the most
up-to-date Python on the mac, rather than the one installed by Apple,
things can get
a bit hairy, and then if one wants to go PyQT/wxPy/etc, it can get
even worse with
trying to get all the compiling/linking to work.

Have you considered using the Unix/X distribution of Python? OS X is
ok as a Unix system, and comes with a not unreasonable X server. I
tend to install things from darwin ports, but you might prefer fink
(or even emerge, though I've pretty much given up on it).

<mike
--
Mike Meyer <mw*@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[SPE - Stani's Python Editor]

With some good guidance, it goes much more smooth than I thought, even
for a total Mac newbie like me. For example to install the latest
Python 2.4.2 and wxPython2.6 on the Mac was very easy. You can find
instructions in the SPE Python IDE manual and also how to install SPE
on the Mac in case you want a full featured IDE as well:
http://pythonide.stani.be/manual/html/manual2.html

Here as well you'll find a lot of installers as well for MacOS X:
http://pythonmac.org/packages/

Good luck,
Stani
--
http://pythonide.stani.be

[Alex Martelli]

Kenneth McDonald <ke************ ****@sbcglobal. net> wrote:

At the moment I'm doing most of my stuff on a Mac, but I've been
considering also getting
a Windows laptop. One of the reasons is that I've found it very
difficult to get certain
Python related things running on the Mac; for example, if one wants
to use the most
up-to-date Python on the mac, rather than the one installed by Apple,
things can get
a bit hairy,
Such as, downloading
<http://downloads.activestate.com/Act...ActivePython-2
..4.2-248-macosx-powerpc.dmg>
and doubleclicking on the package it contains? I don't see how it could
get any less hairy than that.
and then if one wants to go PyQT/wxPy/etc, it can get
even worse with
trying to get all the compiling/linking to work.
I assume that's because the pre-built versions of these various packages
are built for Python 2.3.5 (the version Apple bundles with MacOSX)
rather than for ActivePython. But one run of "python setup.py install",
while perhaps "worse" than doubleclicking on a pkg within a dmg, is
still not really "hairy".
On the other hand, it seems like most of this stuff is just available
as installers for PCs.
Am I being naive to think that installation of most of this stuff
(including getting it working)
will be much easier in the PC world?

PyQt for Windows is not available under GPL (as it is for Mac). If
shelling out 250 pounds (plus VAT) is "much easier" for you than doing a
little compilation, or you can't use the GPL version anyway, etc, etc,
then, maybe.

Me, I'd rather stick to the Mac...!-)
Alex

[Bugs]

Have you tried the ActiveState version of Python?
http://www.activestate.com/Products/...d=ActivePython

[BartlebyScrivener]

> And on a somewhat related note, do people find ipython to be a decent

replacement
on Windows for the fact that the Windows shell is braindead?

I'm curious about this part of the post. Any fluent Pythoners actually
happy using Windows XP and, if so, do they use ipython as a kind of
bash shell substitute? Other alternatives to compensate for the widely
derided command line in windows?

rpd

[Scott David Daniels]

BartlebyScriven er wrote:

I'm curious about this part of the post. Any fluent Pythoners actually
happy using Windows XP and, if so, do they use ipython as a kind of
bash shell substitute? Other alternatives to compensate for the widely
derided command line in windows?

The widely derided command line in Windows is largely widely derided by
people who are used to a different command line and wish windows matched
the one they were used to. I have moved between a number of different
"shells" in my programming career, and Windows "cmd.exe" is not at all
the worst (though I had to do a lot of "help" command to learn how to
use it). The tough part on Windows (for the Linux/Unix/*ix bigots) is
that each program scans the command line that invoked it in its own
inimitable way. This is not really the fault of the windows command
line processor; this comes from allowing flexibility to individual
programs. The Windows model is big programs that do everything; the *ix
model is small independent processes that connect in interesting ways.
I like the latter, but there is something to be said for the former.

--Scott David Daniels
sc***********@a cm.org

[Cameron Laird]

In article <ma************ *************** ************@py thon.org>,
Kenneth McDonald <ke************ ****@sbcglobal. net> wrote:

[Mike Meyer]

Scott David Daniels <sc***********@ acm.org> writes:

BartlebyScriven er wrote:
The tough part on Windows (for the Linux/Unix/*ix bigots) is that
each program scans the command line that invoked it in its own
inimitable way. This is not really the fault of the windows command
line processor; this comes from allowing flexibility to individual
programs.

If you mean what I think you mean, I'd say it's the fault of
Windows. I don't do much Windows, and no Windows-specific development,
so maybe this has been fixed since I last checkd on it.

I consider Unix shells to be less than good as command line
processors. Yes, they have lots of really spiffy features, but most of
them just aren't very bright when it comes to being a command line
processor.

zsh is the only exception I know about, but that requires someone
familiar with both zsh and the command in question to teach zsh about
each individual command in a language that looks like line noise in
places, and adds a level of indirection to all your commands. And
that's for the easy cases.

A good command processor provides an API so that commands can tell the
command processor about their arguments, allowing the command
processor to do completion on flags or command words, to complete
arguments and do pattern matching against the appropriate universe,
instead of just against file names, and so on.

Windows seems to have APIs for nearly everything. Is there one like I
described above?

<mike
--
Mike Meyer <mw*@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.