By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,959 Members | 1,160 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,959 IT Pros & Developers. It's quick & easy.

Is Python Mac Centric???

P: n/a
While trying to learn more about Python's standard modules, I noticed
that there are *a lot* of Mac only modules... more so than Unix and
Windows specific modules combined. Is there a reason for this? I am
familiar with the Windows extensions by Mr. Hammond and wonder if
they'll ever become apart of the official Python distribution. It looks
as if something similar already exists for Macs with all these Mac only
modules. Why is this?

Also, I've noticed that OSX 10.3 comes with Python 2.3 installed, but
that Windows XP does not. Python installation is much more cumbersome on
Windows. The user has to dl Python and then Mr. Hammond's extensions to
get up to speed with the new Macs out of the box. Does Python play
favorites? I think it would have a much larger user base if Windows user
got what mac users get.

Could someone explain this to me? I don't mean this to start a platform
war as I'm really agnostic on the matter. Just curious.

Thanks!!!

Jul 18 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
Apple decided they wanted to include Python in 10.3, and the Python
community was thrilled.

There are also a couple of people who are working very hard on
Mac-specific modules for Python. I don't know why they're included in
the core while pythonwin is not--is it just historical coincidence? A
license difficulty? Change in attitudes? However, I don't view the
pythonwin download as a big hassle.

Python could probably be included in the next version of Windows
if Bill Gates decided he wanted to. But I don't think he's called Guido
up yet.

Jeff

Jul 18 '05 #2

P: n/a

Jeff> Python could probably be included in the next version of Windows
Jeff> if Bill Gates decided he wanted to. But I don't think he's called
Jeff> Guido up yet.

I believe the Python license gives Bill the option of including Python
without Guido's permission. ;-)

Skip

Jul 18 '05 #3

P: n/a
Also, I've noticed that OSX 10.3 comes with Python 2.3 installed,
Tim> That was Apple's decision, not "ours".
but that Windows XP does not.


Tim> And that's Microsoft's decision, not "ours". We can't tell OS
Tim> vendors what to ship, and all OS vendors are equally free to
Tim> redistribute Python (the Python license extends that right to
Tim> everyone who wants it).

While Microsoft doesn't bundle Python with Windows, there are one or two PC
makers who add Python to their Windows boxes (HP comes to mind - the
practice appears to have originated at Compaq before HP acquired it). I
think that's mostly to support their extra admin tools, not to encourage all
their customers to start writing software.

Skip

Jul 18 '05 #4

P: n/a

"hokieghal99" <ho********@hotmail.com> wrote in message
news:bs**********@solaris.cc.vt.edu...
Also, I've noticed that OSX 10.3 comes with Python 2.3 installed, but
that Windows XP does not.


My new HP Pavilion XP came with Python 2.2.1 loaded for use by HP's
utilities. However, their docs say nothing about it and it was not
completely installed in that there were no file associations for .py.
That's fine since I will add 2.3.3 soon and leave HP's install alone for
its use.

Terry J. Reedy
Jul 18 '05 #5

P: n/a
hokieghal99 fed this fish to the penguins on Tuesday 30 December 2003
08:23 am:
familiar with the Windows extensions by Mr. Hammond and wonder if
they'll ever become apart of the official Python distribution. It
They're already "apart from"; whether they'll become "a part of" is
another question.
looks as if something similar already exists for Macs with all these
Mac only modules. Why is this?
Not really. I don't think the Mac modules are accessing down to the
core Mac programming interface, they are more utilities.

I think shutils duplicates a lot of the macostools package. The macfs
package seems to exist mainly to present standard file requesters --
probably because there was (still is?) no normal command-line interface
on the Mac; before TKinter became a standard part of the Python install
(back in the 1.5 days) the Windows/Linux/Unix/Amiga/etc. ports all had
access to a command line and didn't need graphical popups to ask for
stuff like files -- the Mac had no such option. (I forget if it was
someone at SLAC or LLNL who produced an AREXX library for such pop-ups,
and since Irmen was kind enough to fit a REXX port module into Amiga
Python, one could do the graphical requests via a REXX linkage <G>).

macfs probably still exists because it would be too painful to remove
it.

Besides, there ARE Windows specific modules: msvcrt and _winreg
Also, I've noticed that OSX 10.3 comes with Python 2.3 installed, but
that Windows XP does not. Python installation is much more cumbersome
on Windows. The user has to dl Python and then Mr. Hammond's
extensions to get up to speed with the new Macs out of the box. Does
Python play favorites? I think it would have a much larger user base
if Windows user got what mac users get.
So complain to Bill Gates. Mac OSX is a Unix-variant OS; the core that
Apple started with likely included lots of such "additional" stuff. The
Python developers have no control over what get included with an OS
release. (Note: if you download from ActiveState, I think you can get
Python and the extensions in one installer, along with the PythonWin
IDE).
-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Bestiaria Home Page: http://www.beastie.dm.net/ <
Home Page: http://www.dm.net/~wulfraed/ <


Jul 18 '05 #6

P: n/a

On 30 dec 2003, at 21:41, Dennis Lee Bieber wrote:
looks as if something similar already exists for Macs with all these
Mac only modules. Why is this?

Not really. I don't think the Mac modules are accessing down
to the
core Mac programming interface, they are more utilities.


They are wrappers for a large part of the MacOS API's. And they are
actively maintained.

Ronald
Jul 18 '05 #7

P: n/a
Jeff Epler wrote:
There are also a couple of people who are working very hard on
Mac-specific modules for Python. I don't know why they're included in
the core while pythonwin is not--is it just historical coincidence? A
license difficulty? Change in attitudes?


AFAIR, the Mac parts were included on request of Jack Jansen, who
was looking for a "permanent home" for his code, with CVS, bug tracking,
integrated releases, and all that. Guido van Rossum agreed, as it would
make Jack's life simpler.

I personally was shocked when I saw just *how* big the code base was,
but then accepted it, as much of it is for OS9 and older, and the OSX
stuff is more and more getting folded into the standard libraries
(where applicable); OS9 support will be dropped for Python 2.4.

Apart from Tim's analysis of coding styles, I think PythonWin would
become integrated if Mark Hammond requested that. Anybody else
requesting it would have no effect; and, as Tim said, Mark is unlikely
to request it because he doesn't want to wait a year for the next
Python release just to release the next version of PythonWin.

Regards,
Martin

Jul 18 '05 #8

P: n/a
"hokieghal99" <ho********@hotmail.com> wrote in message
news:bs**********@solaris.cc.vt.edu...
Python installation is much more cumbersome on
Windows. The user has to dl Python and then Mr. Hammond's extensions to
get up to speed with the new Macs out of the box.


Or install the ActiveState distro, which has pythonwin pre-installed. One
install and off you go.

To be honest, too, I'm not sure how useful the pythonwin extensions are for
new Python users -- if you're not interested in banging around with the
Windows API, then base Python has all you need. Although I do very much like
the pythonwin IDE.

James
Jul 18 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.