Re: [Pythonmac-SIG] Speed up Python on the Mac?
Louis Pecora wrote: >>Although this will not help you know, I have been told, Pycho >><http://psyco.sourceforge.net/> will run on the Intel Chip. > Thanks for the tips, Brian. Wish I had that Intel Chip Mac Powerbook > now. :-) Even so, Psyco doesn't understand NumPy arrays, which I hope you're already using. Essentially, you are right that you need to write some of your code in C, and that it's quite tedious to do it be hand. There are a number of tools that make it easier however. Here's my assessment, but I haven't actually used all of these: SWIG -- Automatically creates wrapper for existing C/C++ code. A good choice if you are working with a n existing library, particularly if that library is under development (i.e. wxPython) f2py -- similar to SWIG, but for Fortran code. Understands NumPy arrays. A good option if you have Fortran code you want to use, or like writing Fortran SIP: similar to SWIG, used for PyQT, that's all I know. Boost::Python -- C++ wrappers for the basic Python data types, handles reference counting etc. for you. I think there are some wrappers for NumPy arrays as well. A good choice if you want to write custom extension code in C++ Pyrex -- A python-like language for writing C extensions. It makes it very easy to write what is essentially a mixture of Python and C, with Python syntax. Easy to call C functions. Probably the easiest way to write custom extensions. Can work with NumPy arrays, but only at the C level -- working with a pointer to the data. Psyco -- automatically translates pieces of your runtime code into machine language. Understands standard python data types, including the array.array type. Does not know about NumPy arrays (darn!). Can make major speed improvements for numeric code, but only if you use array.array or regular old lists and tuples. It's extremely easy to use, so why not try it on your code? Only available for x86 processors. Weave.Blitz -- From the SciPy project. Automatically, and on the fly, translates and compiles individual NumPy expressions into C++ using the Blitz++ library. Probably the easiest way to speed up small sections of code. Cxx -- kind of like Boost::Python. Is it still being maintained? Have I got them all? I hope this helps. Make sure to check out the SciPy docs, there is discussion of optimizing numerical code in various places there. -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] SWIG Install problem.
David M. Cooke wrote: > Experience has shown that compiling Scipy with gcc 4.0 on a Mac doesn't > work (various really annoying problems with how Fortran libraries end up > being linked and so on). So it's suggested that you use 3.3. There is the same problem with Fedora Core4, also using gcc 4.*, but SWIG compiles fine there. After all, SWIG has nothing to do with Fortran. Lou, Have you tried the SWIG lists? -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] Solution to some SWIG Install problems on Mac OS X
Hi Lou, I'm glad you got this working. Thanks for posting the resolution to your problems, it's good to have this stuff archived. If time permits, I hope top do some SWIGing myself, so perhaps we can help each other out. On Thursday 08 December 2005 1:17 pm, Louis Pecora wrote: >Solution: directories (folders) and files with spaces and special > Mac symbols (e.g. option-whatever) can cause problems. Yup. Technically, a file name on *nix can have any charactor in it except a "/", so many utilities use space to separate things that it's hard for things to work right with them in there. I spend most of my time on Linux, so I'm not in the habit of using spaces in file names anyway. > setenv CC g++ > > in my login file .tschrc which I got from a colleague. The dangers of borrowing other people's code! Why are you using tsch anyway? bash really is nicer, unless you're really used to a C shell. And it's the OS-X default (and most Linuxes also). Setting CC to g++ is a very odd thing to do. It's going to break a lot of make files, CC should be a C compiler! > I changed it to > setenv CC gcc You should probably just not set it to anything. gcc should be the default anyway. On my system, /usr/bin/CC is a link to gcc-3.3 > (3) running 'make install' would not work since I had no permission to > write in some directories. I don't fully understand this since I am the > admin and I was running logged in as such, but to no avail. > Solution: run this as > > sudo make install This is VERY standard stuff. I think I recall you're having a hard time transitioning to the multi-user environment of OS-X a few years back, and having some discussion about it on the MacPython list...or maybe that was someone else. OS-X has the best system for dealing with this I've seen. By default, it is set up so that it is impossible to be logged in as the root user (unix talk for system administrator). This is a good thing, as the root user can do anything, and it's remarkable easy to make a mess of your system with a typo at the command line. Also, if you're the root user and you acidentally run some malicious code, it can reek havock (not such an issue for OS-X as Windows, but still an issue). However, obviously some things do need to be done with root privileges. This is what sudo (Super User Do) is. It lets you run a single command as the root user. This is good, as it lets you get what you need done, but it makes it very clear that "I am now messing with the system" you can't do it accidentally. When working from the GUI, whenever you need to do something that requires root privileges, a dialog is popped up, asking for your password. Again a clear sign that you are messing with the system. If you were to download a virus accidentally as an email, a dialog would pop up and ask you for your password, and you know immediately that something was going on you didn't expect. So, on OS-X being an "admin" user only means that you are allowed to use sudo. Contrast this with Windows: an "admin" user can do anything, including accidentally run a virus or something that destroys theire system. However, if you run as a non-admin user, then you can't do anything administrative without loggin out, l then back in as the admin. This is a such a pain that many people just run as admin user all the time. couple this with poorly written software that requires you to run as an admin user (we have some of this in-house!) and hardly anyone doesn't run as an admin user, and surprise surprise! viruses galore! Wow! I got carried away with that! > At least I got this far. I'll be interested in what you come up with, I think our needs are similar. -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] pythonw and python with applescript
On Tuesday 13 December 2005 7:24 pm, Zhi Peng wrote: > I would like > to have a small C code and then compile and linked as dynamic library so > that it can be imported by python code as we had in Linux platform. Are you doing exactly the same thing on OS-X and Linux? Are you using distutils to compile your *.so? If so, it should work. > Mac terminal looks like unix/linux, but there are some difference, which > I may not know enough. The differences, as far as this is concerned, are: * that OS-X requires different flags and what not for compiling and linking -- distutils should take care of that for you * Any GUI program needs to be run from inside an application bundle. This is true for pure C / C++ programs as well. For Python, pythonw does that for you. > In C code, all argumnet, parameters have to be > changed to in PyObject form, otherwise, python code may not be able to call > the function. This makes it sound like you are doing more than trying to get an extension that works on Linux to work on the mac. Yes, extensions can only recieve and return PyObjects to/from Python code, but inside your extension you jsut write regular old C. SWIG is one way to generate code that translates C types into PyObjects. You can also do it by hand (or use pyrex, Boost::python, SIP, etc.). > Not sure if anyone trys swig utility on other platform? I've used it on Linux only, but it certainly works on OS-X. wxPython is built with it, for a large-scale example! > on > swig home page, there is an example, it might work on linux/unix. But it > does not work well on Mac as I tried it. post that example, if we are to help you, that's exactly what we need, a simple example. And post exactly what you did to compile 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] Solution to some SWIG Install problems on Mac OS X
HI all, Perhaps this is getting bit off-topic, but other seemed interested, so here goes. By the way, I didn't intend to send my whole diatribe about Windows security to the list, sorry about that. On Tuesday 13 December 2005 9:41 am, Louis Pecora wrote: > For graphics, I have chosen wxPython. I know there is matplotlib, but > using it interactively baffled me (although several nice people sent me > examples). I may include it in my toolbox in the future. Well, matplotlib and wxPython solve very different problems. MPL by itself is not intended to build applications with. to do that, you use another GUI toolkit (wxPython, PyGtk, TkInter), and if you need plotting, you can embedd MPL windows in your app. There has been a long recent thread about doing this with wxPython on the MPL list recently. If you need plotting in your apps, be sure to read it. You might also want to check out wx.lib.floatcanvas. It's designed to display and interact with data in arbitrary floating point coordinates. It provides zooming and panning and simple projections(for maps). It could be useful. If it looks like it is, let me know and I'll send you the latest version and some more examples of how to use it (I wrote it). > I have yet to learn that and I > still mostly do print readline kind of I/0 and menus. I keep it > simple, but occasionally GUI stuff is useful. Yes, it is, but it takes a lot longer to write GUI code than simple raw0input calls! Get yourself on the wxPython-users list. In particular, check the recent threads initiated by Rich Shepard. he's like you: A scientist without a whole lot of CS background, learning wxPython for apps to drive his models. > Yeah, the dangers of other's login scripts, huh? Well, I switched it to > gcc so I assume it should be better now. I'd remove that setenv call altogether, It might override Apple's defaults, and break other things. If you switch to bash, that will kill it. Then you'll probably need a .profile file with at least this in it: export PATH="$PATH:/usr/local/bin" or export PATH="/usr/local/bin:$PATH" depending on whether you want your stuff or Apple's as default in your shell. Rob Managan wrote: > While I have not tried WxPython I have built C modules for python > using SWIG and python's distutils. That trades the headaches of > makefiles for writing a setup.py file. I can give an example and they > really are not that bad once you have done it once! I'd love to see an example. Does it run SWIG for you too? > Is distutils more for distributing packages/modules than developing? Absolutely necessary for developing extensions. And not hard for simple set-ups. Bob Ippolito wrote: > However, setuptools is also useful for pure Python development, Bob, what do you see as the future of setuptools? Will in be in the standard lib in future versions? -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] Newbie troubles with MacPython 2.4.1 / Tiger 10.4.3
Mark Asbach wrote: > Then I started up the PackageManager and tried > to get those modules that I need. PackageManager is no longer being maintained. You can find a lot of packages (including numarray) at: http://www.pythonmac.org/packages/ Make sure you get ones that match your OS-X/Python versions. You can use packages for OS-X 10.3 on Tiger. -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
[Pythonmac-SIG] MacPython documentation and webpages
Mark, Thank you so much for taking a lead on this: it is sorely needed. Mark Asbach wrote: > Maybe it would be helpful to not distribute PackageManager with the > MacPython installer package any longer I'm not sure the MacPython installer has anything in it that's truly useful anymore. I know I don't use anything in it. If there is useful stuff in there, maybe it could be separated out and put in the collection at pythonmac.org/packages > on this topic in a prominent location. I've edited the MacPython wiki > page at http://wiki.python.org/moin/MacPython to reflect the current > status of PackageManager. Thank you for doing that. That kind of initiative is what makes Wiki's work! > Jack: as your MacPython page was the first page that I found googling > for python on Mac topics, it would be nice if you found the time to > update the "News" section Yes Jack, please do that! I know you haven't had much time for macpython lately, but for historical reasons, your page is quite prominent. > I found that information on > MacPython is split over a couple of web locations, most of which > feature incomplete, outdated or at least contradictory information on > where to get which version of MacPython. This is so true. We really need a well laid out, definitive main page for Python on OS-X. Perhaps it can be hosted on python.org. Otherwise, pythonmac.org is a good option also, but its main page needs to be updated. Once we've got that, we can try to get as many of the other pages to point to it as possible: maybe this would be a good use for a "google bomb". I am neither the web master of any of those sites, nor a guru of MacPython, but I'll help where I can. -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] MacPython documentation and webpages
Bob Ippolito wrote: > There's already two relevant wikis (python.org, pythonmac.org), what > would a CMS do differently? What it might to differently is make it easier to maintain the main front-page web site, but I don't think we need it. Bob, Are you the webmaster of pythonmac.org? If so, how is that page produced? is it static html? If so, are you open to replacing it with a page that is better suited as the primary Front-End to the Python-on-OS-X world? I think that's the best place for it. python.org only has a very simple page for each platform, it's fine as it is, if pythonmac.org had a better page If you'd like to see it improved, there seems to be some interest in this group in doing the work. -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] PIL for Python 2.4x? (Mac OS 2.4.x)
Brian Ray wrote: > -- a Python Binding for Quartz <http://tinyurl.com/9gfj8>. Now that may work for the OP's original goal: getting up a splash screen before initializing wx. I'd be interested to hear it it does. -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] MacPython documentation and webpages
Mark, You got the ball rolling on this: Mark Asbach wrote: > From my point of view, it would be very helpful to concentrate > MacPython knowledge and information in a central place like > www.python.org / http://wiki.python.org and replace all outdated > information on the other web pages by a link to that central place. > I would invest some time and effort in revising documentation. Bob Ippolito wrote: >>Are you the webmaster of pythonmac.org? If so, how is that page >>produced? is it static html? > Yes and yes. >>If so, are you open to replacing it with a page that is better >>suited as the primary Front-End to the Python-on-OS-X world? > Patches accepted ;) If anyone wants to deal with it, I'm definitely > willing to dish out accounts. I think we have an answer: python.org does not, in general, have a lot of platform specific documentation, and we'd have to get the primary python folks to approve anything we want to put there. I think that makes pythonmac.org the best place for our new, improved, "Intro Page for Python on OS-X". Mark, are you willing to coordinate the writing of a new page[s]? I suggest we have a basic intro, and then perhaps a decision tree under the heading: What version of Python should I use? That decision tree would include things like: which version of OS-X are you running? Do you need python 2.4 features? Do you want to bundle apps for others to use? etc. And, of course, we need a pointer to a FAQ in the Wiki. I'd also suggest that we break the pythonmac.org/packages pages down into separate pages, one for each python version. I think that will make it much clearer to folks coming to it which set of packages they should look at. Anyone else? -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] Best site to get Numeric and wxPython for new Tiger 10.4 install?
Louis Pecora wrote: > What are the best sites to use to install Numeric and wxPython which > will be used with the stock, Apple-installed Python? pythonmac.org/packages Robin Dunn just released a brand-new wxPython: http://www.wxpython.org/download.php We'll probably put it on the pythonmac site at some point. It's also time for an update to Numeric, but the one there works fine. -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] Best site to get Numeric and wxPython for new Tiger 10.4 install?
Louis Pecora wrote: > I am > trying to find which Numeric from pythonmac.org/packages/ > <http://pythonmac.org/packages/> I should use. In theory, you want one in: Mac OS X 10.4 (stock Python 2.3.5) However, there isn't one there. The one in: Mac OS X 10.3 (stock Python 2.3.0) may work. If it doesn't then you are stuck with upgrading to Python2.4 or building Numeric yourself, which should "just work" including Vectlib lapack support. If you do that, it would be great if you'd build a package and it can be put on that site. Apparently most Tiger users are running Python 2.4 -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] Best site to get Numeric and wxPython for new Tiger 10.4 install?
Louis Pecora wrote: > Yeah, I've thought about going to 2.4, but I don't need more > installation complications for now. If I can hold off, I will. well, it's easy to install 2.4, so if there is even one more ready-built package for it, then you're even, more than one, and you've saved time. -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] State of DrawBot, missing features
Dinu Gherman wrote:
Frederik Lundh
seems to have abandoned his efforts to port DrawBot to Windows [4]
due to its "overforking disease."
Well, if you want something cross-platform, maybe the wxPython
FloatCanvas (written by me) would serve you well.
What I like about it (and why I wrote it) are four key features:
Generalized floating point coordinates: use whatever coordinate system
you like, and it will scale everything for you. It even supports a
limited projection option (I include a flat-earth projection for doing
simple maps)
Object Canvas: Add objects to the Canvas, then those objects can be
removed, properties changed, whatever.
Zooming, Panning, etc.
Event binding to Mouse events on the Canvas.
I even wrote a little demo that duplicates a DrawBot demo I saw
somewhere. I've enclosed it. It should work with recent versions of
wxPython. It does create an ugly Yellow. Can someone who better
understands RGB fix that?
By the way, you can use FloatCanvas with wxPython to generate PNGs, etc,
without ever bringing up a Window, though the windowing system does need
to be there, which I'm pretty sure it always is on OS-X.
Note that FloatCanvas needs Numeric. The versions on pythonmac.org work
fine.
I have plans to put in a better rendering engine (maybe Agg), and in the
process separate the rendering engine from wx, so that it could be used
for non-GUI work without wx. No guarantee about when that might happen,
however.
-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]
#!/usr/bin/env pythonw2.4
import wx
from math import *
try: # see if there is a local FloatCanvas to use
import sys
sys.path.append("../")
from floatcanvas import NavCanvas, FloatCanvas
print "Using local FloatCanvas"
except ImportError: # Use the wxPython lib one
from wx.lib.floatcanvas import NavCanvas, FloatCanvas
print "Using installed FloatCanvas"
class DrawFrame(wx.Frame):
"""
A frame used for the FloatCanvas Demo
"""
def __init__(self,parent, id,title,position,size):
wx.Frame.__init__(self,parent, id,title,position, size)
# Add the Canvas
Canvas = NavCanvas.NavCanvas(self,-1,(500,500),
ProjectionFun = None,
Debug = 0,
BackgroundColor = "White",
)
self.Canvas = Canvas
self.Show(True)
self.MakePic()
return None
def MakePic(self):
Canvas = self.Canvas
phi = (sqrt(5) + 1)/2 - 1
oradius = 10.0
for i in xrange(0,720,1):
radius = 1.5 * oradius * sin(i * pi/720)
Color = (255*(i / 720.), 255*( i / 720.), 255 * 0.25)
x = oradius + 0.25*i*cos(phi*i*2*pi)
y = oradius + 0.25*i*sin(phi*i*2*pi)
Canvas.AddCircle((x,y),
radius,
LineColor = "Black",
LineWidth = 2,
FillColor = Color,
)
self.Canvas.ZoomToBB()
app = wx.PySimpleApp()
DrawFrame(None, -1, "FloatCanvas Demo App", wx.DefaultPosition, (700,700) )
app.MainLoop()
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Best site to get Numeric and wxPython for new Tiger 10.4 install?
Bill Janssen wrote: >>Apparently most Tiger users are running Python 2.4 > > I strongly doubt that. Python 2.3.5 is what comes with the stock > distribution; I was not very precise. How's this: Apparently most Tiger users that are building and distributing packages are running Python 2.4 > it should be supported. coulda, woulda, shoulda. Bob accepts contributions to the pythonmac site. In fact, he's even said he'll give admin privileges to folks that want to help maintain it. That brings up an issue: In many cases, it is very easy to build a mpkg of a python package once you have it all compiled. If all of us that got packages working on our machines contributed them, the pythonmac site would get much more comprehensive. As for me, I'm still running 10.3, and I try to contribute packages for Python2.3 and python2.4 -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] Problem with applets on MacPython
> Your programs are probably behaving correctly. What's happening is > that none of those application building tools have an option that > attaches a console to them, so your simple console interaction isn't > going to work. Your output is probably going to the "Console" open that up and you should see your output. > In order to make an applet with that sort of console, > you'll need to use a windowing toolkit such as wxPython, Tkinter, or > PyObjC. Which is a bit much for a beginner. I'd get started with using the unix terminal to start to learn and run python. You really don't want to have to build your app into a App bundle while testing it anyway. Start up the "terminal" app. Use "cd" to put yourself in the folder (directory) that your python script is in. Then type: python MyScriptName.py and it should run. You're off and running! If none of that makes sense, then look for tutorials on the web about using the unix command line in OS-X--there's lots of them, and it's well worth learning a bit about. A utility I find invaluable is "Open terminal Here" -- google it and you should find it. by the way, there are a number of IDEs for python on OS-X, and last I heard, none of them were really bug-free enough to use for a newbie. Has that changed? How's SPE on OS-X now? How's PyOxide coming along? etc. If you don't mind spending a little money, WingIDE and Komodo are reported to work well. WingIDE has a non-commercial version that's pretty cheap. Or you can use the command line and an editor--that's served me well for years. Just make sure you get a good, python-aware editor, I'll leave that up to you to research! good luck, -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] Trouble installing PIL package
Ken Brooks wrote: > OS: Tiger 10.4.4 > System: 1GHz / 1GB RAM > Python: 2.3.5 > > Using PackageManager to install PIL Don't use PackageManager, it's outdated. Use the packages at: http://pythonmac.org/packages/ I think the ones for: Mac OS X 10.3 (stock Python 2.3.0) might work with your system, but you're probably better off installing python 2.4 from: http://undefined.org/python/ and using these: Mac OS X 10.3+ (Python 2.4.1 framework build) They'll work on 10.4 We really need to update the pythonmac.org web site! (and Jack's Page) -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] Newbie environment questions
Ken Brooks wrote: > Still nothing changes! So how does the debug loop work? How can I > reload a module short of relaunching the environment?? ^^ You've just inadvertently answered your own question. That's what we mean when we say "Python fits your brain": >>> reload(foo) Python caches modules so that if one module is imported in ten different places, it doesn't reload them each time. To force a reload you use, appropriately enough, the reload function. > 2. I really wish for the "doskey" feature that lets you easily > retrieve and edit a line previously typed to the interactive > interpreter. Does it exist here? Yup. It's called readline. Apple doesn't ship it with OS-X, because it's licensed under the GPL, but you can install in separately, or you can install a new version of python that has it. See: http://undefined.org/python/ for a newer Python, and: http://www.pythonmac.org/packages/ For an assortment of add-on packages There is a readline for th python 2.3 that came with OS-X 10.4 there. It may work with 10.4 also, if you install "TigerPython23Compat" from that page also. All that being said, you might want to try one of the fancier python shells for interactive use, like ipython. Or, just write your entire script in a file (or multiple files) and restart python each time. It's rare that something take that long to run that re-starting is a problem. You can start it with: $ python -i MyScript.py and you'll get the interpreter prompt when it's done running. -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] Problem with applets on MacPython
Kevin Walzer wrote: > I used to maintain packages of SPE on OS X: it was a nicely-designed > application but very unstable. It crashed constantly. > > I've looked at the new version: it seems even more slick than before. > Not sure about how stable it is. Someone gave Stani a Mac, and I know he's been submitting bug reports for various wxPython stuff on the Mac, so I imagine it's much better. I need to go give it a try some day. -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] Building multiple command-line( ( CLI ) programs with py2app
Bob Ippolito wrote: > What do you want to happen, ideally? Clearly you don't want 30 CLI > apps with 30 full Python distributions. There are several > workarounds, but in order to make py2app serve your needs I'm going > to need to know what that is. I've thought about this, and I think the solutions proposed will probably work well for the OP. However, I'd like to have another option. I'd like to be able to install a complete Python distribution that has all the packages my apps need, all in one bundle. Then the individual scripts would use that, rather than the regular installed python. Perhaps you'd have a #! line like: /usr/bin/env MySpecialPython in each script. MySpecialPython would be installed somewhere on the path, and it would be a link or small script that started up a python installed in a bundle somewhere. That bundle would have all the packages installed that all my Scripts need. Currently, what I do is supply a bunch of *.mpkg files for all the packages I need, and my users (of which there are only a couple now anyway) just need to install them all. Not a big deal, but a single, customized "run time" that doesn't interfere in any way with the installed python would be pretty cool. It seems that the Py2App infrastructure could be useful for making such a beast. You'd need to add a way to give it multiple scripts to search for dependencies, then make the primary interpreter something that could be called just like regular python. Once we've got that, we'd also need a way to build "applets", or application bundles that would use the "run time", but would otherwise behave like an application bundle: point and click start-up, icons, etc. This sounds like a good idea to me, because I have a growing collection of small wxPython programs. Each one is pretty small, maybe a few hundred lines of code, but making a full Py2App bundle of each one results in a pretty darn set of bundles! Does anyone else think this would be useful? -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] Building extensions on 10.4 that can be used on 10.3?
Russell E. Owen wrote: > Are there any tips or tricks to building 3rd party python extensions on > MacOS X 10.4 in such a way that 10.3 users can use them? It can be done, but I think it's PITA > <http://pythonmac.org/packages/> has most or all the extensions I need, > but some of the ones I use are fairly outdated (especially numarray). So > another option is to contribute modern versions built on 10.3 before I > upgrade. But I'm not sure how practical that is; I only have 10.3/Python > 2.3 Installing 2.4.1 from undefined.org/python is pretty trivial. In fact, using the 2.4.1 Framework build for OS-X 10.3, and installing it on both 10.3 and 10.4 might well do what you want. I know the 10.3 stuff will all run on 10.4, it's just a question of what C libs get linked if you build on 10.4, using the 10.3 Python. I suspect that if you use distutils, it might all work, but if you build everything on 10.3, you're all set. > with instructions on how to create > the package. This is very easy for anything that builds with distutils. Py2App comes with bdist_mpkg, which will build a *.mpkg from setup.py. The only tricky part is external libs. For instance, for matplotlib, I need to make sure it statically linked libpng and libfreetype, so that the package would run on a stock OS-X. It would be great if you contributed some upgraded packages to pythonmac. -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] Building multiple command-line( ( CLI ) programs with py2app
Bob Ippolito wrote: >>I'd like to be able to install a complete Python >>distribution that has all the packages my apps need, all in one >>bundle. >>Does anyone else think this would be useful? > > Not really... this would require an installer, so you might as well > use a regular Python distro. I don't follow. All you'd need is a *.mpkg of the "runtime", and then one for each applet. Or you could put them all in one. One of the issues with a regular python distro is that the user could be using that distro for something else. If they are doing that they may well need/install different versions of various libraries, upgrade it, whatever, and my applets could break. What I'd like is for my stuff to depend only on a Python distro that I have control over. I thought maybe Py2App would be an easy way to build such a thing. I suppose I could create a python distro in: /Library/Frameworks/MySpecialPythonFramework and put what I need into that. How hard would that be? Could I just make a copy of the regular one and go from there, or is that path hard coded all over the place? The other thing I need to learn is how to put a bunch of *.mpkgs together into one meta-mpkg, so that I can install a bunch of stuff with one click. -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
[Pythonmac-SIG] Mac Python and eggs...
Bob Ippolito wrote: There are eggs up on Cheese Shop for use with easy_install. This brings up a question. I think it's a really good idea if we can decide, as a community, what the canonical way is to distribute packages to the MacPython world. Currently, I think putting a *.mpkg on pythonmac.org is that way. Should we keep doing that? or is it time to switch to putting eggs in the cheese shop ? or eggs on python mac? thoughts? By the way we really do need to update and improve the pythonmac web page. I hope to get to it soon, but if someone beats me to it, that would be great! -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] Mac Python and eggs...
Bob Ippolito wrote: > I'd like to see eggs used for everything that can be distributed as an > egg... but as Ronald says, mpkgs still have their place for packages > that need to install Other Stuff, and as a transitional means. Can you put an egg in a mpkg? > There's no good reason to prefer eggs on pythonmac.org. I don't quite follow. Are you suggesting that we don't put any eggs on pythonmac? If so, then we do put non-egg packages there? I am concerned that that will just confuse the users more. I'd really like to be able to tell people: go to this place, and all available packages for Python on OS-X are there. > setuptools has > built-in support for uploading source packages and eggs to Cheese > Shop. If the package is already registered by someone else on Cheese > Shop, just track them down and ask them to add your user as a > maintainer role, which should allow you to upload eggs. yes, that does look pretty cool. -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] Mac Python and eggs...
Bob Ippolito wrote: > Not yet. Not yet at all? or not yet with bdist_mpkg ? > We could mine Cheese Shop and list the pure python packages, the > packages that have Mac OS X eggs, and the mpkgs. And put the results on the pythonmac site? I like that. -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] Mac Python and eggs...
Bob Ippolito wrote: > Is there a difference? pkg bundles can contain anything that you can > put on a filesystem plus arbitrary executable code to run at various > points during the installation process, so there's nothing they can't > do from a technical perspective. That was my question. I know nothing about pkg bundles. Thanks for all your work on this. -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] Building extensions on 10.4 that can be used on 10.3?
Russell E. Owen wrote: >>It would be great if you contributed some upgraded packages to pythonmac. > Gladly! > > Mostly I want to see numarray 1.5 there. Go for it. I've been meaning to do it, but haven't gotten around to it. > It has C code and links to > LAPACK and BLAS. So...do I somehow need to make it statically link? nope, that one is a piece of Cake. Apple provides LAPACK as part of it's veclib, and I think the numarray setup.py knows how to find it. python setup.py build should do it. > I'll have to > keep a MacOS X 10.3 machine around anyway for testing, so I might as > well build the application on that. Sigh. I think he said that you could build your app on 10.4, as long as all the python modules you use (and python itself) were built on 10.3. As long as you have a 10.3 machine around, you should be all set. -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] Mac Python and eggs...
Ronald Oussoren wrote: > BTW2. This reminds me of the old PackageManager, Jack's plan about it > was to provide a list of easy-to-install packages that are known to work on > OSX. Much can, and has, been said about the actual implementation, but the > idea > is a good one. Exactly. The problem with it was the same as with many other efforts to do this kind of thing for python: the effort was put into building the infrastructure, rather than building the packages. We need to make it as easy as possible to build the packages themselves, and and easy way for them to contribute them to somewhere people can find them. Really, downloading a mpkg from pythonmac.org and double clicking on it really is easy enough. All we need is an easy way to populate it. In addition, Jack had defined the idea of a "scapegoat": for a PackageManager repository, someone was taking responsibility for those being good packages and not viruses or malware or anything. I don't think that's necessary. If we we want the collection to be complete, it needs to be easy to add stuff to it. Let's wait until there is a problem before solving that problem. That's not to say that we should let just anybody upload packages to pythonmac, but if there are a handful of people that can, and they accept contributions from everyone else, we could have a pretty complete selection fairly easily. I do support the idea of using eggs. For me, the most compelling reason is the ability to install different versions. If Bob gets a chance to add egg support to bdist_mpkg, I think all we need to do is use that and put the resulting mpkgs on pythonmac. -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] Mac Python and eggs...
Bob Ippolito wrote: > Eggs and Cheese Shop already have that problem way solved. > > python setup.py register sdist bdist_egg upload -s > > That will register your package on Cheese Shop, build the egg and > source distro, and upload it to Cheese Shop with GPG signatures. Does the egg itself get put on cheeseshop? I just searched cheeseshop for a few packages I often use (NumPy, PIL, matplotlib). They all had links to a download page, but nothing there, and those download pages had the usual assortment of tarball, windows installers, etc (including some eggs). Frankly, that doesn't do any more for me than Google, at least for packages I already know the name of. What that tells me is that there is a need for an OS-X package (or egg) repository on pythonmac. -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] Mac Python and eggs...
Bob Ippolito wrote: > Yes, the egg itself gets hosted on Cheese Shop, as well as the source > download (hence the "upload"). > > The packages you often use are not yet using setuptools, Do you know of a package I can find on cheeseshop that is using setuptools? I'd like to get a sense of what features that offers. > so it's no > surprise that they don't take advantage of these new features that > aren't in distutils. Well, matplotlib has an egg on the sourceforge download site, and NumPy is putting its include files in a odd place specifically to accommodate ssetuptools, and neither of those have eggs on cheeseshop. I guess setuptools really hasn't caught on yet. but it does seem to be gaining a lot of momentum, so I'm hopeful. > Someone needs to convince the maintainers of the > packages that you use that they should be using setuptools, at least > for distribution (but not necessarily as a requirement for installation). > >> Frankly, that doesn't do any more for me than Google, at least for >> packages I already know the name of. > > That's orthogonal. That was based on the fact that I just got pointed back to the project's primary download site anyway, that's usually not hard to find (for a project I know about anyway). If the eggs were available directly on Cheeseshop, then it would be better. >> What that tells me is that there is a need for an OS-X package (or egg) >> repository on pythonmac. > > I'm not at all convinced on that point. The reason we've ever needed it hasn't changed: most package maintainers don't build packages for OS-X. The Mac community has always had to do that itself for most packages. The only exception for the packages I use is wxPython. (and Robin is looking into eggs) If we can't get package maintainers to build OS-X compatible eggs, what good does cheese shop do? It's also really nice to have one-stop shopping for OS-X Python packages. Another issue I wonder about is all the possible combinations of OS-X and Python versions that we're dealing with. Do they all need a separate egg? -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] Mac Python and eggs...
Charlie Moad wrote: > I just thought I would mention that you don't see the mpl eggs on > cheeseshop for a reason. The download url is set to mpl's sf files > page. Setuptools is smart enough to look at cheeseshop and see the > download url and then find the correct egg from there, hence > 'easy_install matplotlib' works. Sorry if I misinterpreted your post. No, you didn't misinterpret my post, but according to Bob, you could easily upload the eggs directly to cheeseshop -- why not do that? Another issue is that the Cheeseshop interface could use some work, as it wasn't the least bit clear that that magic could occur. And the third, is that on the sourceforge download page, I didn't see an OS-X egg. I was about to poke through the MPL list and see what you said about this, but I guess I'll just try: 'easy_install matplotlib' and see what happens. This is all a bit of a mess now, but it looks very promising, and I think Bob has convinced me: For any package I need, I'll try to build an egg, and try to get it uploaded to cheeseshop. -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] Mac Python and eggs...
Christopher Barker wrote: > I guess I'll just try: 'easy_install matplotlib' and > see what happens. Well, first I had to get setuptools installed. cheeseshop has an egg, but how do I install that? So I downloaded the zip file, and in there found that I needed to do: $ python ez_setup.py Which said that it worked, but I couldn't find the easy_install script anywhere. Afer much floundering, I finally figured out that it put it in: /Library/Frameworks/Python.framework/Versions/2.4/bin which is not on my $PATH. Should it be? or should there be links to those scripts in /usr/local/bin? once I got that figured out, I tried to use it to install MPL. It didn't work. I'll move that discussion over to the MPL list. I do think this all has promise, but there are some wrinkles to smooth out, and I'm thinking that maybe, once all is said and done, there will still be the need for "click to install" mpkgs for OS-X. If nothing else, there should be one for setuptools itself! -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] Mac Python and eggs...
Bob Ippolito wrote: > You REALLY should read the docs. Of course I should, and I did. I also did my floundering until I identified the problem before asking for help here. My comment here was bringing up the question of how, on OS-X, we want to recommend people deal with having installed scripts on their $PATH. However, this whole discussion started because I thought we wanted to have an easy way for newbies to find and install packages on OS-X. This has not be easy for me so far, and I am neither an OS-X nor a *nix newbie. If it was just me, I'd just run the setup.py scripts that come with the packages and be done with it, but I want to help out the community, as well as having a standard approach to point my colleagues to. > http://peak.telecommunity.com/DevCenter/EasyInstall The only thing it says there about installing the easy_install script is: "An easy_install script will be installed in the normal location for Python scripts on your platform." You've seen me on this list for years, and I have NEVER noticed /Library/Frameworks/Python.framework/Versions/2.4/bin before. I have had scripts installed in /usr/local/bin. (probably from mpkgs put together by Bob) So, the question is: What should "standard Practice" be for handling scripts installed by easy-install (and distutils, I suppose). I see a couple options so far: * Advise people to put: /Library/Frameworks/Python.framework/Versions/2.4/bin on their PATH. * Have people put symlinks to scripts in there in their PATH. * Follow Charlie's suggestion: Create a ~/.pydistutils.cfg file with: - [easy_install] script_dir = /usr/local/bin - in it. By the way, I didn't see any mention of the script_dir value in the Easy_Install doc. None of those options are particularly newbie-friendly. * Change the default script_dir in the "official unofficial" Framework builds to /usr/local/bin That's more newbie-friendly, but I'm sure has lots of other problems. -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] best way to install packages?
Andrew Jaffe wrote: > Anyway, is there a 'best' way to install python packages on a > mac nowadays? It seems that there at least three possibilities: > >- plain old setup.py install >- bdist_mpkg >- eggs (in which case I realize I'm not sure I know exactly *how* to > do this) The "Best" way to install packages is to use whatever form you get. If you get an egg, use easy-install, if you get a mpkg, point and click it, if you the source, use setup.py. I'm not just being glib here. I wonder if you, in fact, are asking a larger question, which it would be nice to discuss here: What is the best way to distribute packages? Now you have to consider the three options above: 1) Just distribute the source with a setup.py 2) Use bdist_mpkg to build a mpkg 3) Build and egg. The reason I make this distinction is that if you are getting just the source from a package maintainer, there is little reason to go though the trouble of making mpkgs or eggs, if you only want to install it on your own machine. slight modification to that: The is no reason to make a mpkg. You might want to make an egg, so that you can get the versioning control eggs give you (and some other features, but versioning control is the big one) However, if it's just for your purposes, and the package maintainer hasn't set up setup.py to build and egg, it's probably not worth it. That being said, I would love it if EVERYONE that downloads and builds a source package on their Mac would contribute a binary package to the community. Mac users like binary packages! I suggest the following for making a package that can be distributed: - Make an egg. - If you can't figure out how to make an ebb, use bdist_mpkg - I think Bob is working on making py2app support eggs with bdist_mpkg, so that may get easy. However, keep in mind that when you make a binary package, it will only work (reliably) with the version of Python that you build it with. I think the versions we should support are: Bob's "official unofficial" 2.4.1 framework build for 10.3 (this will run on 10.4 also) 2.4.1 framework build for 10.4 There's something to be said for supporting Apple's pythons but I think that's lower priority. And these packages should be put up on pythonmac.org One other note: The Framework builds put the "bin" directory inside the Framework. That's where scripts get installed by default. What that means is that in order to use them, the user needs to add that directory to their PATH. This isn't a big deal, but it reminds me too much of the old DOS days, where you needed to add something to your PATH for every darn piece of software you installed. I much prefer the *nix standard of having a few locations where executables get installed, and I's like to see the default scripts directory be /use/local/bin. Should this be the standard? How could we accomplish that? Or should we just tell people to add the Framework bin directory to their PATH. Mostly I feel strongly that, as a community, we need to establish standard ways of doing Python on OS-X, and publish them somewhere. I'm not picky about what those standards are, as long as they exist. -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] best way to install packages?
Ronald Oussoren wrote: > Even more important that versioning is that eggs give you an easy way > to uninstall software (although I'm not quite sure about scripts). It really does look like eggs are the way of the future. >> Bob's "official unofficial" 2.4.1 framework build for 10.3 (this will >> run on 10.4 also) >> >> 2.4.1 framework build for 10.4 > > Don't. There should be only one binary installation of Python 2.4.x for > every x and than one should work on 10.3 and 10.4. OK. However, if I understand it, if I am running 10.4, I can run a python and extensions that were built on and for 10.3. However, if I build an extension on 10.4, it may well not work on 10.3. What that means is that anyone building extensions on 10.4 can't contribute to the repository of packages for 10.3. However, you also can't run extensions built for a 10.3 python on a 10.4 python, which is why this is such a headache! For that matter, can I build extensions to a python built for 10.3 on 10.4 at all without trickery? I, and all my colleagues, are switching to 10.4 now (I just upgraded to day). I was just thinking I'd go 10.4 across the board, but now I think I may want to stick with a python built for 10.3, if for no other reason that to get wxPython working as easily as possible. > This makes life a lot easier for casual users. Good point. The "standard" approach is for casual users, those doing things like trying to build a universal binary python can do whatever they want! > I'd prefer /Library/Python/2.x/bin as the directory where scripts get > placed > because that directory is easily visible in the Finder and allows you to > install > software for both python2.3 and python2.4. So we need to tell people to add that to their PATH. > The bin directory inside the framework is a bit to hidden for most users > and hard to get to using the Finder. Maybe we could put a link from /Library/Python/2.x/bin to the bin directory in the Framework. That way, you wouldn't need to change the standard script dir. > I'll defer to any standard once it is here :-). Feel free to write a > proposal about a standard, including what needs to be done to get there ;-) OK, I'll get working on that, once I'm clear about all this 10.3 vs. 10.4 stuff. By the way, is there any advantage of the 10.4 build? One other thought: having all these different pythons and what not to support is a pain, but really, once you have the setup.py hacked so that it works right, it's no big deal to build a new package. What that means is that the real goal is to make sure that the patches required to build for OS-X get applied by the package maintainers. Then things will "just work" -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] wxPython build issue
Guys, I'm a bit confused where the problem is here. I've just installed OS-X 10.4, and I'm trying to decide where to go with my python version. I was planning on going all 10.4, rather than using a python framework built for 10.3. However, I need wxPython, so I'm interested in this thread. Bill Northcott wrote: > I have been trying to build wxPython on Tiger (10.4.4 gcc--3.3/g77) > with some difficulty, which may just be me being dense. Is this only a problem with gcc 3.3? What about gcc 4.0? Why are you building with 3.3 on OS-X 10.4? Or should I just stick with the older python build and use Robin's binaries? thanks, -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] best way to install packages?
Bob Ippolito wrote: > You're really confused here. Yes, I know. I was hoping for some clarification. Let me try it this way: I am running OS-X 10.4 I need Python >= 2.4.1 I *need* to build packages that will run on my machine, and I can give binaries to others running 10.4. I can also give them whatever pre-requisites they need, as long as there is )or I can make) and easy installer for it (like a python2.4.1 mpkg, for instance) I also need to build stand-alone apps with Py2app that will run on 10.4 While I'm at it I'd *like* to build binaries that I can contribute to the community and put up on pythonmac.org. Which python should I use? Which gcc should I use when I build stuff? >> I may want to stick with a python built for 10.3, if for no other >> reason that to get wxPython working as easily as possible. > > That's totally backwards... How is that? Robin provided binaries built for both 2.3 and 2.4 for OS-X 10.3, but not for 10.4, so I think that means I need to use the python built for 10.3. In addition, there is a thread in this group right now about trouble building wxPython on 10.4 -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] not appear
Bob Ippolito wrote: > The framework build's bin directory is technically way down inside > the framework, but there are symlinks in /usr/local/bin. However: linda.s wrote: > The > installation appeared to be fine until "make install" was complete. So it looks like the OP didn't do a Framework build. What all this means is that you shouldn't build from source unless you know what you are doing, and have a good reason to. -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] install again?
Charles Hartman wrote: > Maybe linda.s might have a more useful perspective > at this point? Charles, I totally agree with you about newbies and Python. However, linda.s compiled python from source. Anyone who is compiling from source should darn well be able to figure out how to add something to her path. Which brings up the question: why did linda.s compile the source? I'm going to make a guess that she didn't have a good reason, but didn't find the binary installers right away. What this means is that much of the problem is documentation. This has been talked about before, and I think everyone agree that we need to improve it, but someone needs to do it. One other point: right now there are two "recommended" binaries for OS-X: Bob's 2.4.1 framework build ActiveState's 2.4.2 framework build. However, Bob's is not the latest, and ActiveState's comes with licensing restrictions and no readline. So there is no ideal build right now. Bob is working on a Universal build at the moment, and it will be the latest, so hopefully we will soon have a single binary installer that we can recommend to newbies. Daniel Lord wrote: > As for Apple and Python: Apple supports Python just fine- No, they don't. They don't keep it up to date, they are unlikely to keep backward compatibility, and they provide no way to do GUI programmer (not quite true, I think they provided an out-of-date version of wxPython with Tiger). A large fraction of folks wanting to program on the mac will want to do GUI programming. You are also very likely to need additional packages, so that needs to be easy also. > By installing 2.4, a user has installed a > non-Apple-official version so the user has to take responsibility for > setting it up properly. I think Charles point is that the user shouldn't need to take that responsibility, the packager could instead. > Because 2.3 is the official Apple version, the creators of > the 2.4 binary package did not want to overwrite 2.3 and assume the > liability for the users system. Actually, it's also because Apple has included some closed source stuff in their Python. Replacing it without that WOULD break some things. > There is an assumption that when one is using development > tools, one knows a bit more of the technical details on using the > operating system. This is quite true. I think Charles is right, that Python could be a great newbie-friendly development tool for OS-X, but that would require fixing more than this. Really, it would be great if someone bundles up a good python distribution with a good IDE and a good GUI library (PyObjC or wxPython or TKinter). Add some good docs and viola! I think this could even be commercially viable, but someone's got to do it. In the meantime, I do think with a little work, we can make it easier. > But don't blame Python, Apple, or > the great group of folks here who unselfishly keep Mac Python going. I don't think there is blaming: more like expression of frustration and suggestions for improvement. Charles, if you want to help, here's my suggestion: Re-write the main pythonmac.org page, then post your version to this list for discussion. If it is well liked, Bob has already said he'd be glad to replace the current page. Here are my suggestions for a how to write that page: Welcome to Python on the Mac! Intro- links to other python resources, etc. What Python should I use? -- brief discussion of the options. --The "Recommended Option" -- for users without special needs or newbies that don't know what they need - Link to Binary Python 2.4.* installer - Instructions of stuff to do after installing: -- Install TigerPython24Fix -- Add /usr/local/bin to your PATH -- Note: couldn't those steps be optionally done by the installer? - Link to Collection of packages on Pythonmac.org - Link to Wiki pages for people that need to use other Pythons. Perhaps build instructions, etc. What do I do now? -- How to run from command line -- IDE/editor options -- Pointers to "learn python" resources NOTE: I think we can recommend the same thing at this point for all users of OS-X 10.3 and 10.4. It also looks like the new Universal build may become the news recommended Python for OS-X 10.3.9 and above, but it's not ready yet. I was thinking of a decision tree, based on what version of OS-X you're running, and what you want to do (web development, GUI programming, etc), but I think we can, in fact have a single setup that will be best for most people running 10.3 and greater, so we can keep it simple. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-
Re: [Pythonmac-SIG] install again?
Bob Ippolito wrote: > Caveat emptor. You can not build extensions on 10.3.9 when using a > universal build. Fair enough. No is going to be running 10.3 on an Intel Mac. If you want to develop for Intel users, you need 10.4. Period. However, given that, I think we should perhaps just suggest that 10.3.* users stick with a PPC only build. That would give us two builds to support with pre-built binaries, but a bunch are already done. I'm sorry to say that I just switched to 10.4, so I wont' be building an packages for 10.3. > That said, you'd be able to use it, and install all the eggs/mpkgs you > want, but you would not be able to use it with a compiler. The other option is to say: "If you don't intend to build your own packages, use the universal build", but I think that's risky, and a newbie might not think s/he is going to build anything, but will discover later that they need to. > That goes both ways, users of the universal build can't use "legacy" > eggs (marked with ppc or i386 architecture) from the current builds. That's OK. I think we can rally the community to build a good collection of stuff one the universal build comes out. Maybe none of them will be tested on Intel, but so be it! Bob, what do you think the timescale is for a universal build? If it's soon, then we should work on re-0writing the web site as though it's ready to go. -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] install again?
[EMAIL PROTECTED] wrote: > I agree pretty much completely with Charles Harman, Bill Janssen, and > others. So do I, however This is Open Source software! Which doesn't mean that it can't be great in every way, but it does mean that it is developed for different reasons than commercial software, and it will have different features. All of us that contribute to the MacPython community have other jobs, and are only contributing what we can out of the goodness of our hearts, essentially. The reason much open source software is short on easy installers and documentation for newbies is that the people capable of developing those things don't need them. > This > requires letting go of your ego and imagining what the world looks > like from their viewpoint. No, it doesn't. It means taking our own precious time to make something for someone else, just to be nice. That's asking a LOT > Make an Installer > for Dummies. Make an IDE that works in the Mac way. (Where are you, > Glenn?) Make Cocoa access automatic with the installation. Make a > simplified, high-level Cocoa-based GUI API. Make an easy and coherent > add-on method. Make adding SciPy and Chaco a no-brainer. (Oops--wrong > list.) Never require a user to build his/her own software. Don't > expand the user's lexicon with the likes of mpkg, egg, setuptools, > patches, distutils, and so on. That would be a great list IF the primary goal was creating a easy tool for newbies to use. I think there is real commercial potential in making such a tool based on Python, but I'm not in the business of selling software, I'm in the business of doing Oceanography. > You are making end-user software. No, we're not. Most of the Python, MacPython, SciPy etc. community is making software for ourselves to use. Other end users are a nice bonus. > Python with a good Mac-way IDE has so much potential to reach the > same usability as THINK Pascal did in 1984. Yes, it does, but it won't be built until someone who is capable of building it wants it enough to put the time it. I suspect that that will only happen if someone decides to try to make money from 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] install again?
Bob Ippolito wrote: > I'll tell you what: I'll drop the ego and get a new pair of glasses in > exchange for five or six million dollars.. I'll bet I could package up Python, PyObjC etc. with good installers and tutorials for only about a one million dollars. Then maybe another million to start marketing it. Anyone want to fund my new company? -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] a beginner's list
Chris Porter wrote: > And here, Mac comes with Python! Very nice. > That shouldn't be downplayed. All I needed was the Python that was already > installed, plus a couple added things. (I needed Python to talk to MySQL, and > that I had to install MySQL, so there was likely no native ability to do so on > the Mac I've got.) This is my point. You couldn't actually get anything done without downloading and installing _something_. Once you're doing that, it would have made very little difference if you had downloaded and installed a new version of Python as well. However, what would have made a difference is whether or not a package for the MySQL lib were easily available or not. That's why whatever the MacPython community endorses and documents should be a version with as broad package support as possible. I think that's 2.4.*, rather than the Apple supplied python. In addition, if you have your code running just fine and dandy under Apple's python, then you upgrade to 10.5, chances are that your app will no longer work, as Apple is likely to yank their python out from under you. If it were running with a user-installed Python, chances are it would keep working. -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 ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] New Page, first proposal
d the rest in the Wiki, except the download pages. > Somebody who comes idly to the idea of programming in Python, and > finds the pythonmac page, will be happy if the result is an > afternoon's work that ends in a "hello world," possibly in a window. > Using my own arbitrary preferences, that would entail: > > 1. downloading & installing Bob's framework 2. downloading & > installing TigerPython24Fix 3. adding /usr/local/bin to the PATH We really should build an installer that does the three of these at once (with the PATH editing optional). I have no idea how to do that, though. > 4. downloading & installing wxPython I don't think wxPython is that starting point. And I'm a big wxPython fan. > 5. downloading & installing [fill in name of IDE] Until there is one robust enough to really recommend, we're not there yet. How's SPE doing on the mac these days? Also, different IDEs are different, they each need their own tutorial, ideally one Mac-centered, but that's no our job. I do think a little "getting started" tutorial with a editor and the command line is a good idea, however. enough that they can read one of the intro books and know what to do. Bill Janssen wrote: > Who wants to open windows? Why is a GUI automatically necessary? I agree, it's not. And if your goal is web programming, it never will be. > And if it is, all you need is already there on 10.4 Here's where I'm not sure. I do like that it's this easy, and I know the fact that python comes with OS-X has been good marketing for me in my organization. As for the Apple-supplied Python. Yes, it's fine. I used it for a good while. However, it really is getting pretty old. That isn't a problem in and of itself, but people are now making third-party packages that require 2.4, and most of the people building and distributing binaries are doing it for 2.4.1 also. While it's easier for a newbie to get started with the built-in python, they may well hit a brick wall soon. I think that anyone doing any real work with Python is going to need use a third party package pretty soon in the game. As they can't use only pre-installed stuff, it's not that big a deal for them to install a new python as well, if we make it easy. I'm a bit wary of saying to newbies: "Here you go, look how easy this is!", then when they start doing more, saying: "By the way, no that you're really doing something real, you need to go do this extra stuff" I'm not convinced about this. I may vote for a link near the top of the main page labeled "The ultra-quick easy intro to Python", to a Wiki page with this: , in three minutes: > 1) Click on Applications/Utilities/Terminal. > > 2) In the terminal window, enter the following line: > > % pythonw > > 3) You will see a prompt ">>>". At the prompt, enter the following > line: > >>>> print "Hello, World!" > > and you will see "Hello, World!" written back to you. > > 4) To do this in a window, enter the following lines at the ">>>" > prompt: > >>>> import wx app = wx.PySimpleApp() frame = wx.Frame(None, -1, >>>> "Hello World").Show(1) app.MainLoop() > > That's it! Then maybe a little discussion of why (and when) one might want to download a newer Python. Also a pointer back to the page that discusses what GUI toolkit tone might want to use. > *Don't* deprecate the Apple pre-installed Python! Rejoice in it! > And then hint that even better things are available in 2.4.x... I think it needs to be a strong suggestion, rather than a hint. A big part of this is that having a large collection of pre-built packages is key, and I don't see that happening for Apple's Python. -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] a beginner's list
Kevin Ollivier wrote: > It's important to note, though, that you're looking at a use case of > someone who's already familiar with databases, MySQL, etc. and knows > exactly what they want to use Python to do. The only point was that they knew what they wanted to do, and it involved external packages. If they were less familiar, my point would be stronger. > where > people wouldn't need to install extension modules (at least, not right > away) and who probably would do fine with the Apple-installed Python. This is key: 1) you really can't get far without extension modules 2) Where do you put the learning/effort curve? (a) up front: do this extra work, and you're set. (b) later: Here's an ultra easy way to do it --- then when you try to do something real, you'll need to do the extra work then. (b) is probably better fro selling something -- "get them hooked, then tell them how much work they really have to do". That's why most commercial software is structured this way. (a) is better for getting people quickly to where they really need to b if they are going to use Python for real, and I think we can get (a) easy enough that it's not a big deal. The real impediment to getting total newbie/casual users excited about Python on OS-X is the lack of a nice, fully integrated IDE/GUI toolkit with tutorials and all. We'd all like to see that, but none of us need it enough to build it. > (I was fine with 2.3 for over a year after 2.4 was released, > believe it or not!) So was I, but it's really getting pretty old now! > If broad package support was going to happen on Mac, I really think it > would have happened by now. I disagree, but maybe I'm wrong. I think that if we focus on one python version, and create an easy way for people to contribute packages, we can get a better collection. With Py2App and bdist_mpkg, it's really, really, easy to build one, once you've gotten it to build at all. That's been the case for a while, but I do think if we can focus the community, we can do much better. I need to build the packages for my colleagues anyway, if it's easy to contribute them, I will. > I'll tell you why I don't package: > I don't have time to support or maintain the packages. As much as I love > the Python community, I can't afford to be a point of support when > something breaks, or when someone needs an upgrade, etc. and I don't > believe in just dumping things in somebody's lap and saying "good luck!" Here's where I actually agree with your previous point. I have the same issues. I built a matplotlib package (for 2.3 and 2.4, actually) and contributed it to pythonmac.org. Soon enough, MPL was upgraded, and I got the occasional note asking for an upgraded package. I didn't need it myself, so I didn't do it. However, I still think it was helpful that an OS-X user could easily install and try our MPL. If they liked it, they could go through the effort to build the latest version themselves. This is different than the Apple-supplied python issue. I'm only suggesting that we recommend an alternative because we can provide one that's easy to install. I'd never tell newbies to python to go and build their own from the tarball! > do a quick writeup for beginners about what setup.py commands can be > used to install most Python packages. We should certainly do that. However, there are OS-X users without a compiler installed. This is a real problem, and Apple doesn't even make it that easy to install the compiler. Linux users all have compilers. Windows users all get binaries -- the closer we can get to that for the Mac the better. > I must have thought to myself "wow, you can do that?!" about > five times when reading Robin's wxPython build process docs. There is no replacement for good docs, and those are good, but let's face it, there are a LOT of questions on wxPython-users from people trying to build it themselves. > In short, you might be surprised at how many potential Mac Python users > would really be helped simply by reading Bill Jannsen's step-by-step > tutorial. I strongly feel we should put that up for beginners' in some > sort of "30-second Python quick start", as was suggested earlier. > Instant gratification has been found, in some instances ;-), to have a > positive impact on peoples' first impression of your product or service. > ;-) I do think that's a good idea too, but don't let them get too far before suggesting an upgraded Python. -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] a beginner's list
Bill Janssen wrote: > You had no idea about it because it's not going to happen. "Apple is > likely to yank their python out from under you"? Come on, this is > absurd. In 10.5, /usr/bin/python is likely to be Python 2.4 instead > of 2.3, but the odds are to 1 that it will be there, and the > Python community has taken great pains to make sure 2.4 is > backwards-compatible with 2.3. > > We can only quote odds because none of us work for Apple, but still, > in my opinion -- what troll-bait! It was not intended that way. Yes, Apple will most likely supply a Python with 10.5. It will also most likely be a 2.4.*. What I don't see any evidence for is them keeping 2.3.5 around as well. What that means is that all the packages you have compiled and installed for 2.3.* will no longer work. Yes, python-only scripts that use usr/bin/python will most likely work, but that's it. If you think Apple will keep 2.3.* around, in addition to a newer 2.4.*, then tell us why. They didn't keep 2.2* around when 10.3 came out. -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] New Page, first proposal
Charles Hartman wrote: > I just don't believe it should > be necessary for those people, at first, to take on even the beginnings > of Unix in order to brave taking on Python. How are they going to do it? Is there a single free IDE that you think is ready for this kind of user (including the install)? I don't know of one. Without an IDE, you have the terminal (which is an IDE, as a matter of fact, but not a GUI one!) You're right that it shouldn't be necessary, but I think it still is. The lowest common denominator at this point needs to be a willingness to learn a bit about using the terminal and an editor. -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] a beginner's list
has wrote: > - professional Unix developers who want to use Python on OS X just > the same as they'd use Python on any other *nix If this means non-GUI apps, then they don't need any help from us, except maybe one line about how python acts exactly the same from the command line on OS-X as it does on any other *nix. The MacPython page should focus on what is different or special about using python on OS-X -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] a beginner's list
Kevin Ollivier wrote: > As does just explicitly upgrading your Python. I don't see why it's > breaking if you install Leopard, but upgrading if you install MacPython > 2.4 from pythonmac.org. Either way, your 2.3 extensions don't work and > you have to start from scratch. And either way, if you thought things > would "just work" you're in for a rude awakening. > > So what's the difference? The difference is that when you upgrade OS-X to leopard, you may or may not know that you are upgrading Python, and if you did know, you may not want to. I started this with a reference to a particular poster, that had installed some sort of Python app (I'm guessing a web app), and he got it work by installing the needed extensions. When (If) he upgrades OS-X, that app will break. Almost every other app he has installed on his system will continue to work, but the python based one will not. This would apply to any app using the built in python and any extensions: simple scripts, py2app bundles, etc. If those were using a user installed python build, they would continue to work when the OS was upgraded. It's kind of like having apps linked against certain versions of shared libs, except that I think Apple makes a point of keeping old versions of their system libs around when the put out new ones. -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] a beginner's list (Or: everyone's talking; no-one's listening)
has wrote: > I think what's happening in this discussion is we've got two camps > talking past one another. > > One side sees the problem primarily as a marketing issue: "How can we > attract the widest possible audience, i.e. both serious and casual > users?" > > The other sees it as a purely technical issue: "How can we provide > the latest, best tools for the minimum amount of time and work?" Well, no. The primary developers are primarily interested in the latest, best tools, yes. But everyone involved in this conversation is trying got figure out how best to market to casual users -- the truly serious ones are all set. > I have no problem with folk like Chris and Bob saying they're only > interested in supporting serious comers. That's not at all what I'm saying. I'm not interested in supporting the totally casual newbie, but only because that's not a marketing issue. We don't have the integrated IDE-GUI Toolkit-docs to support them. Let them buy RealBasic or RuntimeRevolution, or whatever. I am interested in supported users that are casual enough that they may not have the Apple developer tools installed, but are interested in at least learning to use the terminal and an editor a bit. > and isn't intended to, appeal to all sections of the audience out > there. I think we can have a single approach that support everyone between the "I'd like to learn a bit about the terminal" user to the "I'll compile it myself, but I'd rather not, if there's a binary that meets my needs" user with the same approach. > If folk can agree on the latter approach, both camps should set up on > the same website, and each look after their own sections of interest. I don't think there is any problem here. Bob is responsible for the pythonmac.org site, and He's made it very clear that he'd be glad to see it updated for newbies, but he's not going to do the work. Fortunately, Charles is ;-) > As for the frontage, split it across the middle: top half for the > cheery "let's introduce you to Python in 30 seconds" spiel; bottom > half for"here be the hardcore haxxors; come be one with us if you > think you're hard enough". And somewhere in the middle, you can have a > Top 10 lists of why it's really worth upgrading to the latest and > greatest Python et-al, providing a natural path for casual users to > follow once we've got our hooks in 'em good and proper. That's a pretty good structure. I think the real debate here really boils down to one issue: What do we present as the "standard" python to use on OS-X: the Apple supplied python or the Framework build of 2.4.1. then of course, there's a lot of details to be worked out. However, I think a consensus is building: -- define the Framework installer for 2.4 as the "standard" and most supported python for OS-X. (the existing build for 10.3 and the universal build for 10.4) -- also provide at least a quick tutorial for newbies, based on the built-in Python, and put a link to it near the top of the main page. -- At the end of that tutorial, give an explanation of why (and when) one might want to install the newer build of Python for further work. Does anyone strongly disagree with this? -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] New Page, first proposal
Charles Hartman wrote: > But we're not. I never use the Terminal with Python. I use WingIDE > (can't recommend to beginners because it uses X11). Um, why not? I think X11 now comes with OS-X by default. Or does it jsut look&feel too non-Macish. However, I think we need to have a totally open source (or at least free-as-in-beer) approach, even if we have recommendations for commercial products as well. > Nor is their relation of source file to output particularly > (graphically) clear. What does it set the working directory to when you run a script? >> The more I think about it, the less terrible the Terminal sounds. >> Starting as session there is easy. Any files saved go to the >> user's top directory. A next step is just to show them how to >> change directories. I agree. It really is easy enough. For most people. > Learning even a simple subset of UI commands at the > same time, which have no apparent conceptual connection to the > problems you're attending to in writing your first programs, makes it > harder. I just don't see why we need to leave that obstacle in the way. We don't have the tools to not do it, that's why. However, if we make sure the installer automagically takes care of the PATH issue, we can then recommend the "Open Terminal Here" applet, and things get pretty easy: navigate around to your script in the Finder, click "Open Terminal Here", type "python NameOfMyScript.py", hit return, and your code runs. Hit the up-arrow, then return, and it runs again. They don't even need to know that the terminal isn't a special tool for running python scripts! BTW, "Open Terminal Here" is a nifty applet you can put in your finder that you can click on, and a terminal window will open, and cd itself to the directory that the finder is currently viewing. It's clearly an ugly hack, but it does the job: http://www.entropy.ch/software/applescript/welcome.html Why the heck Apple doesn't build that functionality into finder is beyond me. > You're absolutely right. This is the (*the*?) question that I think > we need to settle, to some degree, before any organization of a new > page can make much sense. I don't think so. We know we want the "Easy start for Newbies" page, we don't have to know what to write in it before writing the rest. Let's not get too ambitious right now. If we can just clean up and make clear that main page on PythonMac.org and we'll have made some good progress. -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] a beginner's list
Kevin Ollivier wrote: > My point is: When people upgrade > Python, anyway, anyhow, their extensions will break. MacPython 2.4 > doesn't do anything more or less than Apple's Python in stopping that; > it simply lets you put off upgrading your Python should you want to do so. Right. To be softer: I think it's a good idea to only base your stuff on things you either control or you're confident your OS vendor won't change in the next release. That's why I advocate installing your own Python. > Python extensions always break when you upgrade the major Python > version. Users *should* be aware of this, regardless of what platform > they use or where they get their Python from. Sure. > nothing Apple can do to resolve the problem except stop updating Python > or stop bundling, both of which would be very bad. Yes, they could. They could keep 2.3.5 around and add 2.4.* to it, rather than replacing it. That's what I do when I upgrade. Then all my utilities still work, while I slowly add all the extensions to the new version. I had 1.5.6, 2.0, 2.2 and 2.3 on my Linux box for a while! I'm not sure Apple should do that, and if they did, I'm not sure how long they should keep it up -- you could get a lot of python versions lying around after a while! By the way, Kevin, do you have any idea how hard it's going to be to build wxPython far and with the universal python Bob et. al are working on? -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] 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] 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] New Page, first proposal
ing "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 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. Vinogradov wrote: > What about other sources for python2.4 such as fink and darwinports? > Will they be frown upon or required to comply with framework > installation? We can't require a darn thing about fink or darwinports. They should be mentioned, under something like: If you are using fink or darwinports for other unix-y software or If you want to have complete unix-y environment in your Mac 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. > 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. Bob's always made easy to install packages of his builds -- it could be better, but it's there, and far from wasted. Also, patches get into the main python source, and even Apple gets those eventually! It's just not that bad. All we really need is a couple better web pages, and a few more pre-built packages, and we'll be serving all but the total mac-centered newbies. What those folks need is a complete environment with a single installer. 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? > 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. yea!! > 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. > 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. I hope I'll have some time to really comment on Bill's prototype page tonight. -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
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/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] 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: If you are Python programmers coming from Windows or Linux: etc -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
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/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
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/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
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/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
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/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] Debugger
Bob Ippolito wrote: > I believe there's a debugger in IDLE, and the one in Wing IDE is > pretty good (but that's a commercial X11 app). Normally I just use > pdb, which is strictly console based. If you have wxPython, there is also WinPdb: SPE comes bundled with it, and it can be used on its own. Does PyOxide have a debugger? You'd also be amazed at how far you can get with the command line and a bunch of sprinkled print statements. -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
Bill Janssen wrote: > You missed the first part of my message, I think. The system version > would be installed under /usr/libexec/, or some such place, not under > /usr/bin/. That is a good idea, but how do we get Apple to do it? > That would leave /usr/bin free for the MacPython gang to > install its version, or at least a symlink to /usr/local/bin/pythonw. Except that, ideally, third parties should NEVER put ANYTHING in /usr/bin. However, if we put out stuff in /usr/local/bin (or /opt/whatever), and there was no "python" on the standard path, we'd have less confusion. Way back when Redhat used python1.5 with a bunch of added extensions for its admen tools. All their tools had "usr/local/bin/env python" in the #! line. This was a pain in the *&$^&%* when you wanted to upgrade your standard python, just like it's a pin now with Apple. However, all they needed to do was put a darn version on the #! line: /usr/bin/env python1.5 Apple could do the same thing, then all their admin tools would be insulated from adding additional, newer pythons anywhere on the PATH. I can't do anything about what Apple does, but I always put a version number in all my #! lines. This makes sure it uses the python version I want it used with, regardless of environment It also makes it clear to me, and anyone else that may read that script, what version is was developed against. Yes, when I get rid of that version of python, I need to go change a bunch of #! lines, but I like that too, because it assures that I am aware of what I've changed, and I can test against the new version of python when I do it. I like to see this as a universal practice in the Python world -Chris NOTE: Even better would be a way to specify multiple versions in order of preference, and a python launcher that would sort that out for you. This would be particularly nice on Windows, where you can only associate *.py with one thing. Maybe some day I'll want that enough to write it! -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/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] Build script for Universal Python
Ronald Oussoren wrote: > I remember that. Is that icon still available? Isn't it used in the Wiki? (the wiki seems to be down at the moment) > That icon was a lot > better than what we have now, if anyone complains about the realism > they can come up with another icon :-). And I second that: I love 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] final? try at new MacPython download page
Charles Hartman wrote: > The two big topics -- topics that loomed large for me when I started > trying to figure out whether I wanted to use Python on the Mac -- > aren't really addressed yet: alternative IDEs (Wing, SPE, PyOXIDE if > it were working, etc) and GUI libraries (especially wxPython). > If these doesn't go on the first page -- I guess the consensus may be > against this -- then shouldn't they go in the FAQ? They should go in the Wiki, one page for each topic. The topics are too big for a FAQ. One of us needs to start writing them. > I see wxPython > mentioned there, very much in passing, and with a virtual deprecation > in the same sentence That may be out of date info. wxPython has improved a LOT in recent releases. It's a Wiki, we can update 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] Build script for Universal Python
Kevin, you are completely right about the icon issue, but someone needs to lead the effort --- will you do it? If you want it to be adopted by the general Python community, Guido is the obvious one to ask. By the way, I've heard there is a (slow) effort afoot to update the python.org web site -- perhaps they've already done done icon work, or other graphic work that could be adapted. -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] Build script for Universal Python
Ronald Oussoren wrote: > only reason > for having a discussion about the icon anyway is that some people claim > that > a photo-realistic snake-related image will scare some users away. The other reason is that we don't want to use an Apple trademark. > http://beta.python.org/ I don't love it, but it's fine, and it would scale well to different sizes. Using the same icon as the web site is a very good idea. Does anyone know how final that look for the web site is? -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] Download page on www.python.org now updated
Donovan Preston wrote: > Stop with the 16 ton weight/snakes/apples debate. Just use the new, > official, python logo, +1 -- 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] simple help?
Charles Hartman wrote: > I'm getting really tired of not understanding this: Can someone point > me to some single place that explains the whole path / PATH / > PYTHONPATH arrangement for Python? I know there are two sorts on the > Mac, framework and /usr, and I know some other bits and pieces, but I > have no clear overall picture. > > This came to my attention when I downloaded and installed IPython, > which looks very nifty. I put it in my MacPython folder in / > Applications -- but that's not really where it belongs, I think ipython is an executable script, so you want to put it where those go. For stuff not installed by Apple, that is usually: /usr/local/bin then you want to make sure /usr/local/bin is on your PATH. You do that by adding it to your /Users/YourName/.profile file, like this: export PATH=/usr/local/bin:$PATH A little googling should give you more info if you need it. One more complication: the default dist-utils install directory for scripts is not /usr/local/bin. It's a bin directory buried in the depths of the Framework somewhere (I can't tell you where, as I'm at home on my Linux box right now). You may want to add that to your PATH too. The upcoming new installer is going to do that for you. good luck, -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] simple help?
Charles Hartman wrote: > I think that part of what confuses a non-Unix person like me is the > distinction PATH / (executable programs and scripts) vs. PYTHONPATH / > modules. (This comes up with IPython because embedding its interpreter > in another program requires importing a module IPShellEmbed.) Usually, they really are totally unrelated, but I guess it can be confusing when a package contains a program and also modules for use with other programs. > I find > that my environment contains no PYTHONPATH variable, presumably because > I've just been using the modules supplied with Python and with wxPython, > and the installers have put them in (some) default places. So I assume > that the new installer, too, won't set a PYTHONPATH. I have never needed a PYTHONPATH. Almost everything gets installed to the default location (site-packages). That's probably the case for almost all people that are the primary user of their machine. The main exception is if you have a bunch of modules you want to use that you don't want to install in the system python. I've never had a need for that, but some do. -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] wx.ART_NEW, 'module' object has no attribute 'ART_NEW'
> On Mar 7, 2006, at 8:10 AM, Kevin Ollivier wrote: >> I suspect what is happening is that Python Launcher is using the >> system Python 2.3 installation instead of the Python 2.4 one you >> installed. Do a Get Info on the demo.pyw file and see if it says >> PythonLauncher (2.3.5) as the default app to open that file. If it >> does, try changing it to PythonLauncher (PythonLauncher version >> 0.1) and see if that helps. as I understand it, PythonLauncher respects the #! line of start up scripts. That means that you could change the #! line in the relevant scripts to something like: #!/usr/bin/env pythonw2.4 I like to put a version in my #! lines, as it document what version I've tested with, and it lets me have scripts that use different version on the same system. Will changing the default app for a given *.pyw script change it for all *.pyw scripts? -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] simple help?
Bob Ippolito wrote: > On Mar 8, 2006, at 4:28 PM, Samuel M. Smith wrote: >>So does the new Python Installer create ~/Library/Python/2.4/site- >>packages? Or must one create it manually? > > One must create it manually. I think it should create it, it will make things a tiny bit easier for some folks, and what's the harm? -CHB -- 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 ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] simple help?
Ronald Oussoren wrote: > Nothing will automaticly install in ~/Library/Python/2.4/site-packages, > which means automaticly creating the directory is not very useful. I'm > sure I wouldn't notice the directory if it were created, and I'm sure > I wouldn't be the only one. > > This doesn't mean we shouldn't improve the documentation :-). My thought is that if we have docs that say something like: If you have modules that you want accessible by a particular user, rather than the whole system, put them in: Users/TheUserName/Library/Python/2.4/site-packages It would be nice if that directory existed. On the other hand, when the installer runs, do we create one only in the user's directory that's installing, or all users directories, or??? Maybe it's just as easy to just tell people to create it if they need 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] Recurring question - which python should I use?
Bill Janssen wrote: > Or, at least, I don't know how to build a Mac installer that installs > a complete Python along with the other code it needs. If there's a > cookbook way of doing that, I'd be interested, too. Bill, Do you really not know about Py2App? It occasionally has some tricky bits, and doesn't yet work with the new universal build, but it is still better than anything else out there for any platform. In fact, with my limited testing, it has always "just worked" which I can not say for py2exe. As a note, a big part of the discussion about what version of python the macpython community should endorse centered around the advantages of using a non-Apple build with py2app. -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] Recurring question - which python should I use?
Bill, You have unique needs that are far beyond what most people mean by "distribute my app"! Bill Janssen wrote: > none of the available-for-Python-on-the-Mac portable GUI > systems are good enough wxPython is really the only portable option right now -- what is not good enough about it for your needs? I'm curious. (I have hopes for GTK+ on Cairo, with the > Imendio-sponsored port at > http://developer.imendio.com/wiki/Gtk_Mac_OS_X). That would be nice, but I'm not all that optimistic that it will be ready that soon, or look&feel very Mac-ish. People complain about that enough with wxPython. > along with 2 Mac apps > written in Java as bundled jar files (for Swing). What does SWING give you that wxPython doesn't -- again, I'm curios. > When building an installer, I build the Python extensions from source > (using the system Python) and install them under /usr/local/mysys/... > The post-install script in the Mac installer then inserts a .pth file > for my system's extensions in the system Python's site-packages > directory. This allows all the command-line Python scripts to use > them, along with the daemon. > > Can you suggest a better approach? I don't know that it's better, but once you're doing all that, it really wouldn't be a bid deal to distribute the new FrameWork installer as well, and then not be dependent on Apple's Python. What you have now will most likely break if the user upgrades OS-X, as Apple is likely to upgrade their python, and then your .pth file could disappear and, more fatally, your compiled extensions may not work with the new one. The rest of the process would be the same. I'd like to be able to build a "Python Runtime" that included all of the Framework build, plus the full set of modules that I need for my apps. then I'd like to be able to run command line apps against it, and use Py2Applet (no, it doesn't exist), to build Application bundles that relied on that runtime. This seems to me to be a good solution for folks like us that are distributing not one app, but a bunch of apps that all depend on the same stuff. In my case, I have a set of small GUI utilities, and some command line scripts -- it seems a bit crazy to bundle up the entire python and wxPython with a 200 line script! Or more to the point, the same pile with a number of small scripts. I think all this could be accomplished with a small amount of hacking on Py2App, but I have no idea if I'll ever get around to that. On the other hand, I wonder if the "runtime" could be built by simply installing the Framework Build, installing all the extensions you want, then making a big tarball out of: /Library/Frameworks/Python.Framework After all, I think one of the points of Frameworks is that they are self-contained. You could then even give it a different name (MySpecialRunTime) and put a few links into usr/local/bin to whatever you need in: /Library/FrameWorks.MySpecialRuntime.framework/Version/2.4/bin/ Would this work? I may just try this some day. -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
[Pythonmac-SIG] New Python icons.
Hi all, I just noticed on c.l.p that someone has whipped up a set of icons based on the new one on the website. I know Kevin O. is working to come up with something better, but I figured it wouldn't hurt to take a look at these: """ I've taken the opportunity to knock up some icons using it, finally banishing the poor old standard-VGA-palette snake from my desktop. If you like, you can grab them from: http://www.doxdesk.com/img/software/py/icons.zip in .ICO format for Windows - containing all resolutions/depths up to and including Windows Vista's crazy new enormo-icons. Also contains the vector graphics source file in Xara format. You can also see a preview here: http://www.doxdesk.com/img/software/py/icons.png -- And Clover mailto:[EMAIL PROTECTED] http://www.doxdesk.com/ """ -- 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] py2app is building semi-standalone package only.
Read, Thanks for posting a summary, it's nice to have this in the archives. A few notes: Read Roberts wrote: > To get a separate installation of Python 2.3.x under Mac OSX 10.3, Why not just use 2.4.1 ? Is there a reason you need a 2.3 version? > Two wrinkles to be aware of: > 1) location of command-line 'python' > In a plain Mac OS X 10.3 installation, the command 'python' works because > the system environment variable "PATH" contains a reference to "/usr/bin", This is totally standard *nix stuff. > puts the symbolic > link under "/user/local/bin", Also standard. "local" more or less means "not installed by the OS vendor" > which is not in the default PATH environment variable. which is too bad. /usr/local/bin is such a standard for user-installed stuff, I've always wondered why OS vendors don't' just put it in the default PATH. > I added a symbolic "python2.3.5" in the directory "/usr/bin, > pointing to the python program under 'Library/Frameworks/Python.framework", > so I can invoke this python with the command "python2.3.5". Here's where you've deviated from the standard: As a rule, you shouldn't out ANYTHING in /usr/bin. that's Apple's job. As you haven't written over anything, it's probably not going to cause any problems, but the usual solution is to add /usr/local/bin to your PATH instead, but adding a line something like this to your /Users/YourName/.profile file: export PATH="usr/local/bin/:$PATH" That will tell your shell (if it's the default bash shell) to look in /usr/local/bin for executables before the other places it looks. -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] py2app is building semi-standalone package only.
Bill Janssen wrote: > Read, my installers put links in /usr/bin/, too. It's really the only > way to go, until Apple provides something like the Windows registry > complete with a programmatic API for it. AACCK! NOO! You sure don't need the nightmare of the registry for Apple to make this kind of thing easier. 1) They could just have a standard place for user-installed command line apps to go (/usr/local/bin is a fine choice), and PUT IT IN THE DEFAULT PATH! 2) you mentioned a programmatic API: In fact, I think there is a plist somewhere that sets the default environment variables for all apps, you could add a PATH entry (or add to it) programmaticly easily enough. 3) PATH is only relevant to command line apps: if you've never gone back from using a GUI -- you'll never need to care about this. 4) I've used a GUI for many years: Macintosh, various flavors of Windows, KDE, etc -- I still keep going back to the command line for some things. -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] Upgrading to Python 2.4 and handling packages (e.g. Numeric, wxPython, etc.)
Lou, Thanks for the summary, you beat me to it. I'm a bit surprised that you didn't already know this -- I thought is was made pretty darn clear that you needed to re-install all your add-on packages when you installed an upgraded Python. In fact, that's one of the reasons' not to use Apple's Python -- when they upgrade, it you'll need to re-install everything. I guess we still need to work on the docs. > Many thanks to Bob Ippolito for supplying those packages. Bob built many (most?) of them, but some were built by others, and given to Bob to put on the site. I say this because: > Reinstalling the kinds package. I assume you already have the package > in your Python files directory. You need to reinstall it after you > upgrade to Python 2.4. Do this by opening the terminal, cd to the kinds > folder and type > > sudo python setup.py install Why don't you build a package out of this? If you install Py2app, you can run: bdist_mpkg and you'll get a nice package that you can give to Bob to put on the site. When we get the released version of the Universal binary, I hope many folks, like you and I, will make packages and contribute them. I think a large collection of ready to install packages for OS-X will do a lot to lower the barrier to entry for new Python users. > Create the file kinds.pth with the > single line in it, This is a bit odd. These days, most packages are built to not need a *.pth file. I think all you need to do is have a __init__.py file in the package directory. I'd encourage the kinds developers to update their setup. by the way, what is kinds? the word "kinds" is so common I'm having a hard time finding it with Google. -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] Upgrading to Python 2.4 and handling packages (e.g. Numeric, wxPython, etc.)
Louis Pecora wrote: > Any ideas? yup. Py2App should have installed a script in /usr/local/bin called bdist_mpkg. If that's on your PATH, you should be able to run: bdist_mpkg in the directory that your setup.py lives in. -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] Installing numpy 0.9.6 problems
James Boyle wrote: > I am running gcc 3.3. I note that the python 2.4.2 was built using gcc > 4.0.1. Could this difference in gcc versions be the problem? > At present I am at a loss as to what to try next. It sure could. The thing to try is using gcc 4.0.1: sudo gcc_select 4.x You may need to upgrade your XCode tools to do this. -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] Upgrading to Python 2.4 and handling packages (e.g. Numeric, wxPython, etc.)
Louis Pecora wrote: > % python setup.py bdist_mpkg --open > > at the shell prompt.Is that right? I'm sorry I wasn't clear: >> bdist_mpkg at the shell prompt, all by itself (it's a script) should do it. If there is a setup.py in the directory you type that in, it should use 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] [ann] Appscript Installer 1.3 released
Bill Janssen wrote: >> It is officialy released, even if Bill hasn't updated the download >> page at python.org yet. Are we really ready to call it the "official" version to use? I just had a colleague try it, then he asked me how to get wxPython and numpy working with it. I don't think there is a wxPython build for it yet (will the one for 2.4.1 work?) And he couldn't get numpy to build and install right. I didn't try to debug that for him, instead I suggested to just use 2.4.1 for a while longer. If the new universal build is it now, we need to update pythonmac.org/packages with some information about what packages will work with it, and start building new universal packages! I know I need: wxPython numpy matplotlib At the very least, so I'll help with those, though wxPython is beyond my skills. -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] Upgrading to Python 2.4 and handling packages (e.g. Numeric, wxPython, etc.)
Louis Pecora wrote: >> >> bdist_mpkg >> >> at the shell prompt, all by itself (it's a script) should do it. If >> there is a setup.py in the directory you type that in, it should use it. >> > Did that. Python can't find bdist_mpkg . Python can't find it?, or the shell can't find it? There is a script in usr/local/bin called bdist_mpkg and a module that should have been installed with Py2App also called bdist_mpkg. If you post your output, maybe we can figure out what's wrong with your installation. For me, the bdist_mpkg script looks like this: #!/usr/local/bin/python from bdist_mpkg.scripts.script_bdist_mpkg import main main() Pretty simple. If I start up Python, I can see where the module is installed: Python 2.4.1 (#2, Mar 31 2005, 00:05:10) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import bdist_mpkg >>> bdist_mpkg.__file__ '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/bdist_mpkg/__init__.pyc' I suspect that you installed a PY2App that doesn't match the python you are using, so it's installed in the wrong place. I'm really looking forward to when (soon!) we have the Universal 2.4.3 and we can all just work hard to support that ONE version! -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] Installing numpy 0.9.6 problems
Ronald Oussoren wrote: > I'd prefer to have 1 installer for python on OSX, that makes support > a lot easier. And we would like to by able to use Py2App to build apps that will run under both 10.3.9 and 10.4.* -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] [ann] Appscript Installer 1.3 released
Ronald Oussoren wrote: > wxPython definitely works, I've tested it. That is, if you are on > a PPC box. The existing wxPython binary installer installs a PPC binary, > that won't work with a universal build on intel. That's good to know,but we really do need to get a Universal build of wxPython (and lots of other stuff!) built. It looks like it will beg a bit of a project, and it doesn't look like any of the people who really know what they are doing (Kevin O, Robin, ??? )have the time and/or tools for it now. I'm going to give a try this week myself. Prepare yourselves for questions! I'm also going to take this to mean that, in general, all the packages built for the 2.4.1 Framework build should work with the Universal build On PPC. Users of the Intel machines are probably still better off using the 2.4.1 PPC build and related packages, and it will all run under Rosetta. > Feel free to provide universal packages, and tell us about software that > doesn't work with universal python. I'll be working on that this week. I don't have an Intel box to test on at the moment, but should be getting one soon. > Even a wishlist for packages would be useful. wxPython numpy Numeric numarray matplotlib PIL I can work on all of those. Then: PyGTK : Is there a version that can work entirely fink (or darwinports) free? PyQT: that's going to be fun! -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] Marking the pre-built extensions as Intel-capable...
Bob Ippolito wrote: > That whole section really needs to be restructured to address the > common questions and issues people have regarding finding the right > packages for them. great idea. > I think I'd like to turn http://pythonmac.org/ > packages/ into just a launch pad for finding a list of packages for > the Python that you're interested in. Do you mean that it wouldn't actually host them for download there? Please no. I think it is a VERY good idea to have a collection there for download. Pretty soon, I think we'll be able to call the 2.4.3 Universal build the "officially recommended" build, and we can have a collection of packages there for it. I now I'll contribute a few, and I'm sure others will as well. One question is: should they be eggs or traditional *.mpkgs? -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] Marking the pre-built extensions as Intel-capable...
Bob Ippolito wrote: > No, I mean that that URL won't directly list any packages. It'll be a > listing of package lists and enough information to direct a newish user > to the right list. Then yes, that's a great idea. I am, as we e-speak, reworking those pages with a different structure now. I'm no web designer, but it should give us something that someone can make prettieer if they want. > I'd certainly prefer eggs where possible, but transitionally we're > definitely going to need *.mpkgs. Maybe both for now, and/or separate > pages for .mpkgs and binary eggs? What happens if you double-click on a *.egg? I like that anyone with OS-X can figure out how to install from a *.mpkg -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
[Pythonmac-SIG] The Universal Buld and py2app
Bob, What's the status of Py2App and the new universal build. I'd like to start making packages for it, but I"d really like bdist_mpkg. Or should I figure out how to make binary eggs instead? By the way, is it possible to have the new universal build co-exist with the 2.4.1 framework build? At the moment, everything seems to be working, at least on my PPC machine, but it makes me a bit nervous to just write over what I've got working. A clarification for others: AFAICT, on a PPC Mac, the new universal build can be used with old, PC only, packages for 2.4.1. This means that for those of us on PPC machine, we can have all the old packages while we test and build new ones. Very cool. -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] Marking the pre-built extensions as Intel-capable...
Ronald Oussoren wrote: > Before anyone starts coding, what should happen when you double-click > on an egg? I'd say this should bring up a dialog that allows you to > install the egg and possibly set some options. Installation will be done > using easy_install. That sounds good to me. Does easy-install come with the new Universal build package? Or is a good first step to make a package out of that? I'd like to start populating the world with Universal packages. I see a couple possible routes: 1) wait for Bob to finish Py2App (bdist_mpkg): I think he's indicated he's hoping to get that done this weekend. 2) build *.eggs, and hope someone comes up with a app to associate them with later. (and it the meantime they can be installed with the command line easy-install 3) just build them for myself, and wait until this settles out some more. Maybe start a Wiki page with a list of packages and an indication of what was needed to do to build them. -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] Marking the pre-built extensions as Intel-capable...
Ronald Oussoren wrote: > For casual users it is easier to install mpkgs, hence we'll need > mpkgs until someone writes the tool that allows one to double-click > on eggs to install them. I'm tempted to do so myself just to avoid > packaging stuff twice :-) > > Mpkgs have another advantage: they allow you to include documentation > and examples into the package. None of the existing packages on > pythonmac.org > (except for pyobjc and possibly py2app) actually use this possibility, > therefore I'd say this is not a very important advantage. Doesn't the wxPython package? Anyway, another advantage of eggs is that they can be versioned, so that users can have different versions of a package installed at once. Couldn't we put a *.egg into a *.mpkg? and get the best of both worlds? -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
[Pythonmac-SIG] Bulding numpy with the Universal Build
Hi all, I'm embarking on the project of building the various packages I need with the new Universal Build. I've set up a Wiki page to keep track of what I (and others) have done. Please take a look if you are interested, and add your own work. http://pythonmac.org/wiki/UniversalPackages -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
[Pythonmac-SIG] Wiki Formatting
Hi all, I've been working on a new Wiki page for info about packages on the new Universal build: http://pythonmac.org/wiki/UniversalPackages Something is up with the formatting: I have both: === A heading === = A less important heading = But they both look the same. Am I doing something wrong? -CHB -- 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] Wiki Formatting
Jordan Mantha wrote: > I think you want is: > > = A Heading = > > == A less important heading == Thanks. Did someone go fix that? > have had a lot of difficulties with the apps on > that wiki page (I a few data analysis scripts using SciPy). SciPy is a challenge! > I finally got Numpy > and Scipy (from SVN) installed using gfortran (gfortran-intel-bin.tar.gz > from http://hpc.sourceforge.net/) and the Universal MacPython 2.4.3c1 > build from Ronald Oussoren. I followed the directions at > http://www.scipy.org/Installing_SciPy/Mac_OS_X . I can update the wiki > page when I get a chance. Great, please do so. It does look like it's really going to be a trick to get a Universal build of SciPy but maybe separate Intel and PPC builds wouldn't be too bad. As soon as Bob gets bdist_mpkg working with the Universal build, we can start making packages for all to use. -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] Wiki Formatting
Ronald Oussoren wrote: > I'd prefer not to have seperate Intel and PPC binaries. Would merging > seperate > Intel and PPC builds be of any use? Yes, though I'm not sure what you mean by merging. Do you mean lipo'ing them together? or having separate builds in one *.mpkg? Ideally, we could get it all truly Universal, then one could build Universal Py2App bundles with it and all. I think the big trick with SciPy is the Fortran components. SciPy, Fortran and gcc 4 have been having trouble for a while. If that's fixed, I have no idea about how to build Universal binaries with gfortran or g95. Does anyone know? While I'm on the topic, I'm looking into building Universal binaries of some other packages that depend on other libs. For instance, matplotlib depends on libpng and libfreetype. In the past, I've built static libs of those, and then linked MPL against them, getting a nice self-contained package. However, I have no idea how I would go about building Universal static libs, or two sets of libs, or Any suggestions? -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
[Pythonmac-SIG] Has anyone built PIL with the Universal Python?
Hi all, I just sat down to build PIL for the Universal Python, and I had a thought: 1) it needs a couple extra libs, in particular: libjpeg libfreetype I have, in the past, compiled that kind of thing as a static lib, and linked it to the package. However, as we may end up needing the same libs in various packages, maybe we should make a "libs package", that might even install into the Python tree, and they can all use that. libfreetype is needed for both matplotlib and PIL, for instance. Thoughts? -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] wxPython universal (was Re: Wiki Formatting)
Kevin Ollivier wrote: > I've been able to build wxPython as Universal using the Universal Python > build from about a week ago, and it works on Tiger, but on Panther > certain things that are supposed to be initialized at load time aren't > being initialized. I, for one, think it would be a good start to get a Tiger only one out there. Did you need to do anything special to get that working? -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] future of python/w
Charles Hartman wrote: > Excellent news. I'll hope that, by the time these students get going When might that be? weeks? maybe not. Months? probably. Charles Hartman wrote: >>> I ask because I have to write a getting-started sheet for some >>> students taking up Python, on various platforms. I hope you'll put it on the wiki or somewhere for all to see. -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] PyXML install problems
Bob Ippolito wrote: > When using the universal build, you need to have the universal SDK > installed. It looks like you don't. Do you get that if you install the latest XCode tools? -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] PyXML install problems
Bill Janssen wrote: > Time to update the downloads page? I'm not sure. We don't have a single Universal package available yet. However, it does work, on PPC, with the packages for the 2.4.1 Framework build. If you use it on Intel, however, you're stuck with building everything yourself, and I don't know how universally that works. I'd be inclined to wait until we have a core of commonly used packages available. -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
