Re: [Pythonmac-SIG] My stab at a new page
Bill Janssen wrote: You missed the first part of my message, I think. The system version would be installed under /usr/libexec/, or some such place, not under /usr/bin/. That is a good idea, but how do we get Apple to do it? That would leave /usr/bin free for the MacPython gang to install its version, or at least a symlink to /usr/local/bin/pythonw. Except that, ideally, third parties should NEVER put ANYTHING in /usr/bin. However, if we put out stuff in /usr/local/bin (or /opt/whatever), and there was no python on the standard path, we'd have less confusion. Way back when Redhat used python1.5 with a bunch of added extensions for its admen tools. All their tools had usr/local/bin/env python in the #! line. This was a pain in the *$^%* when you wanted to upgrade your standard python, just like it's a pin now with Apple. However, all they needed to do was put a darn version on the #! line: /usr/bin/env python1.5 Apple could do the same thing, then all their admin tools would be insulated from adding additional, newer pythons anywhere on the PATH. I can't do anything about what Apple does, but I always put a version number in all my #! lines. This makes sure it uses the python version I want it used with, regardless of environment It also makes it clear to me, and anyone else that may read that script, what version is was developed against. Yes, when I get rid of that version of python, I need to go change a bunch of #! lines, but I like that too, because it assures that I am aware of what I've changed, and I can test against the new version of python when I do it. I like to see this as a universal practice in the Python world -Chris NOTE: Even better would be a way to specify multiple versions in order of preference, and a python launcher that would sort that out for you. This would be particularly nice on Windows, where you can only associate *.py with one thing. Maybe some day I'll want that enough to write it! -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/ORR/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Mon, Feb 13, 2006 at 09:06:06AM -0800, Christopher Barker wrote: Bill Janssen wrote: You missed the first part of my message, I think. The system version would be installed under /usr/libexec/, or some such place, not under /usr/bin/. That is a good idea, but how do we get Apple to do it? So the end result is that the system Python (and Perl, Tcl, Ruby, ...) isn't visible? Yuck - as started earlier in this thread, there are plenty of people for whom the system Python 2.3.x is plenty usable. Not everyone creates bundled applications for redistribution, or needs Python 2.4. Way back when Redhat used python1.5 with a bunch of added extensions for its admen tools. All their tools had usr/local/bin/env python in the #! line. This was a pain in the *$^%* when you wanted to upgrade your standard python, just like it's a pin now with Apple. However, all they needed to do was put a darn version on the #! line: /usr/bin/env python1.5 Apple could do the same thing, then all their admin tools would be insulated from adding additional, newer pythons anywhere on the PATH. What Apple does now, i.e. #!/usr/bin/python (see the contents of /usr/libexec/fax, for example), is better - what if you had a replacement Python 2.3 which didn't have Apple's CoreGraphics bindings in it, for example? It's not always going to be the case that Apple provides a Python version one major version behind the current one. Also, a lot of Apple's tools run from within a GUI context where the path is set by the loginwindow environment (~/.MacOSX/environment.plist), not by your shell initialization files, which makes absolute paths more attractive. They could use #!/usr/bin/python2.3, I guess... NOTE: Even better would be a way to specify multiple versions in order of preference, and a python launcher that would sort that out for you. This would be particularly nice on Windows, where you can only associate *.py with one thing. Maybe some day I'll want that enough to write it! Apple does something similar with its Java launching mechanism; you can specify exactly this JVM version or this major version or at least this version and so forth in the Info.plist file. It'd be nice if Apple provided a standard way to handle versioning for any system-provided interpreter, though whatever they did would only be likely to apply to bundled applications, not command-line stuff. -- Nicholas Riley [EMAIL PROTECTED] | http://www.uiuc.edu/ph/www/njriley ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
So you're saying that the pre-installed version could never be really acceptable. In that case, perhaps we only need convince Apple to move /usr/bin/python to some more system-y place that wouldn't usually be on users' paths. We then in the MacPython world take the position that Python isn't really pre-installed on Macs, and the place for a person to start would be to download the installer and run it. Perhaps then in addition the installer could symlink /usr/local/bin/pythonw to /usr/bin/python, thereby solving the PATH issue. That won't happen. Replacing system components is completely wrong, what if someone finds a security bug in /usr/bin/python and Apple ships a security update to fix it [*]. The installer should update the user's path to ensure that our version of python is earlier on the PATH. I guess that would be one way to get Apple to ship Python updates :-). You missed the first part of my message, I think. The system version would be installed under /usr/libexec/, or some such place, not under /usr/bin/. That would leave /usr/bin free for the MacPython gang to install its version, or at least a symlink to /usr/local/bin/pythonw. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On 12-feb-2006, at 19:28, Bill Janssen wrote: So you're saying that the pre-installed version could never be really acceptable. In that case, perhaps we only need convince Apple to move /usr/bin/python to some more system-y place that wouldn't usually be on users' paths. We then in the MacPython world take the position that Python isn't really pre-installed on Macs, and the place for a person to start would be to download the installer and run it. Perhaps then in addition the installer could symlink /usr/local/bin/pythonw to /usr/bin/python, thereby solving the PATH issue. That won't happen. Replacing system components is completely wrong, what if someone finds a security bug in /usr/bin/python and Apple ships a security update to fix it [*]. The installer should update the user's path to ensure that our version of python is earlier on the PATH. I guess that would be one way to get Apple to ship Python updates :-). You missed the first part of my message, I think. The system version would be installed under /usr/libexec/, or some such place, not under /usr/bin/. That would leave /usr/bin free for the MacPython gang to install its version, or at least a symlink to /usr/local/bin/pythonw. The system version is installed in /usr/bin. Or do you mean we should only support some future version where Apple doesn't place python in /usr/bin (which I hope doesn't happen)? Ronald Bill smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
The system version is installed in /usr/bin. Or do you mean we should only support some future version where Apple doesn't place python in /usr/bin (which I hope doesn't happen)? Yes, that was the idea. /usr/libexec/python, or some other directory unlikely to be on the user's path by default. I don't know about only support. Hope for was more like it. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 12, 2006, at 11:38 AM, Bill Janssen wrote: The system version is installed in /usr/bin. Or do you mean we should only support some future version where Apple doesn't place python in /usr/bin (which I hope doesn't happen)? Yes, that was the idea. /usr/libexec/python, or some other directory unlikely to be on the user's path by default. I don't know about only support. Hope for was more like it. It's not really a good idea, and it certainly has near zero chance of happening -- ever. Asking Apple to move their Python interpreter is dead in the water. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On 12-feb-2006, at 20:48, Bob Ippolito wrote: On Feb 12, 2006, at 11:38 AM, Bill Janssen wrote: The system version is installed in /usr/bin. Or do you mean we should only support some future version where Apple doesn't place python in /usr/bin (which I hope doesn't happen)? Yes, that was the idea. /usr/libexec/python, or some other directory unlikely to be on the user's path by default. I don't know about only support. Hope for was more like it. It's not really a good idea, and it certainly has near zero chance of happening -- ever. Asking Apple to move their Python interpreter is dead in the water. I sure hope so. /usr/bin/python has its uses. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 12, 2006, at 2:55 PM, Bill Janssen wrote: It's not really a good idea, and it certainly has near zero chance of happening -- ever. Asking Apple to move their Python interpreter is dead in the water. I sure hope so. /usr/bin/python has its uses. I wish someone would explain to me what /usr/bin/python can do that /usr/libexec/python cannot do. It's standard, and that's how it currently works. There is no good reason to change anything Even if they did decide to change it, the change would simply cause us to do twice as much work for the next couple years to support both layouts. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On 10-feb-2006, at 4:24, Bill Janssen wrote: Could a Mac ever ship with an acceptable pre-installed Python? If not, perhaps the solution for Apple is to move /usr/bin/python to some other spot, like /usr/libexec/, or some such place. The issue of not being able to produce redistributable applications still exists, and also backwards compatibility with previous versions of Mac OS X. So you're saying that the pre-installed version could never be really acceptable. In that case, perhaps we only need convince Apple to move /usr/bin/python to some more system-y place that wouldn't usually be on users' paths. We then in the MacPython world take the position that Python isn't really pre-installed on Macs, and the place for a person to start would be to download the installer and run it. Perhaps then in addition the installer could symlink /usr/local/bin/pythonw to /usr/bin/python, thereby solving the PATH issue. That won't happen. Replacing system components is completely wrong, what if someone finds a security bug in /usr/bin/python and Apple ships a security update to fix it [*]. The installer should update the user's path to ensure that our version of python is earlier on the PATH. Ronald [*] the first part being very unlikely of course :-) Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On 11-feb-2006, at 0:37, Bill Janssen wrote: I've put up a new page, with a slightly different address: http://bill.janssen.org/mac/new-macpython-page.html. I noticed you use an icon that contains a realistic picture of a snake. Please keep in mind that lots of people are scared of snakes, please see the archives for more information. not-getting-the-snakephobia-ly yours, Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On 11-feb-2006, at 1:40, Charles Hartman wrote: On Feb 10, 2006, at 5:31 PM, Bill Janssen wrote: And how about bundling tcltkaqua into it, as well? Because some of us, at least, have no interest in tcl. I'm not clear whether its presence interferes with wx (thing #421 that I'm not clear about), but it doesn't help; why should I want it on my system? Because _tkinter, and hence IDLE use it? IDLE seems to be the only ready-to-use acceptable Python IDE right now. Not that I want to bundle Tcl/Tk, Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 11, 2006, at 2:50 PM, Charles Hartman wrote: On Feb 11, 2006, at 4:22 PM, Ronald Oussoren wrote: On 11-feb-2006, at 1:40, Charles Hartman wrote: On Feb 10, 2006, at 5:31 PM, Bill Janssen wrote: And how about bundling tcltkaqua into it, as well? Because some of us, at least, have no interest in tcl. I'm not clear whether its presence interferes with wx (thing #421 that I'm not clear about), but it doesn't help; why should I want it on my system? Because _tkinter, and hence IDLE use it? IDLE seems to be the only ready-to-use acceptable Python IDE right now. I'm not very happy about that (and I don't know that anyone else is, either; Bob I. has described some of the problems with IDLE), but if it's the way it is it's the way it is. But here I am, a rank beginner, I look at the descriptions of wxPython and its rivals and decide I like wx -- can I install that, and begin building apps with it, from IDLE? Yes, assuming IDLE is started up and configured properly that will work fine. IDLE is one of the few IDEs that is designed properly such that it runs scripts in a subprocess. We all seem to recognize the need for flexibility in preferences about IDEs (since there's no clear, free, Mac-native choice). But GUI libraries may be different. I feel it's important not to foreclose the wx possibility, and I'm still not clear about what that entails, though a recent post by Bob (which I can't find at the moment) partially addressed this. Huh? wx possibility? I'm totally confused, what relevance does wx have to any of this discussion? Not that I want to bundle Tcl/Tk, --especially given the download/install overhead, right? Yes, it's a few megs. OS X 10.4 ships with it, so we don't have to include it -- just state that 10.3 users will need to acquire it separately. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
Bob Ippolito wrote: The largest issue is that you can't legally redistribute the Python interpreter that ships with Mac OS X, so you can't create standalone applications. Even if you could, it wouldn't have a chance of being backwards compatible with the way that Apple builds things. This seems to be where this argument goes: the user/newbies vs. the developers. Can we break this knot? Sure a developer wants a system that guarantees no barriers for anyone trying to use his product. Sure a newbie or just a user wants no barriers to just get up and running. If each side insists on having its way, this will go nowhere. I thought it had a chance for a few days and now I'm having my doubts. I sense developers here want everyone to get the latest and greatest python so then their product is a no-brainer to use (sorry about the slang). Of course, users/newbies want to just jump in there and go without pain. I'm a user so perhaps that explains why I am more on the user side. You shouldn't be forcing everyone to adopt a python system that then suits your marketing model. Why a compromise can't be reached here is beyond me. Does this happen with Perl? Ruby? I'm not sure how helpful that was, but I need to vent. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
It seems to me (as *much* closer to a newbie than a developer) that simply recommending the download install of Python 2.4.x not only wouldn't put a major obstacle in the way of beginners, but wouldn't seem to, either. That one step isn't a problem -- if we can get to the point where that's the only step (because no Fix or Compat is needed, the PATH gets tweaked, etc). Charles On Feb 10, 2006, at 8:36 AM, Louis Pecora wrote: Bob Ippolito wrote: The largest issue is that you can't legally redistribute the Python interpreter that ships with Mac OS X, so you can't create standalone applications. Even if you could, it wouldn't have a chance of being backwards compatible with the way that Apple builds things. This seems to be where this argument goes: the user/newbies vs. the developers. Can we break this knot? Sure a developer wants a system that guarantees no barriers for anyone trying to use his product. Sure a newbie or just a user wants no barriers to just get up and running. If each side insists on having its way, this will go nowhere. I thought it had a chance for a few days and now I'm having my doubts. I sense developers here want everyone to get the latest and greatest python so then their product is a no-brainer to use (sorry about the slang). Of course, users/newbies want to just jump in there and go without pain. I'm a user so perhaps that explains why I am more on the user side. You shouldn't be forcing everyone to adopt a python system that then suits your marketing model. Why a compromise can't be reached here is beyond me. Does this happen with Perl? Ruby? I'm not sure how helpful that was, but I need to vent. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
Bill Janssen wrote: 1. Link to the Macintosh Library Module: A lot of that stuff will be rendered obsolete the minute Bob releases the universal build of MacPython. PythonIDE, Package Manager, etc.: not gonna be included. At a minimum, you should note that this stuff is legacy. 2. Ditto for Apple Events. Does anyone use gensuitemodule or even know what it means? Hey, I'm linking to the official documentation. That's what people will use, till it changes. All this other stuff scattered around is blue-sky wild-ass future, till it's documented. Problem with the official Mac-specific modules and documentation is there's quite of stuff in there that hasn't been correct/usable since OS 9. It's just that nobody's gotten around to dealing with it. Experienced users already know which bits to avoid, so there's not huge impetus to clean it out properly. Doesn't mean you want to steer newbies towards it though. e.g. There's precious little point in linking to gensuitemodule: while it's always been a bit flaky, it appears to be pretty well broken in Tiger. (I've tried it a few times and it just barfs up a variety of errors, and I've seen other reports so it's not just me.) You'd be better not linking to anything at all than linking to obsolete/broken junk like that, because it just makes the rest of Mac Python look bad. FWIW, I did start looking into the issue, but I'm not really qualified to make a call on a lot of the stuff there and I had more immediate things to be getting on with anyway. Still, from my notes, if it's any use: - mac, macpath -- deprecate now. (Are these ever used on OS X?) - macfs -- already deprecated. - FrameWork, gensuitemodule, aetools, aepack, aetypes, MiniAEFrame -- deprecate now. - findertools, Nav, nsremote, W -- deprecate now. - os/os.path -- docs appear to contain various misleading statements about using Python on Mac that apply only to OS 9, not OS X; fix/remove those statements. - EasyDialogs -- still used on OS X but lacks Unicode support and strings are limited to 255-chars - MacOS -- OS9 docs could be stripped out; GetCreatorAndType() and Set CreatorAndType() need fixed or deprecated (don't work on bundles) There's almost certainly more that could be axed by someone who knows what they're looking at. Maybe when I've more time I'll try to do more on this; be nice if it was addressed for Python 2.5. (Wonder what 2.5's schedule is?) HTH has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 9, 2006, at 1:32 PM, Kevin Walzer wrote: If I'm a newbie, I'm going to go, Huh?, then shrug, and move on to Realbasic. There needs to be something double-clickable there for a newbie to use. PythonIDE, though it had many flaws, was useful this way. BTW, what happened to PyOXIDE? It had major bugs, but was promising as a next-generation basic IDE for Python development on the Mac. PyOXIDE isn't dead - it's just sleeping. Seriously, there are several issues: 1) Lack of available time 2) It mostly does everything _I_ need (I actually use it on a fairly regular basis, and I have no burning need to add new features) 3) It needs to basically be re-written - it started as an editor with python embedded in it (i.e., use the python.framework and the various python embedding routines). Unfortunately, with 2.4 and the corresponding PyObjC, that just plain doesn't work well - PyObjC pretty much requires the thing to be a PyObjC-based application (application embedded in python), instead of an application embedding python. 4) The whole what version, what extensions mess that is being discussed here (sometimes I need to use the quartz binding stuff, which precludes other things, for example) 5) The whole what is the goal/underlying philosophy problem that is tangentially being discussed here (personally, I write just simple scripts that end up being run on the command line, but I like the interactive form that the old PythonIDE PyOXIDE provide where you can repeatedly run the same script, have an interactive console attached to that name space to examine things, call stuff, etc... which obviously doesn't work the same for somebody building a PyObjC standalone app vs wxPython app vs beginner who just wants to learn how to do something) So given #2, it hasn't been worth my time (#1) to solve #4 #5 (I've at least got a plan for #5 which should help reduce the scope of #4) and overcome #3. I really should at least release the 2.4 (partial) supporting build, not to mention there are a ton of bug fixes in the underlying IDEKit it's built on... Glenn Andreas [EMAIL PROTECTED] http://www.gandreas.com/ wicked fun! Widgetarium | the quickest path to widgets ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 10, 2006, at 7:24 AM, [EMAIL PROTECTED] wrote: On Feb 9, 2006, at 1:32 PM, Kevin Walzer wrote: If I'm a newbie, I'm going to go, Huh?, then shrug, and move on to Realbasic. There needs to be something double-clickable there for a newbie to use. PythonIDE, though it had many flaws, was useful this way. BTW, what happened to PyOXIDE? It had major bugs, but was promising as a next-generation basic IDE for Python development on the Mac. PyOXIDE isn't dead - it's just sleeping. Seriously, there are several issues: 1) Lack of available time 2) It mostly does everything _I_ need (I actually use it on a fairly regular basis, and I have no burning need to add new features) 3) It needs to basically be re-written - it started as an editor with python embedded in it (i.e., use the python.framework and the various python embedding routines). Unfortunately, with 2.4 and the corresponding PyObjC, that just plain doesn't work well - PyObjC pretty much requires the thing to be a PyObjC-based application (application embedded in python), instead of an application embedding python. That's not true, and I've told you the correct way to fix that... That's why py2app can build plugins. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
You seem to have a good handle on what is needed to get new users involved in working with Python on the Mac. Even some of the questions that you list here might be a little too complex for new users. The problem is that there are many kinds of new users. There are experienced programmers who understand the Mac, and are familiar with, say, Objective-C and Cocoa and Java, but are looking at Python for the first time. They want to know the things that Bob and Ron keep working on, things like How do a build an app in Python? and How do I use Cocoa, or Apple Events, or ... in Python? or How do I use Python with Xcode? And they want the Python tutorial. There are Python programmers coming from Windows or Linux, who want to know primarily how to get Python on their Mac, and what special things about the Mac they need to know to avoid tripping over their feet while using Python. They know about things like site-packages, but not about /Library vs. /System/Library, or frameworks, or various Apple-specific gcc bindings for dynamic linking. Then there are people like Karl described yesterday in his story about the computer teacher descovering Python's turtle graphics, who are looking for low-entry (no installers) ways to do scripting or education. A good entry page tries to speak usefully to all of these communities at the same time, without speaking down to any of them. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
Problem with the official Mac-specific modules and documentation is there's quite of stuff in there that hasn't been correct/usable since OS 9. It's just that nobody's gotten around to dealing with it. Experienced users already know which bits to avoid, so there's not huge impetus to clean it out properly. Doesn't mean you want to steer newbies towards it though. It sounds like we should ask the Python-doc folks to remove the Macintosh docs entirely. Maybe post it with appropriate warnings on pythonmac.org instead. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 10, 2006, at 11:27 AM, Bob Ippolito wrote: On Feb 10, 2006, at 7:24 AM, [EMAIL PROTECTED] wrote: On Feb 9, 2006, at 1:32 PM, Kevin Walzer wrote: If I'm a newbie, I'm going to go, Huh?, then shrug, and move on to Realbasic. There needs to be something double-clickable there for a newbie to use. PythonIDE, though it had many flaws, was useful this way. BTW, what happened to PyOXIDE? It had major bugs, but was promising as a next-generation basic IDE for Python development on the Mac. PyOXIDE isn't dead - it's just sleeping. Seriously, there are several issues: 1) Lack of available time 2) It mostly does everything _I_ need (I actually use it on a fairly regular basis, and I have no burning need to add new features) 3) It needs to basically be re-written - it started as an editor with python embedded in it (i.e., use the python.framework and the various python embedding routines). Unfortunately, with 2.4 and the corresponding PyObjC, that just plain doesn't work well - PyObjC pretty much requires the thing to be a PyObjC-based application (application embedded in python), instead of an application embedding python. That's not true, and I've told you the correct way to fix that... That's why py2app can build plugins. -bob Perhaps requires is too strong a word - how about is easiest to use if instead? Still, the current architecture of PyOXIDE (links with Python.framework, and calls the various PyRun_SimpleString, PyRun_SimpleFile and other commands as listed at http:// ftp.python.org/doc/ext/embedding.html via various UI callbacks, tries to manage the GIL, etc...) has a high impedance match against the way PyObjC works (since it wants to take care of all the details for you, made worse when _that_ code does UI work). My point is that the better way is just to make PyOXIDE a py2app based creature from the start (and then python code calls the IDE framework), though moving all the python code into py2app generated plugins is an interesting option (with it's own benefits/drawbacks). If it were trivial to fix, I'd have done it already... Glenn Andreas [EMAIL PROTECTED] http://www.gandreas.com/ wicked fun! Widgetarium | the quickest path to widgets ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 10, 2006, at 9:51 AM, Bill Janssen wrote: You seem to have a good handle on what is needed to get new users involved in working with Python on the Mac. Even some of the questions that you list here might be a little too complex for new users. The problem is that there are many kinds of new users. There are experienced programmers who understand the Mac, and are familiar with, say, Objective-C and Cocoa and Java, but are looking at Python for the first time. They want to know the things that Bob and Ron keep working on, things like How do a build an app in Python? and How do I use Cocoa, or Apple Events, or ... in Python? or How do I use Python with Xcode? And they want the Python tutorial. There are Python programmers coming from Windows or Linux, who want to know primarily how to get Python on their Mac, and what special things about the Mac they need to know to avoid tripping over their feet while using Python. They know about things like site-packages, but not about /Library vs. /System/Library, or frameworks, or various Apple-specific gcc bindings for dynamic linking. These two can be presented together.. the second set would be something like Python differences between Mac OS X and other platforms. Then there are people like Karl described yesterday in his story about the computer teacher descovering Python's turtle graphics, who are looking for low-entry (no installers) ways to do scripting or education. A good entry page tries to speak usefully to all of these communities at the same time, without speaking down to any of them. Do you really think that there is a large enough audience that would be willing to read pages of documentation, but not be willing to install anything? The situation Karl describes wouldn't have happened by the computer teacher's own hand.. it was only possible because someone knowledgeable was in the room to tell them about Python and also to give them a minimal UNIX crash course. A web page might be ammo for someone like Karl to give out, but it likely wouldn't have done anything for the teacher without Karl. With a downloadable package that sorts out all the issues that need to be documented, then we would be able to skirt the whole issue of the UNIX crash course. Download this package, double-click to install, double-click to start IDLE (or whatever) here. Yes, it might be easier for a teacher with 20 computers to teach rather than install, but how often is that the case? I also think that if we give people the option to use Python without installing anything, then they'll choose that option and be disappointed because the experience with a newer version has a few years more polish and bug fixes... and can simply get them farther because it doesn't have any of the limitations that the pre-installed one has. Another thing to consider would be to do something similar to Movable Python: http://www.voidspace.org.uk/python/movpy/ In this case we would distribute Python as an application, and that application when run by itself could have options to make this Python the default from Terminal or something. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
A good entry page tries to speak usefully to all of these communities at the same time, without speaking down to any of them. Do you really think that there is a large enough audience that would be willing to read pages of documentation, but not be willing to install anything? No. That's why the *first* page is so important. That's why I put the example of the terminal and type 'python' on there. I also think that if we give people the option to use Python without installing anything, then they'll choose that option and be disappointed because the experience with a newer version has a few years more polish and bug fixes... and can simply get them farther because it doesn't have any of the limitations that the pre-installed one has. Not for Python newbies. They've never *seen* the more advanced versions. Python 2.3 all by itself is a pretty nifty programming experience, to someone who's not a developer, but wants to write a script or a simple program. Experienced Python users will of course probably want to install the newer version first. With a downloadable package that sorts out all the issues that need to be documented, then we would be able to skirt the whole issue of the UNIX crash course. Download this package, double-click to install, double-click to start IDLE (or whatever) here. I agree. If the 2.4.x installer were bundled with TigerPython24Fix and some quick-start IDLE app into a single installer, that would be great, and an improvement over the current situation. (And could it please *not* have the word fix in the title?) By the way, Apple seems to believe that the educational environment is important. If someone wanted to write up a page called, How to get your Mac-using class started with Turtle graphics in 10 minutes, I think that would be a positive contribution. Another thing to consider would be to do something similar to Movable Python: http://www.voidspace.org.uk/python/movpy/ In this case we would distribute Python as an application, and that application when run by itself could have options to make this Python the default from Terminal or something. I like this idea, too. Can we make it happen? Any volunteers? Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 10, 2006, at 10:02 AM, [EMAIL PROTECTED] wrote: On Feb 10, 2006, at 11:27 AM, Bob Ippolito wrote: On Feb 10, 2006, at 7:24 AM, [EMAIL PROTECTED] wrote: On Feb 9, 2006, at 1:32 PM, Kevin Walzer wrote: If I'm a newbie, I'm going to go, Huh?, then shrug, and move on to Realbasic. There needs to be something double-clickable there for a newbie to use. PythonIDE, though it had many flaws, was useful this way. BTW, what happened to PyOXIDE? It had major bugs, but was promising as a next-generation basic IDE for Python development on the Mac. PyOXIDE isn't dead - it's just sleeping. Seriously, there are several issues: 1) Lack of available time 2) It mostly does everything _I_ need (I actually use it on a fairly regular basis, and I have no burning need to add new features) 3) It needs to basically be re-written - it started as an editor with python embedded in it (i.e., use the python.framework and the various python embedding routines). Unfortunately, with 2.4 and the corresponding PyObjC, that just plain doesn't work well - PyObjC pretty much requires the thing to be a PyObjC-based application (application embedded in python), instead of an application embedding python. That's not true, and I've told you the correct way to fix that... That's why py2app can build plugins. Perhaps requires is too strong a word - how about is easiest to use if instead? Still, the current architecture of PyOXIDE (links with Python.framework, and calls the various PyRun_SimpleString, PyRun_SimpleFile and other commands as listed at http:// ftp.python.org/doc/ext/embedding.html via various UI callbacks, tries to manage the GIL, etc...) has a high impedance match against the way PyObjC works (since it wants to take care of all the details for you, made worse when _that_ code does UI work). My point is that the better way is just to make PyOXIDE a py2app based creature from the start (and then python code calls the IDE framework), though moving all the python code into py2app generated plugins is an interesting option (with it's own benefits/drawbacks). It would work just fine if you were managing all that stuff correctly. PyObjC and py2app definitely manage the GIL correctly with the tests and field experience to prove it... If it were trivial to fix, I'd have done it already... I didn't say it was trivial, but it doesn't require a rewrite. The majority of the work would be removing code. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 10, 2006, at 10:44 AM, Bill Janssen wrote: A good entry page tries to speak usefully to all of these communities at the same time, without speaking down to any of them. Do you really think that there is a large enough audience that would be willing to read pages of documentation, but not be willing to install anything? No. That's why the *first* page is so important. That's why I put the example of the terminal and type 'python' on there. I also think that if we give people the option to use Python without installing anything, then they'll choose that option and be disappointed because the experience with a newer version has a few years more polish and bug fixes... and can simply get them farther because it doesn't have any of the limitations that the pre-installed one has. Not for Python newbies. They've never *seen* the more advanced versions. Python 2.3 all by itself is a pretty nifty programming experience, to someone who's not a developer, but wants to write a script or a simple program. Experienced Python users will of course probably want to install the newer version first. Yes, but someone who wants to write a script or a simple program and isn't a developer doesn't imply that they're a terminal jockey. If we get them a double-clickable installer that gets them at least IDLE, then they're set and they don't have to learn UNIX in the process. With a downloadable package that sorts out all the issues that need to be documented, then we would be able to skirt the whole issue of the UNIX crash course. Download this package, double-click to install, double-click to start IDLE (or whatever) here. I agree. If the 2.4.x installer were bundled with TigerPython24Fix and some quick-start IDLE app into a single installer, that would be great, and an improvement over the current situation. (And could it please *not* have the word fix in the title?) It *is* a fix, which is no longer necessary with the current branch (or if built on 2.4). Also, the installer has always had IDLE.app. Another thing to consider would be to do something similar to Movable Python: http://www.voidspace.org.uk/python/movpy/ In this case we would distribute Python as an application, and that application when run by itself could have options to make this Python the default from Terminal or something. I like this idea, too. Can we make it happen? Any volunteers? I'd look into it after we get universal framework build with current conventions out the door. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
Hi Bob, On Feb 10, 2006, at 10:15 AM, Bob Ippolito wrote: [snip] Do you really think that there is a large enough audience that would be willing to read pages of documentation, but not be willing to install anything? Yes. (Though there shouldn't need to be several pages of docs.) Many users (that I know of) ask themselves the following before downloading software, especially OSS software, and even more so for non-official builds: 1) Will this affect my existing install or do something I don't want it to do? 2) Can I uninstall it? 3) Are the promises that 'everything will work fine' on the web site really true? 4) What can I do if it DOES mess up my install and I can't install it / uninstaller doesn't work? Have you ever installed some third-party software that crapped on your machine in one way or another? Unfortunately, for most of us that's a rhetorical question, not a real one. ;-) In OSS, people just deal with this because often they know how to fix it themselves. It just pisses them off and tells them to stay away. For people who are less knowledgeable about that stuff, though, these are scary questions and because they feel they may not be able to correct the issue without a full restore, they don't install things on a whim. Application bundles are far less scary because you can just dump them in the trash, but with this kind of stuff you can't. And note, before *anyone* mistakes me, I'm not saying *anything* about the quality of the MacPython 2.4 package. I use it myself, and I think it's great. And lots of people will download it, no doubt. But new people don't have the sort of background with the community we do. They don't know who's on these lists, what kinds of software they produce, what their standards of quality are, etc. Some of those people would just like to avoid finding out those answers the hard way if they can, and I personally understand that feeling. Some basic information about what problems they could expect with Apple Python would let them prioritize what is most important to them, and what they can expect by going either route. For example, I'd do something like the following for a download section: Download the latest Python While Apple includes Python with OS X, their version does not get updated often and contains some bugs and potential issues, and cannot be used to deploy OS X application bundles. For these reasons, many people could benefit from upgrading their Python installation to the latest version from pythonmac.org. For more information, see the FAQ Differences between Apple's Python and MacPython 2.4?. See also What should I expect when upgrading to MacPython 2.4? To upgrade your Python, take the following steps: steps to install MacPython 2.4 here, I figure these will change if we get the path issues, etc. sorted out before it goes live, so I'll leave this blank for now The situation Karl describes wouldn't have happened by the computer teacher's own hand.. it was only possible because someone knowledgeable was in the room to tell them about Python and also to give them a minimal UNIX crash course. A web page might be ammo for someone like Karl to give out, but it likely wouldn't have done anything for the teacher without Karl. With a downloadable package that sorts out all the issues that need to be documented, then we would be able to skirt the whole issue of the UNIX crash course. Download this package, double-click to install, double-click to start IDLE (or whatever) here. Yes, it might be easier for a teacher with 20 computers to teach rather than install, but how often is that the case? I don't know; do you? What if there are lots of people like that not on these lists? What if they do these things but we just don't hear about it because right now it all just works fine? The community on the mailing lists are typically not representative of the entire community, be it Python or any other OSS project. Many, many people passively use software rather than actively become involved in the community. (This is the only Python list I'm on, for example, and it wasn't until I wanted to help Robin, Stefan and Jack move the wxPythonMac port forward that I was on wx lists either.) These passive users are completely 'under the radar' in terms of what we perceive the community to be, are they not? I'd rather assume many of these people do exist than that they don't, because I'd rather consider and address their needs rather than ignore them. As Ocham's Razor states, simple as possible but no simpler, and if we're just ignoring whole target groups of users, then I think we've moved towards too simple. And again, I'm not talking about support here, I'm talking about documentation. None of us has to support any user we don't want to support. I also think that if we give people the option to use Python without installing anything, then
Re: [Pythonmac-SIG] My stab at a new page
At 9:51 AM -0800 2/10/06, Bill Janssen wrote: The problem is that there are many kinds of new users. This is true. The trick, in my view, is to make sure to define terms when they are first used. That way, the actual beginners have a chance of following along and the more experienced new users will skim over that sentence or two and get to the meat of what they are trying to find out. I don't see any other useful way to serve everyone on a single getting started page without either setting the bar too high for true newbies or frustrating the more experienced folks. Links to pages for more detailed explanations can prevent the basic definitions from taking up too much room. But a simple sentence or two of introduction to each topic with novices in mind will go a long way toward eliminating assumptions of what people know. -Rodney ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Wed, 8 Feb 2006 20:29:34 PST Bill Janssen [EMAIL PROTECTED] wrote: I've made up a sample page, at http://bill.janssen.org/new-macpython-page.html. This is the kind of thing I'd like to see replace the page at http://www.python.org/download/download_mac.html. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig My Powerbook is gone for repairs, nothing much to do without it, so I have added some shapes and colours to Bill Janssen's page: https://univmail.cis.mcmaster.ca/~vinogri/mp/default.html I take no credit for this whatsoever, just hoping it will be useful as a template for pythonmac.org. Naturally, without Mac it's hard to make pictures, otherwise there would be more detailed instructions. Cheers, Ivan. ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
Rodney Somerstein wrote: . It would be really nice to have a more basic introduction to what py2app actually does. Why don't you write that, put it in the Wiki, then ask this list for technical review. That's what Wikis are for, and I think often recent newbies are the best people to write newbie docs, when you still remember what questions you have. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/ORR/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
Louis Pecora wrote: This seems to be where this argument goes: the user/newbies vs. the developers. I don't think so. This entire conversation is about supporting the newbies. The disagreements are about how best to do that. You shouldn't be forcing everyone to adopt a python system that then suits your marketing model. I know why I'm pushing for the Install the 2.4 version approach, and it's precisely to support newbies, not to fit a marketing model. If we make it clear that there is one Standard way to do python on the Mac, then it's easier for everyone: - Newbies don't have to make a decision they don't understand the implications of. - We don't have to field questions about more than one version. - When they need to add an extension package, there is only one set of pre-built packages to look at. - Extension package builders and maintainers only need to target one version, and as a result, more packages will work on the Mac. (you should see what's in the matplotlib setup.py: a fragile mess inside the darwin section, looking around for whether you're running fink, or darwinports, etc. so that libs can be found. What a pain!) Those are some of the reasons that I think we need to establish a single, standard, Recommended by the MacPython community version. The Apple python is simply not an option as that standard (for reasons very well discussed here!), so Bob's build is it, unless someone else steps up to make something different. None of this helps the power users: we can go build our own from source, use fink, whatever. Now the marketing: yes, the smaller the barrier to entry to getting someone hooked, the better. On some level, I generally prefer to get people started with an approach that will carry them far, rather than the easiest way to get started, then tell them they need to do it differently as they get going. However, I do think there is a real advantage to showing people a bit about python without them having to download or install something. I think we can accomplish this on the main page of pythonmac.org, with a link something like: New to Python? The 30 second quick start: That will link to a Wiki page that tells people how to fire up the terminal and print hello world, maybe do a mini wx app: there have been some good suggestions on this thread already. At the end of maybe 15 minutes worth (or maybe more, I'm not sure what's best) of getting started, point them to a page that talks about what kind of extension packages there are, and advise about why and how to install a new version. The goal is to show just enough to get newbies interested, then set them up with a system that will carry them well into their python career. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/ORR/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
Charles Hartman wrote: It seems to me (as *much* closer to a newbie than a developer) that simply recommending the download install of Python 2.4.x not only wouldn't put a major obstacle in the way of beginners, but wouldn't seem to, either. Exactly. It's not like anyone but Linux users expects everything to be pre-installed on their machine! You have to download something to try out RealBasic, or whatever, as well. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/ORR/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christopher Barker wrote: Louis Pecora wrote: This seems to be where this argument goes: the user/newbies vs. the developers. I don't think so. This entire conversation is about supporting the newbies. The disagreements are about how best to do that. You shouldn't be forcing everyone to adopt a python system that then suits your marketing model. I know why I'm pushing for the Install the 2.4 version approach, and it's precisely to support newbies, not to fit a marketing model. If we make it clear that there is one Standard way to do python on the Mac, then it's easier for everyone: - Newbies don't have to make a decision they don't understand the implications of. - We don't have to field questions about more than one version. - When they need to add an extension package, there is only one set of pre-built packages to look at. - Extension package builders and maintainers only need to target one version, and as a result, more packages will work on the Mac. (you should see what's in the matplotlib setup.py: a fragile mess inside the darwin section, looking around for whether you're running fink, or darwinports, etc. so that libs can be found. What a pain!) Those are some of the reasons that I think we need to establish a single, standard, Recommended by the MacPython community version. +1 for what Chris is advocating here. A good model for this is Tk Aqua: see http://tcltkaqua.sourceforge.net. For the past few years this has been the standard way to get the latest and greatest Tcl/Tk for the Mac. It's been superseded a bit by ActiveState's distribution, but because ActiveState has licensing restrictions, that's not for everyone. ActivePython is also an example to consider that's a little more relevant. Not to recommend ActivePython itself, as its licensing is more restrictive than the build that will result from this discussion, but it is a self-contained, easily-installed, well-documented, and up-to-date bundle of Python and packages. - -- Kevin Walzer iReveal: File Search Tool http://www.wordtech-software.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD7QBMJmdQs+6YVcoRAjwhAJ4hBw+Ne2VGWQ+/jsH1Wh8MYGka9QCcCwyA D5oEKIwaFMLXgy/juNZPGEA= =J/8l -END PGP SIGNATURE- ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 10, 2006, at 1:06 PM, Kevin Walzer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christopher Barker wrote: Louis Pecora wrote: This seems to be where this argument goes: the user/newbies vs. the developers. I don't think so. This entire conversation is about supporting the newbies. The disagreements are about how best to do that. You shouldn't be forcing everyone to adopt a python system that then suits your marketing model. I know why I'm pushing for the Install the 2.4 version approach, and it's precisely to support newbies, not to fit a marketing model. If we make it clear that there is one Standard way to do python on the Mac, then it's easier for everyone: - Newbies don't have to make a decision they don't understand the implications of. - We don't have to field questions about more than one version. - When they need to add an extension package, there is only one set of pre-built packages to look at. - Extension package builders and maintainers only need to target one version, and as a result, more packages will work on the Mac. (you should see what's in the matplotlib setup.py: a fragile mess inside the darwin section, looking around for whether you're running fink, or darwinports, etc. so that libs can be found. What a pain!) Those are some of the reasons that I think we need to establish a single, standard, Recommended by the MacPython community version. +1 for what Chris is advocating here. A good model for this is Tk Aqua: see http:// tcltkaqua.sourceforge.net. For the past few years this has been the standard way to get the latest and greatest Tcl/Tk for the Mac. It's been superseded a bit by ActiveState's distribution, but because ActiveState has licensing restrictions, that's not for everyone. ActivePython is also an example to consider that's a little more relevant. Not to recommend ActivePython itself, as its licensing is more restrictive than the build that will result from this discussion, but it is a self-contained, easily-installed, well-documented, and up-to-date bundle of Python and packages. The licensing issues with ActivePython were clarified last year: It is explicitly legal to redistribute self-contained application bundles (a la py2exe or py2app) built with ActiveState's distributions. This gives it a leg up on Apple's distro (which has no such clause; components of OS X are not redistributable), and makes it a candidate Python distribution for almost anyone. Personally, I have tried it out a bit on one of my machines and found a couple bugs that were quickly resolved. Nothing outstanding and nothing major, and the turnaround was quick. Currently, ActivePython on Mac OS X is almost exactly the same thing that we're going to be shipping with the universal build of 2.4.2. The differences will be: 1. They aren't shipping readline, we will 2. We'll probably ship universal first 3. I don't believe they have the PATH hack in their installer 4. They ship with an ActivePython icon for pythonw, we'll stick with the current icon. Currently, ActivePython's 2.4.2 distro is a pretty good solution over our 2.4.1 because it doesn't require the OS X 10.4 fix and it's Python 2.4.2 instead of 2.4.1... The other differences are negligible other than the fact that we ship readline and they don't. On Win32, there is more of a reason to use ActivePython because they ship win32all and its IDE (which is different from IDLE). Of course, that's just an install away with the python.org distro, but it's one less step. This would be roughly equivalent to us shipping PyObjC for Mac I guess. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 10, 2006, at 1:53 PM, Bob Ippolito wrote: On Feb 10, 2006, at 1:06 PM, Kevin Walzer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christopher Barker wrote: Louis Pecora wrote: This seems to be where this argument goes: the user/newbies vs. the developers. I don't think so. This entire conversation is about supporting the newbies. The disagreements are about how best to do that. You shouldn't be forcing everyone to adopt a python system that then suits your marketing model. I know why I'm pushing for the Install the 2.4 version approach, and it's precisely to support newbies, not to fit a marketing model. If we make it clear that there is one Standard way to do python on the Mac, then it's easier for everyone: - Newbies don't have to make a decision they don't understand the implications of. - We don't have to field questions about more than one version. - When they need to add an extension package, there is only one set of pre-built packages to look at. - Extension package builders and maintainers only need to target one version, and as a result, more packages will work on the Mac. (you should see what's in the matplotlib setup.py: a fragile mess inside the darwin section, looking around for whether you're running fink, or darwinports, etc. so that libs can be found. What a pain!) Those are some of the reasons that I think we need to establish a single, standard, Recommended by the MacPython community version. +1 for what Chris is advocating here. A good model for this is Tk Aqua: see http:// tcltkaqua.sourceforge.net. For the past few years this has been the standard way to get the latest and greatest Tcl/Tk for the Mac. It's been superseded a bit by ActiveState's distribution, but because ActiveState has licensing restrictions, that's not for everyone. ActivePython is also an example to consider that's a little more relevant. Not to recommend ActivePython itself, as its licensing is more restrictive than the build that will result from this discussion, but it is a self-contained, easily-installed, well-documented, and up-to- date bundle of Python and packages. The licensing issues with ActivePython were clarified last year: It is explicitly legal to redistribute self-contained application bundles (a la py2exe or py2app) built with ActiveState's distributions. This gives it a leg up on Apple's distro (which has no such clause; components of OS X are not redistributable), and makes it a candidate Python distribution for almost anyone. Personally, I have tried it out a bit on one of my machines and found a couple bugs that were quickly resolved. Nothing outstanding and nothing major, and the turnaround was quick. Currently, ActivePython on Mac OS X is almost exactly the same thing that we're going to be shipping with the universal build of 2.4.2. The differences will be: 1. They aren't shipping readline, we will 2. We'll probably ship universal first 3. I don't believe they have the PATH hack in their installer 4. They ship with an ActivePython icon for pythonw, we'll stick with the current icon. 5. We're also shipping some bug fixes that aren't in Python yet, like doing the select.poll check at runtime instead of configure time. Mac OS X 10.4.4 has a fully working poll implementation, but I believe some point version back in the day didn't. Some applications depend on select.poll and associated constants being there. I can't think of anything open source at the moment, but I know people who have internal apps that depend on poll because it has higher performance for their deployment environment. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
Nice, thanks! Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
If we get them a double-clickable installer that gets them at least IDLE, then they're set and they don't have to learn UNIX in the process. I agree. It looks like one good thing to do would be to build an installer that installs a regular App that's just a wrapper around IDLE (and uses the system Python). People who just want to try Python but don't want to install a complete separate version could use this. Though it sounds like there are some technical issues about just running IDLE on 10.3 and 10.4. Maybe this can't be done. The upgrade installer should also include and install such an App, but this App (though looking identical to the other) would use the 2.4.x upgrade install of Python. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
Bob Ippolito wrote: Currently, ActivePython on Mac OS X is almost exactly the same thing that we're going to be shipping with the universal build of 2.4.2. The differences will be: 1. They aren't shipping readline, we will This matters quite a bit, I think. 2. We'll probably ship universal first Always good to be on the bleeding edge! 3. I don't believe they have the PATH hack in their installer That matters too: we've spent enough time nattering on about that to prove it! 4. They ship with an ActivePython icon for pythonw, we'll stick with the current icon. I don't give a *^^ what the icon is. I don't know why, but somehow I feel better about depending on Bob I., than I do about depending on ActiveState. As long as Bob os willing to build what we've been discussing, I say we go with that. There does need to be a mention of other Python installers somewhere anyway, and ActiveState should certainly be listed. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/ORR/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
I agree. If the 2.4.x installer were bundled with TigerPython24Fix and some quick-start IDLE app into a single installer, that would be great, and an improvement over the current situation. (And could it please *not* have the word fix in the title?) It *is* a fix, which is no longer necessary with the current branch (or if built on 2.4). Does that mean that if I download the 2.4.x upgrade installer and run it on my 10.4.4 machine, I do not need to run the TigerPython24Fix? Why do I need to run it separately anyway? Why isn't just part of the regular upgrade installer, run if necessary? And for that matter, why not include TigerPython23Compat as part of the MacPython installer? And how about bundling tcltkaqua into it, as well? Also, the installer has always had IDLE.app. I'm glad to hear that about IDLE.app. But I'm depressed again when I read pages like http://rlai.cs.ualberta.ca/RLAI/RLsoftware/PythonLinks.html#IDLE. My impression from reading that is that MacPython IDLE.app is extensively broken. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 10, 2006, at 2:22 PM, Bill Janssen wrote: If we get them a double-clickable installer that gets them at least IDLE, then they're set and they don't have to learn UNIX in the process. I agree. It looks like one good thing to do would be to build an installer that installs a regular App that's just a wrapper around IDLE (and uses the system Python). People who just want to try Python but don't want to install a complete separate version could use this. Though it sounds like there are some technical issues about just running IDLE on 10.3 and 10.4. Maybe this can't be done. 10.3 doesn't ship with Tkinter at all, so it can't be done there without also installing Tcl/Tk Aqua. We'd have to document that for users of Mac OS X 10.3; I don't want to bundle it. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
This would be roughly equivalent to us shipping PyObjC for Mac I guess. Which I'd recommend. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
Charles Hartman wrote: It seems to me (as *much* closer to a newbie than a developer) that simply recommending the download install of Python 2.4.x not only wouldn't put a major obstacle in the way of beginners, but wouldn't seem to, either. Exactly. It's not like anyone but Linux users expects everything to be pre-installed on their machine! You have to download something to try out RealBasic, or whatever, as well. -Chris I don't know about that. The Mac philosophy is something like, It just works. I hear that a lot from new Mac users around here. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 10, 2006, at 2:31 PM, Bill Janssen wrote: I agree. If the 2.4.x installer were bundled with TigerPython24Fix and some quick-start IDLE app into a single installer, that would be great, and an improvement over the current situation. (And could it please *not* have the word fix in the title?) It *is* a fix, which is no longer necessary with the current branch (or if built on 2.4). Does that mean that if I download the 2.4.x upgrade installer and run it on my 10.4.4 machine, I do not need to run the TigerPython24Fix? Why do I need to run it separately anyway? Why isn't just part of the regular upgrade installer, run if necessary? I'm tired of saying this. ONE last time. TigerPython24Fix fixes a bug in the current release (it's questionable as to if it's a bug in 10.4, or the build of 2.4, but it's a bug nonetheless). Discussing this is completely irrelevant because it's an already solved issue. Please forget it exists - I'm tired of discussing it. And for that matter, why not include TigerPython23Compat as part of the MacPython installer? TigerPython23Compat allows OS X 10.4's installation Python 2.3 to use packages built with OS X 10.3. Not very relevant to a Python 2.4. And how about bundling tcltkaqua into it, as well? Tcl/Tk Aqua ships with OS X 10.4 and it's a relatively large dependency to just include for the sake of OS X 10.3 users. Also, the installer has always had IDLE.app. I'm glad to hear that about IDLE.app. But I'm depressed again when I read pages like http://rlai.cs.ualberta.ca/RLAI/RLsoftware/PythonLinks.html#IDLE. My impression from reading that is that MacPython IDLE.app is extensively broken. Those are reasons not to use IDLE with the built-in Python 2.3. Those issues are all trivial to fix for any build that we produce. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 10, 2006, at 2:34 PM, Bill Janssen wrote: Charles Hartman wrote: It seems to me (as *much* closer to a newbie than a developer) that simply recommending the download install of Python 2.4.x not only wouldn't put a major obstacle in the way of beginners, but wouldn't seem to, either. Exactly. It's not like anyone but Linux users expects everything to be pre-installed on their machine! You have to download something to try out RealBasic, or whatever, as well. I don't know about that. The Mac philosophy is something like, It just works. I hear that a lot from new Mac users around here. Working properly and shipping with everything you could possibly need are two entirely different things. When they download RealBasic it just works, but it didn't come with their Mac. When they download the new Python 2.4 framework, it will be closer to just working -- but it won't be fully Mac-like until there's the movable python inspired version available that does not have a required installation procedure. The Python 2.3 build that ships with 10.3 and 10.4 definitely does not just work unless you're looking to do purely UNIX based things and you don't need to use distutils (e.g. by default scripts go to / System/.../nowhere/bin which requires root to install to and doesn't live on the PATH). The current Python 2.4.x releases aren't a hell of a lot better at just working, but the Python 2.4 builds we *will* be shipping do a much better job approximating that ideology (PATH hack, better documentation, fixes to distutils and the installation layout, etc.). Personally I don't find Linux to just work at all as a developer. If I need a package outside of their package management system I have to go f*!(ing crazy figuring out which *-dev packages i need to install in order to get it to configure and make install correctly. I often need bleeding edge software such as the latest Python and PostgreSQL release. Maybe I just hate Debian, this probably isn't an issue with all (most?) Linux distributions. *BSD and Mac OS X don't have this problem because they ship packages with all the headers and such installed. Much easier to get what I need done. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
For these reasons, many people could benefit from upgrading their Python installation to the latest version from pythonmac.org. For more information, see the FAQ Differences between Apple's Python and MacPython 2.4?. See also What should I expect when upgrading to MacPython 2.4? To upgrade your Python, take the following steps: Kevin, That would be a great addition! Could you please make these pages exist in the Wiki and add FAQ entries to point to them? Thanks! Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
I've put up a new page, with a slightly different address: http://bill.janssen.org/mac/new-macpython-page.html. It includes pointers to the Wiki and the FAQ, leads with the suggestion to upgrade, keeps the simple example, but drops the use of IDLE, and no longer points to the (seriously damaged) existing standard MacPython documentation. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
Bill Janssen wrote: I don't know about that. The Mac philosophy is something like, It just works. I hear that a lot from new Mac users around here. Linux users expect it to be installed already, or come with their distro, but don't expect it to work without tweaking config files. ;-) Mac users expect to have to buy it or download it and install it, but then expect it to just work. That's changed a bit with OS-X and all the nice i* apps, but you still can't get that much real work done on a Mac without installing some software. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/ORR/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 10, 2006, at 3:37 PM, Bill Janssen wrote: I've put up a new page, with a slightly different address: http://bill.janssen.org/mac/new-macpython-page.html. It includes pointers to the Wiki and the FAQ, leads with the suggestion to upgrade, keeps the simple example, but drops the use of IDLE, and no longer points to the (seriously damaged) existing standard MacPython documentation. For reference: 10.0 - Cheetah 10.1 - Puma 10.2 - Jaguar 10.3 - Panther 10.4 - Jaguar 10.5 - Leopard Also, the trademark is Mac OS X not MacOS X or Mac-OS/X or MACOSX ;) -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 10, 2006, at 5:31 PM, Bill Janssen wrote:And how about bundling tcltkaqua into it, as well? Because some of us, at least, have no interest in tcl. I'm not clear whether its presence interferes with wx (thing #421 that I'm not clear about), but it doesn't help; why should I want it on my system?The answer might be, because Apple puts it in their (therefore in mine). Is that true? Anyway I'm not clear about the logic of this.Charles___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 10, 2006, at 5:34 PM, Bill Janssen wrote: Charles Hartman wrote: It seems to me (as *much* closer to a newbie than a developer) that simply recommending the download install of Python 2.4.x not only wouldn't put a major obstacle in the way of beginners, but wouldn't seem to, either. Exactly. It's not like anyone but Linux users expects everything to be pre-installed on their machine! You have to download something to try out RealBasic, or whatever, as well. -Chris I don't know about that. The Mac philosophy is something like, It just works. I hear that a lot from new Mac users around here. The audience we're imagining is one looking to branch out a little -- into programming, to begin with, into Python in particular. If that involves downloading something, that's perfectly familiar territory. If I were a Mac user interested in a new approach to word processing I'd expect to download Nisus Writer, or whatever. (For that matter, Word doesn't come free on Macs.) I think the Python is parallel, from that psychological standpoint. (The fact that Apple ships a version of Python is a red herring here.) Charles ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
If I need a package outside of their package management system I have to go f*!(ing crazy figuring out which *-dev packages i need to install in order to get it to configure and make install correctly. Agreed. I'd like that to be different with MacPython. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
For reference: 10.0 - Cheetah 10.1 - Puma 10.2 - Jaguar 10.3 - Panther 10.4 - Jaguar 10.5 - Leopard Also, the trademark is Mac OS X not MacOS X or Mac-OS/X or MACOSX ;) Sorry, Housecat was a (temporary) joke. I'll fix the Mac OS X refs. Though, frankly, I don't care what the trademark is, and I think people tend in real usage to use MacOS. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
Please forget [TigerPython24Fix] exists - I'm tired of discussing it. Fine. The next installer won't have it or need it, and I'll remove the bit about it on my sample page. And for that matter, why not include TigerPython23Compat as part of the MacPython installer? TigerPython23Compat allows OS X 10.4's installation Python 2.3 to use packages built with OS X 10.3. Not very relevant to a Python 2.4. OK, thanks. And how about bundling tcltkaqua into it, as well? Tcl/Tk Aqua ships with OS X 10.4 and it's a relatively large dependency to just include for the sake of OS X 10.3 users. But IDLE.app won't work without it on 10.3, if I read this correctly. It doesn't have to install on 10.4, the pre-flight scripts can check this. Also, the installer has always had IDLE.app. I'm glad to hear that about IDLE.app. But I'm depressed again when I read pages like http://rlai.cs.ualberta.ca/RLAI/RLsoftware/PythonLinks.html#IDLE. My impression from reading that is that MacPython IDLE.app is extensively broken. Those are reasons not to use IDLE with the built-in Python 2.3. Those issues are all trivial to fix for any build that we produce. OK, great. The Alberta page was referring to the IDLE.app that came with the MacPython installer; so that's just something to put on the TODO list for the installer. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
And how about bundling tcltkaqua into it, as well? Because some of us, at least, have no interest in tcl. I'm not clear whether its presence interferes with wx (thing #421 that I'm not clear about), but it doesn't help; why should I want it on my system? Because you can't run IDLE without it. Maybe in a perfect world we'll have an installer that will allow you to do a custom install and uncheck the tcltkaqua entry before running the install. The answer might be, because Apple puts it in their (therefore in mine). Is that true? Anyway I'm not clear about the logic of this. Apparently, for 10.4. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
The audience we're imagining is one looking to branch out a little -- into programming, to begin with, into Python in particular. That's *one* of the audiences. If that involves downloading something, that's perfectly familiar territory. If I were a Mac user interested in a new approach to word processing I'd expect to download Nisus Writer, or whatever. (For that matter, Word doesn't come free on Macs.) I think the Python is parallel, from that psychological standpoint. (The fact that Apple ships a version of Python is a red herring here.) I think I agree with this. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 10, 2006, at 5:34 PM, Bill Janssen wrote: And how about bundling tcltkaqua into it, as well? Because some of us, at least, have no interest in tcl. I'm not clear whether its presence interferes with wx (thing #421 that I'm not clear about), but it doesn't help; why should I want it on my system? Because you can't run IDLE without it. Maybe in a perfect world we'll have an installer that will allow you to do a custom install and uncheck the tcltkaqua entry before running the install. I think it's safe to have a note that says something like this -- Attention Mac OS X 10.3 users: To use IDLE (the Python IDE) and other Tkinter based applications, you must first install tcltkaqua. Better than adding 3 or 4 MB to the download. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 10, 2006, at 8:22 PM, Bill Janssen wrote:Though, frankly, I don't care what the trademark is, and I think people tend in real usage to use "MacOS". Well . . . not for people I know. "OSX" ["OS X"] is more common in my experience, especially among those aware that OS9 was a Mac OS.And I suspect we *do* care what the trademark is -- this isn't a sanctioned Apple website, but isn't there some value to conforming to the mother ship's ways?Charles___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
I've updated it to take into account Bob's comments. http://bill.janssen.org/mac/new-macpython-page.html. It still kind of assumes that the installers will automagically do everything that needs doing. I assume that will be truer with the universal installer. Should there be a paragraph just before the one that starts, As a bonus, saying something about how to run IDLE.app once you've downloaded and installed the upgrade? Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
At 11:58 AM -0800 2/10/06, Christopher Barker wrote: Rodney Somerstein wrote: . It would be really nice to have a more basic introduction to what py2app actually does. Why don't you write that, put it in the Wiki, then ask this list for technical review. That's what Wikis are for, and I think often recent newbies are the best people to write newbie docs, when you still remember what questions you have. Thanks for the suggestion. I suppose I should have expected this when I posted. While I can explain the basic concept of what py2app does, my knowledge pretty much stops there. Given that I'm not much beyond the helloworld level or using Python right now, I will decline for the moment. Due to time constraints, I will not likely move much beyond this in the short-term future. So, I could write one to two sentences that it takes to explain the purpose of py2app. Beyond that, someone else would need to fill in the details. -Rodney ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
Bill Janssen wrote: Problem with the official Mac-specific modules and documentation is there's quite of stuff in there that hasn't been correct/usable since OS 9. It's just that nobody's gotten around to dealing with it. Experienced users already know which bits to avoid, so there's not huge impetus to clean it out properly. Doesn't mean you want to steer newbies towards it though. It sounds like we should ask the Python-doc folks to remove the Macintosh docs entirely. Maybe post it with appropriate warnings on pythonmac.org instead. Might be a good idea; there's probably more discouraging cruft than useful stuff in it right now, and it'd probably be quicker to clean it up separately and resubmit afterwards (assuming anything's left:) than submit piles of individual patches against it in-situ. has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bill Janssen wrote: I'm conflicted about pythonw. On the one hand, this works for everything, whereas python doesn't. On the other hand, why isn't this just what python invokes, and how do we explain that to people? Another example of the surface complexity of the MacPython infrastructure. pythonw invokes GUI applications, python invokes console applications. When installing an extension, I don't type pythonw setup.py install. - -- Kevin Walzer iReveal: File Search Tool http://www.wordtech-software.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD64DHJmdQs+6YVcoRAuAZAJ9QkZVwkcl4owAMzWkNiRXQvvKNzgCfRD56 NrogiTxFiOOkz7vvd+3psM0= =tQys -END PGP SIGNATURE- ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
I fixed a couple of the problems Bob noted, and added some links to pictures (how to start the Terminal, and what the IDLE IDE looks like). Looks good... But I would suggest... Python on the Macintosh You're in luck! Python comes pre-installed on Apple's Macintosh series of computers that run OS X, for versions of OS X greater than 10.1. is a little clumsy... How about Python on the Macintosh Any Mac OS X (10.1+) users are in luck! Python comes pre-installed on every Macintosh that is running OS X 10.1 or higher. Since Apple has nicely included Python with their Operating systems you can get started simply by opening a terminal window (see below). Once you have experimented with Python you may want to consider upgrading to a newer version of Python. For details on upgrading, see If you want a newer version of Python below. - Benjamin ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
pythonw invokes GUI applications, python invokes console applications. When installing an extension, I don't type pythonw setup.py install. But you could. No, my conceptual problem is just that you shouldn't need that extra w, and once you start explaining why it's there, there's no good place to stop. You start bushwhacking into a thicket of MacPython complexity which scares people away. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
I fixed a couple of the problems Bob noted, and added some links to pictures (how to start the Terminal, and what the IDLE IDE looks like). I like it. I'm conflicted about pythonw. On the one hand, this works for everything, whereas python doesn't. On the other hand, why isn't this just what python invokes, and how do we explain that to people? Is it used a lot? Then you would probably need to describe both, with something like: You can run a Python interpreter by double-clicking on Applications / Utilities / Terminal, then typing python or pythonw into the window that opens up. Typing pythonw will prompt Terminal to provide the subsequent python prompt to (do whatever it is that pythonw does) Otherwise, the normal python prompts will not be able to (do whatever it is that pythonw does) Most people find that typing pythonw gives them more options they find useful when programming in python. Another example of the surface complexity of the MacPython infrastructure. I would suggest this: On MacOS X 10.4 (Tiger) you can even bring up a simple IDE by typing, at the prompt, to On MacOS X 10.4 (Tiger) you can even bring up a simple Integrated Developement Environment (IDE) by typing, at the prompt, Bill I've made up a sample page, at http://bill.janssen.org/new-macpython-page.html ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 9, 2006, at 10:52 AM, Bill Janssen wrote: pythonw invokes GUI applications, python invokes console applications. When installing an extension, I don't type pythonw setup.py install. But you could. No, my conceptual problem is just that you shouldn't need that extra w, and once you start explaining why it's there, there's no good place to stop. You start bushwhacking into a thicket of MacPython complexity which scares people away. If we recommend that the user installs a particular framework build of Python, we could distribute it such that python and pythonw are indistinguishable. This issue then disappears. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 9, 2006, at 11:32 AM, Kevin Walzer wrote: 4. Maintainer: does Python on the Mac even have an official maintainer anymore? Has Jack Jansen resigned? Is it maintainer-by-committee? I can't help but think this is part of the reason Python seems adrift as a Mac development platform: the group is having a hard time even agreeing on who it's serving (hard-core developers? newbies?). The outstanding technical support we are getting from the experts such as Bob, for instance in terms of building universal binaries, is getting the most essential daily tasks done; but this isn't the same as having a leadership focus to actually make strategic decisions about Python on the Mac platform. I mention this because I think it's important to state accurately how Python on the Mac is maintained: by a loose group of experts rather than a dedicated maintainer. That will help people know what to expect. Python does not currently have an official Mac maintainer. Jack hasn't officially resigned, but he has been too busy for probably a few years now. I'm too busy to do real maintenance. Nobody else has stepped up. It's currently somewhat of a maintainer-by-necessity. The people doing the maintenance are mostly just Ronald and I, with bits and pieces filled by other members of the Python development community that happen to use Mac OS X as well. The people currently doing maintenance tasks are doing it mostly because they need it done for their own work. Once it's fixed enough for them to use, it sits and waits until there's another problem. Clearly the current distribution and the people responsible for it aren't going very far to serve newbies... -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
That's exactly the kind of fix that -- together with a handful of others -- could make this make-over work. Incorporating the TigerPython24Fix and TigerPython23Compat patches would be another small, huge step. Can the 2.4 installer look at the system and decide which of these is needed? The third piece is a front-end script (part of the installer?? that would be ideal) that checks the user's shell (bash, tcsh, etc) and, perhaps after asking permission, adds the relevant thing to the path. Charles Charles On Feb 9, 2006, at 2:41 PM, Bob Ippolito wrote: On Feb 9, 2006, at 10:52 AM, Bill Janssen wrote: pythonw invokes GUI applications, python invokes console applications. When installing an extension, I don't type pythonw setup.py install. But you could. No, my conceptual problem is just that you shouldn't need that extra w, and once you start explaining why it's there, there's no good place to stop. You start bushwhacking into a thicket of MacPython complexity which scares people away. If we recommend that the user installs a particular framework build of Python, we could distribute it such that python and pythonw are indistinguishable. This issue then disappears. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 9, 2006, at 11:55 AM, Charles Hartman wrote: That's exactly the kind of fix that -- together with a handful of others -- could make this make-over work. Incorporating the TigerPython24Fix and TigerPython23Compat patches would be another small, huge step. Can the 2.4 installer look at the system and decide which of these is needed? TigerPython24Fix is irrelevant for the next build. TigerPython23Compat only allows the system Python 2.3 to use packages targetted for the system Python 2.3 on Mac OS X 10.3. The third piece is a front-end script (part of the installer?? that would be ideal) that checks the user's shell (bash, tcsh, etc) and, perhaps after asking permission, adds the relevant thing to the path. Yeah, this would likely be a post-install script in a sub-pkg that the user could disable using the Customize function. It would happen by default. It's somewhat difficult to present the user a forced choice during the installer, especially considering they might be doing it headless (e.g. with Apple Remote Desktop, or as a sub-pkg of some larger mpkg), with /usr/sbin/installer, etc. Charles Charles On Feb 9, 2006, at 2:41 PM, Bob Ippolito wrote: On Feb 9, 2006, at 10:52 AM, Bill Janssen wrote: pythonw invokes GUI applications, python invokes console applications. When installing an extension, I don't type pythonw setup.py install. But you could. No, my conceptual problem is just that you shouldn't need that extra w, and once you start explaining why it's there, there's no good place to stop. You start bushwhacking into a thicket of MacPython complexity which scares people away. If we recommend that the user installs a particular framework build of Python, we could distribute it such that python and pythonw are indistinguishable. This issue then disappears. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
At 8:29 PM -0800 2/8/06, Bill Janssen wrote: I've made up a sample page, at http://bill.janssen.org/new-macpython-page.html. This is the kind of thing I'd like to see replace the page at http://www.python.org/download/download_mac.html. Bill, As the sort of somewhat sophisticated novice python developer (how is that for a contradiction of terms?) that you folks seem to be targeting, I really like this page. It could use a little bit of cleaning up, such as possibly describing why to use IDLE, how using a newer version of Python can help the user, etc. It is a great start. I look forward to seeing something as straightforward as this replacing the current page. Now, what I really want to see added is something that explains how I can write a program in Python on the Mac and create standalone applications that can run on someone else's computer without them having to install anything else. The descriptions of packaging for Python that I have read here are fairly arcane and not at all straightforward for new developers. As much as I like the general idea of Python, this is the one thing that seems to make the language not ready for end-user applications. It might seem that this isn't Mac specific. But, since the packaging of Python apps on the Mac seems to be different than on other platforms, having a link to it from the main page would be a useful thing. It could certainly be far down the page rather than right at the beginning. Even better would be a discussion of how to move such apps to other operating systems as well. Python may be more elegant than Java, but I can easily give someone a Java app to run on their computer. I'm not confident I could do this for much beyond helloworld with Python and expect it to run since there wouldn't likely be the libraries that I need. Thanks, -Rodney ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
1. Link to the Macintosh Library Module: A lot of that stuff will be rendered obsolete the minute Bob releases the universal build of MacPython. PythonIDE, Package Manager, etc.: not gonna be included. At a minimum, you should note that this stuff is legacy. Also, who writes this stuff and where should a bug be filed? 2. Ditto for Apple Events. Does anyone use gensuitemodule or even know what it means? (I don't.) I don't use appscripting, but I do know enough to know that it's pretty much the standard way (by now) of accessing Apple Events? has, what do you think? Hey, I'm linking to the official documentation. That's what people will use, till it changes. All this other stuff scattered around is blue-sky wild-ass future, till it's documented. You can file documentation bugs at http://sourceforge.net/bugs/?group_id=5470. I'd suggest category Documentation, group Platform-specific. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
Python does not currently have an official Mac maintainer. Bingo! And no one has stepped up to document the amazing torrent of productive activity since Jack retired. As a result, the useful pieces are scattered all over, the official documentation is wildly out of date, and there's not even a useful web page for MacPython. Add to this the fact that the pre-installed Python is widely held to be useless by well-respected and influential members of the community. A parochial and self-defeating assessment, I think. By the way, is anyone a designated point-man to work with Apple on the release it packages for the next OS? Is there anyone from Apple even on this list? Clearly the current distribution and the people responsible for it aren't going very far to serve newbies... It's worse than that, IMO. I've got a great deal of respect and appreciation for those, like Bob and Ronald, working hard on advancing the technology pieces. Great work, just what we all need! But unless there's some effective delivery vehicle for getting that work to the customer, much of it will be wasted. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 9, 2006, at 12:38 PM, Bill Janssen wrote: Python does not currently have an official Mac maintainer. Bingo! And no one has stepped up to document the amazing torrent of productive activity since Jack retired. As a result, the useful pieces are scattered all over, the official documentation is wildly out of date, and there's not even a useful web page for MacPython. Add to this the fact that the pre-installed Python is widely held to be useless by well-respected and influential members of the community. A parochial and self-defeating assessment, I think. It is useless to me. I can't build redistributable applications with it, and it has VM bugs that cause some of my programs to crash without reason. It's a support nightmare because it's different for every release of OS X. 10.3 has 2.3.0 with just CoreGraphics, 10.4 has 2.3.5 with wx, CoreGraphics and tkinter, who knows what 10.5 will have. If we tell everyone to use a particular 2.4.2 release then we don't have to deal with any of that nonsense. It's also showing its age -- some software packages are starting to require or strongly recommend Python 2.4 for usage (e.g. TurboGears). The minimal effort it takes to use a third party installation of Python is well worth it, and it becomes more useful as time goes on. Doubly so now that Leopard is approaching, because users can upgrade without losing all of their Python work to major version upgrade death. It's great and convenient that Apple ships a Python interpreter, but it's only useful for running a subset of UNIX based Python applications and scripts. I don't think it should even be a consideration for people writing software with Python. By the way, is anyone a designated point-man to work with Apple on the release it packages for the next OS? Is there anyone from Apple even on this list? I don't know if anyone in Cupertino is on this list, but I have contacts at Apple. I was more or less the point person for the last release. Clearly the current distribution and the people responsible for it aren't going very far to serve newbies... It's worse than that, IMO. I've got a great deal of respect and appreciation for those, like Bob and Ronald, working hard on advancing the technology pieces. Great work, just what we all need! But unless there's some effective delivery vehicle for getting that work to the customer, much of it will be wasted. It's not a waste because the work done helps me accomplish what I need to do. I do it because I need it to be done, not because I want to help people. I do a lot of things to help people, but that's rarely ever my primary motivation in the context of open source. There's an open invitation for someone to coddle new users and maintain a straightforward web presence. We all know that it would be beneficial, and it's time for someone to step up and do it already. It's been discussed ad nauseam for the past few years, but talking apparently doesn't make anything happen. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 9, 2006, at 12:09 PM, Rodney Somerstein wrote: At 8:29 PM -0800 2/8/06, Bill Janssen wrote: I've made up a sample page, at http://bill.janssen.org/new-macpython-page.html. This is the kind of thing I'd like to see replace the page at http://www.python.org/download/download_mac.html. Bill, As the sort of somewhat sophisticated novice python developer (how is that for a contradiction of terms?) that you folks seem to be targeting, I really like this page. It could use a little bit of cleaning up, such as possibly describing why to use IDLE, how using a newer version of Python can help the user, etc. It is a great start. I look forward to seeing something as straightforward as this replacing the current page. Now, what I really want to see added is something that explains how I can write a program in Python on the Mac and create standalone applications that can run on someone else's computer without them having to install anything else. The descriptions of packaging for Python that I have read here are fairly arcane and not at all straightforward for new developers. As much as I like the general idea of Python, this is the one thing that seems to make the language not ready for end-user applications. It might seem that this isn't Mac specific. But, since the packaging of Python apps on the Mac seems to be different than on other platforms, having a link to it from the main page would be a useful thing. It could certainly be far down the page rather than right at the beginning. Even better would be a discussion of how to move such apps to other operating systems as well. Python may be more elegant than Java, but I can easily give someone a Java app to run on their computer. I'm not confident I could do this for much beyond helloworld with Python and expect it to run since there wouldn't likely be the libraries that I need. py2app is the solution for application packaging, and you must use it with a third party Python installation (e.g. Python 2.4.1) in order to come up with something that's redistributable and robust. If you happen to use the system Python, then you will produce a package that only runs on the particular release of Mac OS X that you build it with. In other words, when you or your users upgrade to Mac OS X 10.5, any system-Python built application bundle will cease to function at all. It is actually not much different than on other platforms. Many py2exe-based setup scripts work identically with py2app if you change the import statement. Mac-specific features of course require Mac- specific solutions, but the standard stuff is identical. There is some minimal documentation: http://undefined.org/python/ py2app.html Any other questions you have can probably be answered by py2exe documentation and/or this list. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Wed, 8 Feb 2006 20:29:34 PST Bill Janssen [EMAIL PROTECTED] wrote: I've made up a sample page, at http://bill.janssen.org/new-macpython-page.html. What about other sources for python2.4 such as fink and darwinports? Will they be frown upon or required to comply with framework installation? Regards, Ivan. ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 9, 2006, at 12:20 PM, I. Vinogradov wrote: On Wed, 8 Feb 2006 20:29:34 PST Bill Janssen [EMAIL PROTECTED] wrote: I've made up a sample page, at http://bill.janssen.org/new-macpython-page.html. What about other sources for python2.4 such as fink and darwinports? Will they be frown upon or required to comply with framework installation? It's the job of Fink or DarwinPorts to sustain their Python communities. There are already too many choices, I'd really like to avoid even more confusion. Also, the topic of Fink and DarwinPorts rarely ever comes up on this list, so there isn't much reason for us to bother. The way that Python is used in such an environment is closer to how it is used on a Linux or BSD distribution, given that it has managed packages and is only usable from a shell. They are also like a separate operating system, typically the only library they use from Mac OS X is libSystem -- they duplicate almost everything else. I don't know if anything has changed in the past two years, but neither offered a framework build last I checked -- which means that neither are capable of running GUI applications from the shell (unless X11 counts). You can still technically use them to build GUI apps via py2app, but I certainly wouldn't recommend either of those platforms for that purpose. If you do happen to build a redistributable app with DarwinPorts or Fink, you'll essentially be redistributing an OS and a Python interpreter because those systems have their own versions of almost everything. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
Now, what I really want to see added is something that explains how I can write a program in Python on the Mac and create standalone applications that can run on someone else's computer without them having to install anything else. Great idea, Rodney. I think we probably need a number of pages like this, kind of an FAQ set. I think the main page should just cover one or two things (how to run python, how to upgrade), and lots of pointers to these pages. Each of these should be fairly clear, with pointers off to more complicated explanations. Here's the start of a list: 1) What's the difference between python and pythonw? 2) What's the advantage of upgrading? 3) What do I do if I want to use pre-built packages? 4) How do I use the Apple GUI toolkit from Python? 5) How do I use Apple Events from Python? 6) How do I build a real Mac application written in Python? 7) How do I install extra modules, like PIL, for the system Python? 8) What IDE's are available, and what are their relative merits? Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
It is useless to me. That's what I mean by parochial. Bob, I completely understand and sympathize with what you are saying here. And for your purposes, these are completely legitimate complaints. But there are lots of pure Unix programs which it works quite well for. I do a lot of text processing, web-page re-writing, web spidering, etc. which works fine with the pre-installed Python. I do image0-processing with PIL and PDF generation with ReportLab which works fine. And to not support -- even celebrate -- those uses is, IMO, self-defeating. The minimal effort it takes to use a third party installation of Python is well worth it, and it becomes more useful as time goes on. Doubly so now that Leopard is approaching, because users can upgrade without losing all of their Python work to major version upgrade death. To begin with, I don't see a stability in the current state of MacPython that gives me confidence in this assurance. But I agree that the effort of installation is minimal, and should be encouraged. Should we officially encourage Apple not to include Python in their next release? That would solve lots of these problems, I think. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 9, 2006, at 1:48 PM, Bill Janssen wrote: It is useless to me. That's what I mean by parochial. Bob, I completely understand and sympathize with what you are saying here. And for your purposes, these are completely legitimate complaints. I'd say pragmatic, not parochial. I understand your concerns but why should we spend our precious and limited resources bothering with a Python distribution that can only support a subset of uses. If we ignore the vendor's interpreter then our documentation becomes MUCH simpler as there will be one -- and preferably only one -- way to do it: install a Python interpreter that is recent and can run the full scope of Python applications. We also get to ignore the issues of which version of Mac OS X they are using because 10.3 and 10.4 will behave the same, and we have the opportunity to fix the issues that constantly plague users such as python vs pythonw (we can simply make the symlinks in /usr/local/bin both point at pythonw). But there are lots of pure Unix programs which it works quite well for. I do a lot of text processing, web-page re-writing, web spidering, etc. which works fine with the pre-installed Python. I do image0-processing with PIL and PDF generation with ReportLab which works fine. And to not support -- even celebrate -- those uses is, IMO, self-defeating. Sure, but all of that stuff works even better with a newer distribution of Python due to enhancements in the interpreter. There's no disadvantage to glossing over the fact that there is an interpreter that ships with OS X. The minimal effort it takes to use a third party installation of Python is well worth it, and it becomes more useful as time goes on. Doubly so now that Leopard is approaching, because users can upgrade without losing all of their Python work to major version upgrade death. To begin with, I don't see a stability in the current state of MacPython that gives me confidence in this assurance. But I agree that the effort of installation is minimal, and should be encouraged. Right now, the current state of MacPython is effectively the current state of Python itself. If you don't trust Python 2.4, how do you trust Python 2.3? Given Apple's track record of making Python worse (though they are consistently improving), your viewpoint makes no sense to me. Should we officially encourage Apple not to include Python in their next release? That would solve lots of these problems, I think. Our problem with Apple's bundling of Python is purely a documentation issue (and the stubbornness of those who insist that it should be used -- even celebrated -- despite its disadvantages). If we make the proposed PATH change script to the installer, we can ignore the system Python just as easily as we could if it wasn't there at all. There's little good reason for us to petition for its removal, and there's good reason for them to keep it there: they use it. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 9, 2006, at 1:39 PM, Bill Janssen wrote: Now, what I really want to see added is something that explains how I can write a program in Python on the Mac and create standalone applications that can run on someone else's computer without them having to install anything else. Great idea, Rodney. I think we probably need a number of pages like this, kind of an FAQ set. I think the main page should just cover one or two things (how to run python, how to upgrade), and lots of pointers to these pages. Each of these should be fairly clear, with pointers off to more complicated explanations. Here's the start of a list: 1) What's the difference between python and pythonw? 2) What's the advantage of upgrading? 3) What do I do if I want to use pre-built packages? 4) How do I use the Apple GUI toolkit from Python? 5) How do I use Apple Events from Python? 6) How do I build a real Mac application written in Python? 7) How do I install extra modules, like PIL, for the system Python? 8) What IDE's are available, and what are their relative merits? Some of these questions are already answered by http://pythonmac.org/ wiki/FAQ -- for the questions that aren't currently answered, feel free to contribute. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Thu, 9 Feb 2006 13:33:17 -0800 Bob Ippolito [EMAIL PROTECTED] wrote: snip It's the job of Fink or DarwinPorts to sustain their Python communities. There are already too many choices, I'd really like to avoid even more confusion. Perhaps this could be mentioned on the Bill's page to the effect that it's discouraged to use those sources. The way that Python is used in such an environment is closer to how it is used on a Linux or BSD distribution, given that it has managed packages and is only usable from a shell. snip They are convinient in a sense that they provide one source for all the extensions for mac. IIRC both are mentioned on SciPy installation instructions. Nevermind that on Tiger SciPy install is a whole ugly can of worms. Cutting down on number of standards is a good thing in this case. Regards, Ivan. ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 9, 2006, at 2:49 PM, I. Vinogradov wrote: On Thu, 9 Feb 2006 13:33:17 -0800 Bob Ippolito [EMAIL PROTECTED] wrote: snip It's the job of Fink or DarwinPorts to sustain their Python communities. There are already too many choices, I'd really like to avoid even more confusion. Perhaps this could be mentioned on the Bill's page to the effect that it's discouraged to use those sources. I wouldn't explicitly discourage it.. I would rather have the page state that it's focus is to recommend and support users of a particular framework distribution of Python, and that the information may not apply to other sources of Python such as from Fink or DarwinPorts. The way that Python is used in such an environment is closer to how it is used on a Linux or BSD distribution, given that it has managed packages and is only usable from a shell. snip They are convinient in a sense that they provide one source for all the extensions for mac. IIRC both are mentioned on SciPy installation instructions. Nevermind that on Tiger SciPy install is a whole ugly can of worms. Cutting down on number of standards is a good thing in this case. The extension problem (on win32 and Mac OS X anyway) is going to be fixed by setuptools sooner than later... it just needs some more time. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
It's the job of Fink or DarwinPorts to sustain their Python communities. There are already too many choices, I'd really like to avoid even more confusion. Perhaps this could be mentioned on the Bill's page to the effect that it's discouraged to use those sources. Fine by me. I try not to use either one, and advise others not to use them. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
If we ignore the vendor's interpreter then our documentation becomes MUCH simpler as there will be one -- and preferably only one -- way to do it: install a Python interpreter that is recent and can run the full scope of Python applications. I think I'm almost convinced on this point, save for the problem of /usr/bin/python and the default PATH. If we make the proposed PATH change script to the installer, we can ignore the system Python just as easily as we could if it wasn't there at all. It is extremely difficult (almost impossible) to make such scripts work properly on Unix, with the variety of shells and environments that people use. There's little good reason for us to petition for its removal, and there's good reason for them to keep it there: they use it. If they shipped, instead, the current version of MacPython, would that make the issue moot? That is, would you still insist on an upgrade before a user could use Python? Could a Mac ever ship with an acceptable pre-installed Python? If not, perhaps the solution for Apple is to move /usr/bin/python to some other spot, like /usr/libexec/, or some such place. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 9, 2006, at 3:56 PM, Bill Janssen wrote: If we ignore the vendor's interpreter then our documentation becomes MUCH simpler as there will be one -- and preferably only one -- way to do it: install a Python interpreter that is recent and can run the full scope of Python applications. I think I'm almost convinced on this point, save for the problem of /usr/bin/python and the default PATH. If we make the proposed PATH change script to the installer, we can ignore the system Python just as easily as we could if it wasn't there at all. It is extremely difficult (almost impossible) to make such scripts work properly on Unix, with the variety of shells and environments that people use. This is practice, not theory. Only a small subset of the target audience knows what they're doing wrt PATH and .profile (or whatever is appropriate). DarwinPorts has a simple 99.9% solution in their postflight script: check if /opt/local/bin is in the path, if not, then append a line to their .cshrc if their SHELL is *csh and append a line to their .profile if their SHELL is *sh. There's little good reason for us to petition for its removal, and there's good reason for them to keep it there: they use it. If they shipped, instead, the current version of MacPython, would that make the issue moot? That is, would you still insist on an upgrade before a user could use Python? Could a Mac ever ship with an acceptable pre-installed Python? If not, perhaps the solution for Apple is to move /usr/bin/python to some other spot, like /usr/libexec/, or some such place. The issue of not being able to produce redistributable applications still exists, and also backwards compatibility with previous versions of Mac OS X. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
Hi Bob, On Feb 9, 2006, at 4:10 PM, Bob Ippolito wrote: [snip] The issue of not being able to produce redistributable applications still exists, and also backwards compatibility with previous versions of Mac OS X. I haven't had time to respond to your other emails yet, but I've seen you mention this several times and I was wondering - why is it not possible to produce re-distributable applications with the system Python? (A thread title, etc. would be fine too if this was answered somewhere.) Thanks, Kevin -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 9, 2006, at 4:17 PM, Kevin Ollivier wrote: Hi Bob, On Feb 9, 2006, at 4:10 PM, Bob Ippolito wrote: [snip] The issue of not being able to produce redistributable applications still exists, and also backwards compatibility with previous versions of Mac OS X. I haven't had time to respond to your other emails yet, but I've seen you mention this several times and I was wondering - why is it not possible to produce re-distributable applications with the system Python? (A thread title, etc. would be fine too if this was answered somewhere.) The largest issue is that you can't legally redistribute the Python interpreter that ships with Mac OS X, so you can't create standalone applications. Even if you could, it wouldn't have a chance of being backwards compatible with the way that Apple builds things. Semi-standalone applications are fragile and only work on a particular minor version of OS X... for example, anything you build against it is only compatible with Mac OS X 10.4. It won't be compatible with Mac OS X 10.3, and it won't be compatible with Mac OS X 10.5 or anything farther away in either direction. Using a third party Python has a chance of being backwards compatible (some apps built on 10.4 work on 10.3) and it virtually guarantees forwards compatibility (apps I built standalone with py2app on 10.2 still work on 10.4, even with i386 hardware). -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 9, 2006, at 6:56 PM, Bill Janssen wrote: If we make the proposed PATH change script to the installer, we can ignore the system Python just as easily as we could if it wasn't there at all. It is extremely difficult (almost impossible) to make such scripts work properly on Unix, with the variety of shells and environments that people use. Well, there are really only two flavors of shell - csh and sh. I'm sure it would be quite possible to create a post-install script that did the right thing for 98% of the people who used it. Those lost 2% are Unix geeks who can easily make the required changes by hand, with a bit of minimal documentation. Tom ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 9, 2006, at 1:38 PM, Bill Janssen wrote: Python does not currently have an official Mac maintainer. Bingo! And no one has stepped up to document the amazing torrent of productive activity since Jack retired. As a result, the useful pieces are scattered all over, the official documentation is wildly out of date, and there's not even a useful web page for MacPython. Add to this the fact that the pre-installed Python is widely held to be useless by well-respected and influential members of the community. A parochial and self-defeating assessment, I think. From a lurkers point of view . . . I think the starting point of the whole page is the perfect way to begin. There are many of us who find that python 2.3 is just fine for the kind of things that we are trying to do. Telling a newbie that this is a great tool but you need to do an update is just going to be overwhelming. Case in point. The other day I volunteered some time at the local elementary school and the computer teacher was looking for something to give to some more advanced 10 to 12 year olds. I told him that his Mac's all have python installed and it comes with a turtle graphics module. Turtle?, he says. Does it work like the old Logo system? After ten minutes of showing him how to get started and answering things like What's this terminal window thing he's off and running and very excited. It cost him very little time, no money out of his budget, no software to install on 30 machines, and suddenly he has a whole new tool to play with and expose his kids to some simple programming concepts. Now he's off learning python. That's how it should work for a newbie. Karl ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
Could a Mac ever ship with an acceptable pre-installed Python? If not, perhaps the solution for Apple is to move /usr/bin/python to some other spot, like /usr/libexec/, or some such place. The issue of not being able to produce redistributable applications still exists, and also backwards compatibility with previous versions of Mac OS X. So you're saying that the pre-installed version could never be really acceptable. In that case, perhaps we only need convince Apple to move /usr/bin/python to some more system-y place that wouldn't usually be on users' paths. We then in the MacPython world take the position that Python isn't really pre-installed on Macs, and the place for a person to start would be to download the installer and run it. Perhaps then in addition the installer could symlink /usr/local/bin/pythonw to /usr/bin/python, thereby solving the PATH issue. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
Case in point. The other day I volunteered some time at the local elementary school and the computer teacher was looking for something to give to some more advanced 10 to 12 year olds. I told him that his Mac's all have python installed and it comes with a turtle graphics module. Turtle?, he says. Does it work like the old Logo system? After ten minutes of showing him how to get started and answering things like What's this terminal window thing he's off and running and very excited. It cost him very little time, no money out of his budget, no software to install on 30 machines, and suddenly he has a whole new tool to play with and expose his kids to some simple programming concepts. Now he's off learning python. That's how it should work for a newbie. Wow! Great success story, Karl. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 9, 2006, at 7:24 PM, Bill Janssen wrote: Could a Mac ever ship with an acceptable pre-installed Python? If not, perhaps the solution for Apple is to move /usr/bin/python to some other spot, like /usr/libexec/, or some such place. The issue of not being able to produce redistributable applications still exists, and also backwards compatibility with previous versions of Mac OS X. So you're saying that the pre-installed version could never be really acceptable. In that case, perhaps we only need convince Apple to move /usr/bin/python to some more system-y place that wouldn't usually be on users' paths. We then in the MacPython world take the position that Python isn't really pre-installed on Macs, and the place for a person to start would be to download the installer and run it. Perhaps then in addition the installer could symlink /usr/local/bin/pythonw to /usr/bin/python, thereby solving the PATH issue. That's not an acceptable solution. We need to support versions of OS X that currently exist, and we can't depend on Apple to do anything. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
At 1:20 PM -0800 2/9/06, Bob Ippolito wrote: py2app is the solution for application packaging, and you must use it with a third party Python installation (e.g. Python 2.4.1) in order to come up with something that's redistributable and robust. If you happen to use the system Python, then you will produce a package that only runs on the particular release of Mac OS X that you build it with. In other words, when you or your users upgrade to Mac OS X 10.5, any system-Python built application bundle will cease to function at all. It is actually not much different than on other platforms. Many py2exe-based setup scripts work identically with py2app if you change the import statement. Mac-specific features of course require Mac- specific solutions, but the standard stuff is identical. There is some minimal documentation: http://undefined.org/python/ py2app.html In general, I know this. I try to at least skim the messages on this list on a regular basis to keep up with what is going on in the MacPython world. But, for someone who is new to Python, the documentation you are pointing to is pretty rough going. It would be really nice to have a more basic introduction to what py2app actually does. Then, a step by step description of how to make it work, rather than just jumping into setup.py scripts. (Where does setup.py come from? The documentation doesn't say. I'm not asking this, just pointing out that it will be confusing to someone just trying to learn this stuff. They are going to want to know why they have to build their application when they already have it running.) Any other questions you have can probably be answered by py2exe documentation and/or this list. Yes, I'm sure they can be. I don't see any reference to actually taking a look at the py2exe documentation. Everything states that it is similar, but for the Mac. It doesn't say take a look there if you need more help. Or to ask here. But this discussion is about how to make this easier for people to get into. Having to ask here isn't that bad. Everyone here is very friendly and helpful. But, many people don't like to subscribe to mailing lists, especially to ask one question. Most of the discussions that go on here are *WAY* over the heads of beginners and even many intermediate Python users. And, the answers often times make assumptions about what the user knows rather than offering basic advice. I'm not complaining, really. I know that you and everyone here do this on your own time and do your best to help everyone. Python on the Mac really needs a very easily accessible discussion board for people to read and ask questions. python-mac is intimidating to someone getting started. Those who aren't so timid may stick it out, but many people will likely skim the messages on the python.org website and walk away after deciding that this stuff is just too tough. The ones who are already programmers aren't the ones I'm talking about. I'm more talking about the new scripter or maybe someone who has done a little bit of AppleScript or possibly HTML and basic JavaScript. While I can articulate what I want to see and can put myself in the place of the absolute beginner (I'm not too far from that myself with Python and I teach technical courses to varying skill levels of users for a living), I unfortunately don't have the Python background to write this material myself. I hope this helps get across what I'm looking for and what I think will benefit people trying to get started with Python on the Mac. -Rodney ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 9, 2006, at 8:09 PM, Rodney Somerstein wrote: At 1:20 PM -0800 2/9/06, Bob Ippolito wrote: py2app is the solution for application packaging, and you must use it with a third party Python installation (e.g. Python 2.4.1) in order to come up with something that's redistributable and robust. If you happen to use the system Python, then you will produce a package that only runs on the particular release of Mac OS X that you build it with. In other words, when you or your users upgrade to Mac OS X 10.5, any system-Python built application bundle will cease to function at all. It is actually not much different than on other platforms. Many py2exe-based setup scripts work identically with py2app if you change the import statement. Mac-specific features of course require Mac- specific solutions, but the standard stuff is identical. There is some minimal documentation: http://undefined.org/python/ py2app.html In general, I know this. I try to at least skim the messages on this list on a regular basis to keep up with what is going on in the MacPython world. But, for someone who is new to Python, the documentation you are pointing to is pretty rough going. It would be really nice to have a more basic introduction to what py2app actually does. Then, a step by step description of how to make it work, rather than just jumping into setup.py scripts. (Where does setup.py come from? The documentation doesn't say. I'm not asking this, just pointing out that it will be confusing to someone just trying to learn this stuff. They are going to want to know why they have to build their application when they already have it running.) Any other questions you have can probably be answered by py2exe documentation and/or this list. Yes, I'm sure they can be. I don't see any reference to actually taking a look at the py2exe documentation. Everything states that it is similar, but for the Mac. It doesn't say take a look there if you need more help. Or to ask here. py2app is not a polished product and is not geared towards people that don't already know what they're doing. If you want to see more basic docs, ask enough specific questions so that you understand the material and write the documentation yourself. Send it to me, and I'll make sure it goes in to the next release. This is open source, that's how it works. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] My stab at a new page
I've made up a sample page, at http://bill.janssen.org/new-macpython-page.html. This is the kind of thing I'd like to see replace the page at http://www.python.org/download/download_mac.html. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
On Feb 8, 2006, at 8:29 PM, Bill Janssen wrote: I've made up a sample page, at http://bill.janssen.org/new- macpython-page.html. This is the kind of thing I'd like to see replace the page at http://www.python.org/download/download_mac.html. import statements don't use quotes (import idlelib.idle, not import idlelib.idle) OS X 10.3 did not ship with Tkinter so IDLE isn't going to work there OS X 10.2 did not ship with a usable version of Python. Python 2.2.0, especially the way they built it, is nearly unusably bug- ridden. It's hardly even worth mentioning that Python shipped with that release of the OS. If they don't use pythonw to start Python, they won't be able to talk to GUI stuff except for what happens to be tkinter based. The instructions will have to say to use pythonw. Though IDLE and other tkinter-based stuff will work due to a hack that's in that release of Tk (the one that ships with 10.4, anyway), nothing else will, so you really need to tell people to use pythonw. pythonw is perfectly good at running every Python app, so there's no reason to have them run anything else for any purpose... -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] My stab at a new page
This is a great start. Do you think it might be a good idea to put this up on the PythonMac wiki so that others on the list can contribute? I can foresee this turning into a really good resource. - Dave On 8-Feb-06, at 11:29 PM, Bill Janssen wrote: I've made up a sample page, at http://bill.janssen.org/new- macpython-page.html. This is the kind of thing I'd like to see replace the page at http://www.python.org/download/download_mac.html. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
