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
Re: [Pythonmac-SIG] strange #!/usr/bin/pythonw behavior...
On Feb 9, 2006, at 8:07 PM, [EMAIL PROTECTED] wrote: > > I want to manipulate iCal from the command line. Thanks to > appscript it > looks like I'll be able to do what I want. > > I wrote a simple skeleton script: > > #!/usr/bin/pythonw Sounds like you're using OS X 10.3. It shipped with pythonw as a shell script, not an executable. You need to point it at the actual binary: /System/Library/Frameworks/Python.framework/Versions/2.3/Resources/ Python.app/Contents/MacOS/Python If you upgrade to 10.4, this should work. -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:39 PM -0800 2/9/06, Bill Janssen wrote: >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, 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. For example, question 3 probably needs to state something about all of the pre-built packages that are available before asking how to use them. Question 6 needs to at least talk about what is involved if the user wants this application to run on multiple platforms, not just Mac. For example, can they build on the Mac and the distribute on other platforms? Or do you have to build on each platform? It is likely that your idea of pointing to more complicated explanations could take care of each of kind of points that I'm raising. My key idea that I'm trying to point out is that for such a list to be useful to beginners, it needs to not make so many assumptions about what they know. An introductory paragraph in each question can help out quite a bit. For example, is it actually safe to assume that a new user even knows what the Apple GUI toolkit is? A sentence or two talking about the great UI functionality that Apple makes available and that it can be accessed from Python should be there before launching into an explanation of how to actually do so. Remember, this should serve people who haven't programmed before as well as people who have but are just new to Python. -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
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] New Page, first proposal
On 9-Feb-06, at 8:10 PM, Chris Barker wrote: Brendan Simons wrote: SPE is almost there, but still needs a binary install. Would it be there with a good installer?Maybe. However its under active development and changes frequently. BTW, "Open Terminal Here" is a nifty applet Here's another easy way to do the same thing: Open the terminal. Type "ls" followed by a space, but don't hit return. Now click on the finder and open the folder you want Terminal to access. In the titlebar of the finder window, next to the folder's name, is a little folder icon. Drag that icon to your terminal window (Expose helps if you have lots of windows open). Terminal will spell out the folder's path for you. Now return to Terminal and hit enter. I now about that, but that's a LOT more than one click -- get Open Terminal Here -- you'll be glad you did!True enough. BTW, I meant to use "cd", rather than "ls" in the example. further still if PyObjC ends up shipping with some version of OS X. That would make a big difference.Thirded. Glad to hear it's been added to the Apple buglist. -Brendan___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] strange #!/usr/bin/pythonw behavior...
I want to manipulate iCal from the command line. Thanks to appscript it looks like I'll be able to do what I want. I wrote a simple skeleton script: #!/usr/bin/pythonw """ %(prog)s - manipulate iCal """ import sys import os import getopt from appscript import * ... etc ... I made it executable and tried executing it from the bash prompt in a Terminal window. No go. The system treats it like a shell script and passes it off to the Bourne shell. Naturally, this doesn't go over too well. If I run it as "/usr/bin/pythonw ical.py ..." it works just fine. Am I missing something? 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] 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] New Page, first proposal
On Feb 9, 2006, at 7:35 PM, Bill Janssen wrote: >>> Exactly. the page we are working on should be just the main page. >>> All >>> the various suggestions for other sections are good, but should be >>> Wiki >>> pages, maintenance is much easier that way. >> >> It might be a good idea to highlight the really frequent FAQs and >> link to their answers on the wiki. > > 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. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] New Page, first proposal
> > Exactly. the page we are working on should be just the main page. All > > the various suggestions for other sections are good, but should be > > Wiki > > pages, maintenance is much easier that way. > > It might be a good idea to highlight the really frequent FAQs and > link to their answers on the wiki. I think this would be a pretty good way to start building a FAQ. 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] New Page, first proposal
> Bill Janssen wrote: > > I think here you are talking about a Mac app bundle, right? I think > > that's probably right. > > It applies just as much to a script with a #! line that relies on > installed packages. Do you really develop without any external packages? Sure. I do a lot of text processing, and the Unicode and re support in standard Python are pretty much good enough for much of that work. Almost the only extension packages I use are PIL, Medusa, and ReportLab. All just install and work pretty well with "python setup.py install". 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
> 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
[Pythonmac-SIG] PATH manipulation and /usr/local/bin
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. Maybe "make frameworkinstall" should still install the symlinks for compatibility with people building their own from source, but I'm not sure if it's better to keep doing it or to just document that the behavior has changed. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] install again?
I know the reason that I got confused is I do not know Mac/UNIX well. Is there any good tutorial to read (I understand there are many but just no idea where to start)? Thanks, Linda. ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] New Page, first proposal
On Feb 9, 2006, at 5:09 PM, Christopher Barker wrote: >> "pythonw" invokes GUI applications, "python" invokes console >> applications. When installing an extension, I don't type "pythonw >> setup.py install." > > But would there be any harm if you did? No >> 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. > > Excellent idea! Is there any downside in having "python" do what > "pythonw" does now? Not that I can imagine... maybe a few nanoseconds wasted on invocation to launch the executable and execv the real interpreter. > Rodney Somerstein 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. > > 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. Shipping setuptools isn't a bad idea, but it's a one-liner to install it.. > Bill Janssen wrote: >> and there's not even a useful web page for MacPython. > > At least we're fixing that! Thanks for all your work, Bill. > >> Is there anyone from Apple even on this list? > > non one that has admitted it -- earlier there was a discussion about > whether Apple was to blame for any of these issues. they clearly > are, as > they don't ever have anyone on this list. I don't think Apple has > really > figured out how to work with the open source community yet. Some Apple employees do a pretty good job at working with open source communities when they have the time to do so.. but they're usually too busy, and it's really their own initiative. Personally I haven't been very pleased with their open source interactions, but it could be worse. > Bob Ippolito 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: > > This has been my point from the beginning. There are a LOT of options, > but we really need to have a "One Standard Way" to do python on the > Mac > that we publicize on the Web. > > A little extra into-tutorial with the built in Python is a fine > way, but > I think it should be clear that it's a good idea to install a new > python > package once you get going. That way there is ONE set of packages to > pick from to download, etc, etc. > > I'd like the "One true way" to be the Apple installed python, but > that's > really not going to work. We've run that topic into the ground. > > We may still need one version for 10.3 and one for 10.4, but that's as > complicated as it should get. > >> 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. > > Um, aren't there issues with not being able to use the universal > version > with less than 10.3.9, and not being able to build extensions on > 10.3 at > all with the universal version? The universal version is indeed not compatible with 10.3.0-10.3.8, but upgrading to 10.3.9 is free. I think it's safe at this point to say 10.3.9 is absolutely required to use the supported version of Python. 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. >> 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. > > Exactly. the page we are working on should be just the main page. All > the various suggestions for other sections are good, but should be > Wiki > pages, maintenance is much easier that way. It might be a good idea to highlight the really frequent FAQs and link to their answers on the wiki. >> 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. > > We could probably just do .profile...anyone messing with what shell > they > use should know how to add something to their PATH. > > Wow! that was a lot. Well we might as well just crib the script from DarwinPorts and change the paths... supporting tcsh is important for the people who started with <= 10.2 and upgraded their way to >= 10.3. I held out with tcsh for a while personally, but I left it at bash last time I AppleCare'ed my powerbook and wiped the machine. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] New Page, first proposal
On Feb 9, 2006, at 5:09 PM, Christopher Barker wrote: >> Is there anyone from Apple even on this list? > > non one that has admitted it I'm an Apple employee. I know there have been others on this list, too, though I have no idea if they're still here. I don't maintain Apple's python, and I have no idea whether the people who do are on this list. I notice that there is a bug report asking for Python 2.4 be added to the release. I just now added a comment to that bug saying it would be nice to keep 2.3 as well as adding 2.4 (so that scripts which explicitly reference 2.3 could continue to work, and so you could explicitly run 2.3 if you had extensions compiled for 2.3). I also saw a bug report asking for PyObjC to be included; I'd definitely like to see that! -Mark ___ 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
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] New Page, first proposal
Hi all, Lots of comments on the whole thread Bob Ippolito wrote: > Nothing relevant comes with the system except for Terminal and > TextEdit... Which is a lousy editor for Python anyway. Brendan Simons wrote: > SPE is almost there, but still needs a binary install. Would it be there with a good installer? >> BTW, "Open Terminal Here" is a nifty applet > Here's another easy way to do the same thing: Open the terminal. > Type "ls" followed by a space, but don't hit return. Now click on > the finder and open the folder you want Terminal to access. In the > titlebar of the finder window, next to the folder's name, is a little > folder icon. Drag that icon to your terminal window (Expose helps if > you have lots of windows open). Terminal will spell out the folder's > path for you. Now return to Terminal and hit enter. I now about that, but that's a LOT more than one click -- get Open Terminal Here -- you'll be glad you did! Bob Ippolito wrote: > The 95% may shrink now that wxPython and tkinter are shipped with Mac OS > X. Except that the version of wx they ship isn't one anyone should use it they can help it. wxPython was a rapidly moving target on OS-X when they chose that version. > further still if PyObjC ends up shipping with > some version of OS X. That would make a big difference. >> If I was building an app that was written in Python, given the current >> state of MacPython and what I've read on this list over the years, I'd >> try to include the whole Python VM in that app bundle. Which means you need to use a user installed python. Bill Janssen wrote: > I think here you are talking about a Mac app bundle, right? I think > that's probably right. It applies just as much to a script with a #! line that relies on installed packages. Do you really develop without any external packages? Kevin Ollivier wrote: > I'd get really pissed off if I didn't know better and things stopped > working regardless of how I upgraded Python. You'd consider whose Python > broke your stuff into your decision to get upset? We really seem to be talking at cross purposes here. If I upgrade *python*, I expect things that depend on it to break, though in fact, when I upgrade python, I usually leave the old version in place so that nothing breaks. I put a version in my #! lines just for that reason. However, when I upgrade OS-X, I want my currently installed apps to keep working. And, in fact, they do, except the ones that depend on python. I just upgraded to OS-X 10.4. For ages, I've been using both Apples python2.3 and Bob's 2.4. All my scripts that have #!/usr/bin/env python2.3 in them are now broken. All the scripts that have #!/usr/bin/env python2.4 in them still work. If I'd started with 2.4 from the beginning, nothing would have broken. It's not hard to fix, particularly since I have a fully functional 2.4 already, but I'm not a newbie, either. > All Apple is doing is including Python with their OS, and occasionally > updating it. That these updates can cause not-so-pleasant things to > happen due to how Python works is not Apple's fault. A lot of the speech > on here practically accuses Apple of causing the problem and it's really > not fair. What they are doing is analogous to removing a bunch of shared libraries when you did an OS upgrade. IF you knew they were likely to do that you'd darn well better statically link your apps. > tell them things break when Python is upgraded > to a new major version; don't tell them (or suggest) things break > because Apple is doing it. Tell them that Apple is likely to upgrade python for you when you upgrade the OS, whether you want them to or not. however -- that's all we're saying. > What about an app bundle that just starts IDLE? Yes, we should make one of those! Kevin Walzer wrote: > No one has said anything about the "applet" packaging concept as we > discuss moving forward with this stuff. I'd like a way to build Applets: things that look like an App, but do depend on everything installed in your python. It probably wouldn't be hard to hack Py2App to do this. IIRC, Bob was open to the idea, but wasn't interested in writing the code himself. > "pythonw" invokes GUI applications, "python" invokes console > applications. When installing an extension, I don't type "pythonw > setup.py install." But would there be any harm if you did? > 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. Excellent idea! Is there any downside in having "python" do what "pythonw" does now? Rodney Somerstein 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. Let's have py2app be
Re: [Pythonmac-SIG] install again?
Christopher Barker wrote: > matplotlib has a lot of C++ in it. and there are binaries built for 2.4 on 10.3 on pythonmac.org, if that helps. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/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 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
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] install again?
Ronald Oussoren wrote: > That's not really a problem, I need some kind of test to determine if we > can get away with loading C++ code compiled with g++-3.3 into a python > build with gcc 4. Boost might also be an option for testing. matplotlib has a lot of C++ in it. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/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 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
> 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
> > 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
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: > >> 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. > > > 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
On Thu, 9 Feb 2006 13:33:17 -0800 Bob Ippolito <[EMAIL PROTECTED]> wrote: > 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. 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 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 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
> 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
> 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
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
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: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 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
> 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
> 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
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
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] a beginner's list
On Feb 9, 2006, at 5:18 AM, Charles Hartman wrote: > I have an IDLE.app on my 10.4 machine. Since I haven't really used > it, I can't remember if it came with Tiger, or showed up when I > installed Python 2.4 -- does everyone with OS 10.4 have it? Is it > just a shell to call idlelib? If so, is there any way to tell > whether it calls with python or with pythonw? It came with the MacPython 2.4 that you installed. It's a bundlebuilder applet, so it's effectively run with pythonw. -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: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
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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 > > OK, going through the page line-by-line: 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? 3. The stuff on launching IDLE from Terminal: doesn't work for me. I get these error messages: Warning: configHandler.py - IdleConf.GetOption - problem retrieving configration option 'enable' from section 'CodeContext'. returning default value: 1 Warning: configHandler.py - IdleConf.GetOption - problem retrieving configration option 'enable' from section 'CodeContext'. returning default value: 1 Warning: configHandler.py - IdleConf.GetOption - problem retrieving configration option 'enable' from section 'CodeContext'. returning default value: 1 Failed to import extension: CodeContext 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. IDLE will do in a pinch, but only if it can be started in a standard (non-terminal) way. 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. - -- 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 iD8DBQFD65jmJmdQs+6YVcoRAvDvAJ0cq+eirvmVEY+T2DrGxCVYuEHILACfdVzB WJNO6v5sV8sJ0/wjhlgdhjk= =LSrM -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). 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
> "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). 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
-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). 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. Bill > 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
Re: [Pythonmac-SIG] a beginner's list
Ronald Oussoren wrote: >>Mac OS X 10.5 will surely ship with at least 2.4.2, > >Maybe, maybe not. Who knows what apple will do? ;-) ;-) My bet is they start the Ascent to Transcendence any day now... >This is a very good reason for not pointing newbies to the system python >on pythonmac.org: unless anyone steps up to *seriously* support the >system python there won't be properly packages extension packages for >the system python. My concern would be that someone steps up with the noble intent of supporting a large number of repackagings, only for their enthusiasm to wear off after a few months after they realise how much long-term work they've committed themselves to. (i.e. Don't bite off more than you can chew.) The sensible thing would probably be to work out what the dozen most-used 3rd-party packages for casual users are likely to be, and commit to maintaining pkgs those for the next year or two. A modest number like that shouldn't create too onerous a workload; enough for the default Python to keep casual users happy without turning into an excessive duplication of effort. e.g. I'm happy to continue providing both 2.3 and 2.4 binary installers for appscript as it's no more work for me, so that's one of the dirty dozen covered right there. As has been said elsewhere, if the aim is to market Python to a broad audience then it's at least as much an exercise in influencing perceptions as technical merit. And often folk just don't like to be presented with a long list of things to download and install before they're able to do anything. e.g. Back before Nick stepped in with his all-in-one installer, some folks fair moaned about having to install a half-dozen simple distutils packages in order to use appscript. Even though the latter approach only took an extra minute or two in practice, in the end it was simpler and much more effective to cater to their "unreasonable" demands than lecture them on why "they" were "wrong". Like I say, perceptions count. And first impressions more than anything else. Technical arguments alone aren't enough; things have to *look* and *sound* simple too. >I do support system python for PyObjC, but even there it is mostly >"lets check if it still works" around release time. For day-to-day work >I'm using a framework installation of Python 2.4. And it's all much appreciated. Cheers, 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] New Page, first proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin Ollivier wrote: > > > What about an app bundle that just starts IDLE? +1 on this idea. That's the way IDLE currently ships, and I think it's very useful. I myself don't like running Python GUI applications from the command-line: I like to see an application name in the menu, not "Python." That's more newbie-friendly as well. (This is how I packaged apps when I was shipping SPE for the Mac, for instance. It's also how Robin Dunn packages the demos for wxPython.) No one has said anything about the "applet" packaging concept as we discuss moving forward with this stuff. I'm assuming that this is because the tools based on WASTE aren't going to be ported (such as applet builder), and also because "applet" is part of Bundlebuilder, which has been deprecated in favor of py2app. However, the "applet" method is really an easy way to package apps that have the external dependencies already installed on one's machine: I always use the "buildapplet.py" script that came with the older MacPython distributions. This is a good use case for IDLE, as its dependencies (tkinter) come by default on the Mac. Using py2app or its variants would be overkill here. Will the applet still be available as a packaging model, deprecated, or obsoleted by the changes that are coming? - -- 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 iD8DBQFD60MCJmdQs+6YVcoRApLmAJ9qegJmORlNx/x3Elwq9Rt+GyNNmgCcCsHm qABbn9rkWErW9CSqGrOt4ys= =FUXP -END PGP SIGNATURE- ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] a beginner's list
I have an IDLE.app on my 10.4 machine. Since I haven't really used it, I can't remember if it came with Tiger, or showed up when I installed Python 2.4 -- does everyone with OS 10.4 have it? Is it just a shell to call idlelib? If so, is there any way to tell whether it calls with python or with pythonw?CharlesOn Feb 9, 2006, at 1:38 AM, Bob Ippolito wrote:Since IDLE runs its shells and scripts in subprocesses, wx (or any other GUI framework) is possible to use if and only if IDLE was started via "pythonw". If IDLE is started with just "python" then wx will not operate. I believe the Tk that ships with OS X 10.4 does have the CPS hack that allows it to work even if started with python, but that doesn't help wx at all. ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] MacOS X _POSIX_C_SOURCES and stuff
On 09/02/2006, at 5:44 PM, Ronald Oussoren wrote: > > This has nothing to do with C++ vs. C, but that Carbon/Carbon.h is > not POSIX compliant (and that's likely also true for other Apple > headers). Why do you say it is not POSIX compliant? As my test program demonstrates, it works correctly in a C program with the POSIX feature macro defined. That is what the standard requires. So why do you say it is not compliant? Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
