Re: [Pythonmac-SIG] uninstall
On Feb 10, 2006, at 1:56 AM, linda.s wrote: If I installed some version of python i do not like, how do i remove them? In windows, it is easy to uninstall them, but no idea about how to do in Mac (just drag it to the the icon of trashcan?)? It depends on which version of Python it is and how you installed it.. You'll have to be more specific. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] uninstall
On Feb 10, 2006, at 2:55 AM, linda.s wrote: On 2/10/06, Bob Ippolito [EMAIL PROTECTED] wrote: On Feb 10, 2006, at 1:56 AM, linda.s wrote: If I installed some version of python i do not like, how do i remove them? In windows, it is easy to uninstall them, but no idea about how to do in Mac (just drag it to the the icon of trashcan?)? It depends on which version of Python it is and how you installed it.. You'll have to be more specific. -bob I installed python 2.4.2 from source. Why version matters (curious:))? The version number is in the path names. Did you install it with ./ configure sudo make install or ./configure --enable-framework sudo make frameworkinstall? -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] uninstall
On 2/10/06, Bob Ippolito [EMAIL PROTECTED] wrote: On Feb 10, 2006, at 2:55 AM, linda.s wrote: On 2/10/06, Bob Ippolito [EMAIL PROTECTED] wrote: On Feb 10, 2006, at 1:56 AM, linda.s wrote: If I installed some version of python i do not like, how do i remove them? In windows, it is easy to uninstall them, but no idea about how to do in Mac (just drag it to the the icon of trashcan?)? It depends on which version of Python it is and how you installed it.. You'll have to be more specific. -bob I installed python 2.4.2 from source. Why version matters (curious:))? The version number is in the path names. Did you install it with ./ configure sudo make install or ./configure --enable-framework sudo make frameworkinstall? -bob ./configure sudo make install ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] uninstall
On 2/10/06, Bob Ippolito [EMAIL PROTECTED] wrote: On Feb 10, 2006, at 1:56 AM, linda.s wrote: If I installed some version of python i do not like, how do i remove them? In windows, it is easy to uninstall them, but no idea about how to do in Mac (just drag it to the the icon of trashcan?)? It depends on which version of Python it is and how you installed it.. You'll have to be more specific. -bob I installed python 2.4.2 from source. Why version matters (curious:))? Linda ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] strange #!/usr/bin/pythonw behavior...
#!/usr/bin/pythonw Bob Sounds like you're using OS X 10.3. It shipped with pythonw as a Bob shell script, not an executable. Yes, thanks. Shoulda thought to actually look at /usr/bin/pythonw... Skip ___ 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] strange #!/usr/bin/pythonw behavior...
#!/usr/bin/pythonw Bob Sounds like you're using OS X 10.3. It shipped with pythonw as a Bob shell script, not an executable. skip Yes, thanks. Shoulda thought to actually look at skip /usr/bin/pythonw... Alas, explicitly specifying the long path didn't work either. It bombs on import of appscript: Traceback (most recent call last): File /Users/skip/cmd/ical.py, line 11, in ? from appscript import * File /Library/Python/2.3/appscript/__init__.py, line 16, in ? from specifier import app, CommandError File /Library/Python/2.3/appscript/specifier.py, line 9, in ? import aem File /Library/Python/2.3/aem/__init__.py, line 25, in ? from send import * File /Library/Python/2.3/aem/send/__init__.py, line 103, in ? raise RuntimeError, Can't send Apple events: no access to Window Manager. (aem-based scripts must be run within a GUI process; e.g. use 'pythonw', not 'python', if running script in shell) RuntimeError: Can't send Apple events: no access to Window Manager. (aem-based scripts must be run within a GUI process; e.g. use 'pythonw', not 'python', if running script in shell) even when run from a Terminal window. Skip ___ 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] strange #!/usr/bin/pythonw behavior...
[EMAIL PROTECTED] wrote: #!/usr/bin/pythonw Bob Sounds like you're using OS X 10.3. It shipped with pythonw as a Bob shell script, not an executable. skip Yes, thanks. Shoulda thought to actually look at skip /usr/bin/pythonw... Alas, explicitly specifying the long path didn't work either. It bombs on import of appscript: Try #!/usr/bin/env /usr/bin/pythonw -- Robert Kern [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter ___ 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] New Page, first proposal
I think this would be a pretty good way to start building a FAQ. There already is a FAQ, and it's been there for a very long time. We don't have to start building anything -- just link to the most popular ones. Where the heck is it? Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] uninstall
On Feb 10, 2006, at 3:14 AM, linda.s wrote: On 2/10/06, Bob Ippolito [EMAIL PROTECTED] wrote: On Feb 10, 2006, at 2:55 AM, linda.s wrote: On 2/10/06, Bob Ippolito [EMAIL PROTECTED] wrote: On Feb 10, 2006, at 1:56 AM, linda.s wrote: If I installed some version of python i do not like, how do i remove them? In windows, it is easy to uninstall them, but no idea about how to do in Mac (just drag it to the the icon of trashcan?)? It depends on which version of Python it is and how you installed it.. You'll have to be more specific. -bob I installed python 2.4.2 from source. Why version matters (curious:))? The version number is in the path names. Did you install it with ./ configure sudo make install or ./configure --enable-framework sudo make frameworkinstall? -bob ./configure sudo make install That would install these files: /usr/local/bin/python /usr/local/bin/python2.4 /usr/local/bin/pydoc /usr/local/bin/idle /usr/local/bin/smptd.py /usr/local/man/man1/python.1 And these directories: /usr/local/include/python2.4 /usr/local/lib/python2.4 Note that if you have since installed a framework build of Python, then /usr/local/bin/python and /usr/local/bin/python2.4 have already been replaced and you should not delete them. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] New Page, first proposal
On 10-Feb-06, at 12:39 PM, Bill Janssen wrote: I think this would be a pretty good way to start building a FAQ. There already is a FAQ, and it's been there for a very long time. We don't have to start building anything -- just link to the most popular ones. Where the heck is it? More to the point, why isn't it on the wiki? :P (My last cry for collaboratively editable documentation apparently fell on deaf ears... ) - Dave ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] New Page, first proposal
On Feb 10, 2006, at 9:39 AM, Bill Janssen wrote: I think this would be a pretty good way to start building a FAQ. There already is a FAQ, and it's been there for a very long time. We don't have to start building anything -- just link to the most popular ones. Where the heck is it? I linked to it in a message to you earlier in this thread, but since you asked: http://pythonmac.org/wiki/FAQ The wiki is linked to from the front page, and the FAQ is the absolute first thing mentioned on the front page of pythonmac.org. Additionally, searching with any of the obvious terms on google is going to bring it up as the first link.. such as macpython faq pythonmac faq Hell, there's even a link to it from Jack's MacPython page! -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] New Page, first proposal
On Feb 10, 2006, at 9:49 AM, David Warde-Farley wrote: On 10-Feb-06, at 12:39 PM, Bill Janssen wrote: I think this would be a pretty good way to start building a FAQ. There already is a FAQ, and it's been there for a very long time. We don't have to start building anything -- just link to the most popular ones. Where the heck is it? More to the point, why isn't it on the wiki? :P How did you not find it on the wiki? It's the very first thing linked to on the wiki! -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] New Page, first proposal
Argh. Right. Note to self: actually go check before asking stupid questions. - David On 10-Feb-06, at 1:03 PM, Bob Ippolito wrote: On Feb 10, 2006, at 9:49 AM, David Warde-Farley wrote: On 10-Feb-06, at 12:39 PM, Bill Janssen wrote: I think this would be a pretty good way to start building a FAQ. There already is a FAQ, and it's been there for a very long time. We don't have to start building anything -- just link to the most popular ones. Where the heck is it? More to the point, why isn't it on the wiki? :P How did you not find it on the wiki? It's the very first thing linked to on the wiki! -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 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] New Page, first proposal
Bob Ippolito wrote: Let's have py2app be a standard part of the 2.4 package. It'd be great if the standard upgrade package had and did everything you need to get started. I suggest easy-install as well. I'd prefer to wait on that until it's more mature. Why? it's what we use now, and it's the best there is. Anyone wanting to create stand-alones is going to need it. There's always room for it to be upgraded in the future. Shipping setuptools isn't a bad idea, but it's a one-liner to install it.. Yes, but it then puts the scripts in the weird bin directory buried in the Framework, and one extra step is one extra step too many. The extension thing we can hack around by installing two copies of the Makefile and having distutils pick a PPC-only Makefile if it detects 10.3. OK. as long as that hack is built in to the installer, that's great. It might be a good idea to highlight the really frequent FAQs and link to their answers on the wiki. Absolutely I think that page should largely be a bunch of links to the Wiki. Well we might as well just crib the script from DarwinPorts and change the paths... Why not just add it to the PATH for all the common shells. It's not going to hurt me to have my .cshrc edited (or created) if I use bash, and then if I ever switch shells there it is. Since we're going to manipulating the PATH with the installer, should we still bother with the symlinks in /usr/local/bin? We definitely want the Framework's bin dir on the PATH because that's where scripts will be installed to... so the /usr/local/bin links seem a bit redundant. If we do this, then the Python installation process is completely self-contained except for the Applications dir. hmmm. In general, I'm not thrilled with every app creating it's own addition to the PATH, it reminds me of DOS pain. I really like that in *nix, there are only a few, standard, places for executables. Given that, another option is to Create a ~/.pydistutils.cfg file with: - [easy_install] script_dir = /usr/local/bin - or whatever is appropriate. That may be getting too complicated, however. The problem is that there are many kinds of new users. There are experienced programmers who understand the Mac, There are Python programmers coming from Windows or Linux, A good entry page tries to speak usefully to all of these communities at the same time, without speaking down to any of them. I think the solution is to start out with a decision tree right at the start: If you are an experienced programmer who understand the Mac: link to Wiki page for them If you are Python programmers coming from Windows or Linux: link to wiki page for them etc -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] New Page, first proposal
On Fri, Feb 10, 2006 at 12:37:55PM -0800, Christopher Barker wrote: Yes, but it then puts the scripts in the weird bin directory buried in the Framework, and one extra step is one extra step too many. This definitely needs to be a FAQ, at least, if not a changed default in the Python framework install. I've seen this catch a large number of people using Python web apps that install scripts for management, such as Trac, TurboGears and so forth. Even if we could just recommend a ~/.pydistutils.cfg like this: [install] install_scripts = /usr/local/bin we'd be better off. -- 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
-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] New Page, first proposal
On Feb 10, 2006, at 1:00 PM, Nicholas Riley wrote: On Fri, Feb 10, 2006 at 12:37:55PM -0800, Christopher Barker wrote: Yes, but it then puts the scripts in the weird bin directory buried in the Framework, and one extra step is one extra step too many. This definitely needs to be a FAQ, at least, if not a changed default in the Python framework install. I've seen this catch a large number of people using Python web apps that install scripts for management, such as Trac, TurboGears and so forth. Even if we could just recommend a ~/.pydistutils.cfg like this: [install] install_scripts = /usr/local/bin we'd be better off. My current plan is to add the framework's bin path to the installer's post-flight. Pros: We can skip /usr/local/bin entirely and avoid the chance that the user wants other things in /usr/local/bin to come in a different order on PATH. We don't have to tweak a single distutils setting Cons: Different than what we do now Transitionally, probably the right answer is to keep the symlinks in / usr/local/bin, but only put the framework's bin dir on the PATH. -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: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
[Pythonmac-SIG] current state of scripting: appscript vs. aeve?
Is there a winner yet? The appscript wiki page seems to have been modified more recently than the aeve one. It seems that the gensuitemodule is still the way to go. 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] current state of scripting: appscript vs. aeve?
On Feb 10, 2006, at 5:31 PM, Bill Janssen wrote: Is there a winner yet? The appscript wiki page seems to have been modified more recently than the aeve one. appscript is the winner. I don't care to maintain aeve, and gensuitemodule is just plain broken. It seems that the gensuitemodule is still the way to go. Definitely not. It hasn't ever worked very well on OS X. IIRC, it can't even do Finder correctly (either that or iTunes, I forget which). -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: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] current state of scripting: appscript vs. aeve?
I've updated the Applescript wiki page accordingly. Bill On Feb 10, 2006, at 5:31 PM, Bill Janssen wrote: Is there a winner yet? The appscript wiki page seems to have been modified more recently than the aeve one. appscript is the winner. I don't care to maintain aeve, and gensuitemodule is just plain broken. It seems that the gensuitemodule is still the way to go. Definitely not. It hasn't ever worked very well on OS X. IIRC, it can't even do Finder correctly (either that or iTunes, I forget which). -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] update the IDLE gentle introduction for the Mac with new screenshots?
There's a nice little tutorial guide introduction to IDLE at http://hkn.eecs.berkeley.edu/~dyoo/python/idle_intro/index.html. It's been translated into 13 other languages by various people. But no one has translated it into Mac by providing Mac screenshots to replace the Windows ones there. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] current state of scripting: appscript vs. aeve?
Bob wrote: It seems that the gensuitemodule is still the way to go. Definitely not. It hasn't ever worked very well on OS X. IIRC, it can't even do Finder correctly (either that or iTunes, I forget which). Yup. gsm's always been a bit flaky, and now appears to be pining for the fjords too [1]. I'll see about cleaning up the relevant wiki pages when I've some spare time; that AppleScript page is hardly appealing. has [1] http://mail.python.org/pipermail/pythonmac-sig/2006-February/016133.html -- 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
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
[Pythonmac-SIG] appscript introspection?
I'm trying to drive iCal using appscript. I can follow simple examples,
mostly like a parrot though. This works, for example:
ev = app('iCal').calendars.filter(its.title==Home).events
events = zip(ev.start_date.get(), ev.end_date.get(),
ev.summary.get(), ev.description.get())
but I haven't found anywhere that lists all the attributes of an event, so I
can't tell what it has other than start_date, end_date, summary and
description. If I don't have an example to use as a cheat sheet, how can I
tell how to add an alarm to an event? Where can I find such information?
Thx,
--
Skip Montanaro
http://www.musi-cal.com/
[EMAIL PROTECTED]
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] appscript introspection?
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
I'm trying to drive iCal using appscript. I can follow simple examples,
mostly like a parrot though. This works, for example:
ev = app('iCal').calendars.filter(its.title==Home).events
events = zip(ev.start_date.get(), ev.end_date.get(),
ev.summary.get(), ev.description.get())
but I haven't found anywhere that lists all the attributes of an event, so I
can't tell what it has other than start_date, end_date, summary and
description. If I don't have an example to use as a cheat sheet, how can I
tell how to add an alarm to an event? Where can I find such information?
1. appscript supplies a help method for appscript objects. See:
http://freespace.virgin.net/hamish.sanderson/appscripthelpsystem.html
In your example:
ev.help()
=
===
Appscript Help (-t)
Reference: app(u'/Applications/iCal.app').calendars.filter(its.title ==
'Home').events
-
---
Description of reference
Element: events --
Terminology for event class
Class: event -- This class represents an event.
Parent:
(Bad terminology: can't find class with AE code ''.)
Properties:
description : Unicode -- The events notes.
start_date : DateTime -- The event start date.
end_date : DateTime -- The event end date.
allday_event : Boolean -- True if the event is an all-day event
recurrence : Unicode -- The iCalendar (RFC 2445) string
describing the event recurrence, if defined
sequence : Integer (r/o) -- The event version.
stamp_date : DateTime (r/o) -- The event modification date.
excluded_dates : list of DateTime -- The exception dates.
status : k.cancelled | k.confirmed | k.none | k.tentative -- The
event status.
summary : Unicode -- This is the event summary.
location : Unicode -- This is the event location.
uid : Unicode (r/o) -- A unique event key.
url : Unicode -- The URL associated to the event.
Elements:
attendees --
display_alarms --
mail_alarms --
open_file_alarms --
sound_alarms --
=
===
app(u'/Applications/iCal.app').calendars.filter(its.title ==
'Home').events
2. It may be more convenient to use Script Editor.app to browse the
application's terminology resources.
But, as has has noted here before, you can't always trust what any
application says is available. There's often a lot of trial and error
to discover what works and what doesn't.
See, for example:
http://article.gmane.org/gmane.comp.python.apple/6726
--
Ned Deily,
[EMAIL PROTECTED]
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
