Re: [Pythonmac-SIG] Zope py2app, some progress

[Roger Binns]

You're probably not setting the right plist keys or something for 
Apple's help.
The documentation doesn't make it clear what should be set.
Additionally I have no idea how to make them from Python so
I can automate all this.
Python does it, see:
python/dist/src/Mac/OSX/Doc
There is a heroic amount of code there, a lot of it because Apple 
pathologically want you to run the help indexer by dragging and
dropping and not in any automated manner.

Anyway I wasted yet another hour following what that does
and it still doesn't work without any indication why.  I really
don't care any more.  If anyone wants BitPim to use the
Apple help mechanisms, then they can spend hours of their
time working it out and contributing whatever needs to be
done.  The way Apple does it also makes it impossible to
use the help while doing development since a bundle doesn't
exist at that point.
Roger
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Zope py2app, some progress

[Roger Binns]

You don't need to touch Objective-C at all!  IOKit is plain old C.
All the example code is in Objective C.  Quite simply there is
far too steep a learning curve to get through these layers be
it Objective C or pseudo objects in C plus mapping into Python
land.
It really is orders of magnitude easier working with win32all
on Windows than trying to do the equivalent stuff on Mac.  Linux
doesn't even enter since there is no way of doing things like
help or some of the device stuff.
There is a USB Prober under /Developer/Applications/Utilities
(BTW I have found everything you mentioned under a different path
than you said so I don't know if you were typing them from memory
or have a different dev kit).
Probably because it was from memory, or maybe because I might have the 
FireWire SDK installed?  I don't know.  
I had all the tools and examples you mentioned and I just have the
standard reinstall that came with the Mac mini.
I couldn't get the USB Prober to see libusb traffic so it may
require the device drivers to cooperate.  It looks like it installs
an alternative driver for the controller.
Roger
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Main Python on Mac version?

[Roger Binns]

Apple's upgrade policy seems to be one of urgency rather than  
convenience.  If there were gnarly security issues in Python, I'm sure  
we'd have seen an upgrade.  There's an upgrade around the corner called  
Tiger (10.4), which will ship with a more recent version of Python.   
Which version this is, I can't say, but the public WWDC 2004 sources  
had 2.3.3 if I'm not mistaken.
The issue is that I am not doing stuff for just myself.  Any other
Mac BitPim developers have to use the same version of Python and
the same extensions.  I also try as much as possible to use
binary installations that are in as wide a usage as possible.
That helps ensure that any bugs are found. 

Anything you build yourself or is used by a small number of people
can have issues.  For example when I built wxPython on a Redhat
box it used SDL because it happened to be installed.  When I then
redistributed BitPim binaries, things failed to run on some
people's machines.
There are some bugfixes that would be nice, but it's dangerous to do  
that because you end up with some people that have a fast datetime  
module and some people with a slow datetime module, or some people with  
a plistlib that works with dates, and other people without.
That is why I stay "mainstream".  The problem now is that BitPim
on Mac is using 2.3.0, yet 2.3.4 on Windows and Linux.  I presume
the various bug fixes in 2.3.[1-5] were serious enough to warrant
new releases, otherwise why did they bother making them.
If you want an application that is 10.2 compatible, 
The way I deal with OS version compatibility is to just build on 
whatever the version is.  I never try and build on a newer version
and hope it will work on older versions.  That mythical virtualisation
software would be very handy for this.

There's a good chance system-python-dependent applications built on 10.3 will  
work on 10.4, but there's probably not a good chance that such  
applications will work on later versions of Mac OS X (if, for example,  
Python 2.4 becomes the default and 2.3 goes away).
And that is how we end up building for different MacOS versions.
When we switch to Python 2.4, it will be required for all supported
operating systems and their versions.  Presumably we'll still be
supporting 10.3 then so I'll have to figure out how to deal with
that.
Roger
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Discovering file type

[Enrico Franchi]

On 10/feb/05, at 15:54, Ramm, Henning wrote:
Don't think so, I looked for something similar myself and ended adding 
Type and Creator to every file that I recognize.
Because I couldn't find a free extensive list of Type and Creator 
codes, I collected my own. Perhaps they are of use for anyone:
Well, it is (almost) what I was looking for, even if it is not included 
in system.
I just found out that LaunchServices solve another of my problems, but 
not this one.
Probably I have to give'em a closer look, maybe searching more 
approfonditely ACDC...

-enrico
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] pythonw, site-packages, .pth problem

[Torsten Sadowski]

Hi,

I ran into a namespace conflict between wx2.5.3 and vtk4.4 on Panther
with the Macpython additions.
Analyzing the problem I stumbled across a strange behaviour. It seems that
*.pth files are simply ignored. If that is so, where does pythonw keep its
pathes as I did not set a PYTHONPATH?

Torsten
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] pythonw, site-packages, .pth problem

[Torsten Sadowski]

Sorry, the.pth files are evaluated. I was simply too stupid to copy the
vtk stuff to the right place.

Torsten

On Fri, 11 Feb 2005, Torsten Sadowski wrote:

> Hi,
>
> I ran into a namespace conflict between wx2.5.3 and vtk4.4 on Panther
> with the Macpython additions.
> Analyzing the problem I stumbled across a strange behaviour. It seems that
> *.pth files are simply ignored. If that is so, where does pythonw keep its
> pathes as I did not set a PYTHONPATH?
>
> Torsten
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>
>
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Zope py2app, some progress

[Bob Ippolito]

On Feb 11, 2005, at 3:15, Roger Binns wrote:
You don't need to touch Objective-C at all!  IOKit is plain old C.
All the example code is in Objective C.  Quite simply there is
far too steep a learning curve to get through these layers be
it Objective C or pseudo objects in C plus mapping into Python
land.
Uh, no it isn't.  A fair share of the IOKit examples are pure C or C++.
It really is orders of magnitude easier working with win32all
on Windows than trying to do the equivalent stuff on Mac.  Linux
doesn't even enter since there is no way of doing things like
help or some of the device stuff.
Yes, the help stuff is a pain in the ass, querying IOKit really isn't.
-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Main Python on Mac version?

[Bob Ippolito]

On Feb 11, 2005, at 3:25, Roger Binns wrote:
There are some bugfixes that would be nice, but it's dangerous to do  
that because you end up with some people that have a fast datetime  
module and some people with a slow datetime module, or some people 
with  a plistlib that works with dates, and other people without.
That is why I stay "mainstream".  The problem now is that BitPim
on Mac is using 2.3.0, yet 2.3.4 on Windows and Linux.  I presume
the various bug fixes in 2.3.[1-5] were serious enough to warrant
new releases, otherwise why did they bother making them.
The standard library is large, it's entirely possible that five bugfix 
releases go by and don't touch anything you use.

If you want to build with a newer version of Python, go ahead, there's 
nothing stopping you and py2app will do the right thing.  Simply invoke 
setup.py with the python you want included in the application bundle.  
The system Python is a special case in that it *refuses* to copy it 
into the bundle for various reasons.

If you want an application that is 10.2 compatible,
The way I deal with OS version compatibility is to just build on 
whatever the version is.  I never try and build on a newer version
and hope it will work on older versions.  That mythical virtualisation
software would be very handy for this.

There's a good chance system-python-dependent applications built on 
10.3 will  work on 10.4, but there's probably not a good chance that 
such  applications will work on later versions of Mac OS X (if, for 
example,  Python 2.4 becomes the default and 2.3 goes away).
And that is how we end up building for different MacOS versions.
When we switch to Python 2.4, it will be required for all supported
operating systems and their versions.  Presumably we'll still be
supporting 10.3 then so I'll have to figure out how to deal with
that.
But my point was that you only need to build on the lowest common 
denominator and it will work everywhere else.

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Main Python on Mac version?

[Roger Binns]

The standard library is large, it's entirely possible that five bugfix 
releases go by and don't touch anything you use.
I think some of the weakref bugfixes (ie in the C core) may be relevant
although it I may also have accidentally the usage in such a way that
it works around the problems.
If you want to build with a newer version of Python, go ahead, there's 
nothing stopping you and py2app will do the right thing.  Simply invoke 
setup.py with the python you want included in the application bundle.  
The system Python is a special case in that it *refuses* to copy it 
into the bundle for various reasons.
On Linux the pydotorg Python does install into a different directory
structure and all works fine (the base Python on Redhat 9 is 2.2).
I'm sure py2app works fine, but it is trivial compared to my other
dependencies, especially wxPython.  The wxPython page says:
  wxPythonOSX needs a "Framework" build of Python 2.3, also known 
  as MacPython-OSX. If you have OSX 10.3 (Panther) then you already 
  have what you need ...

But my point was that you only need to build on the lowest common 
denominator and it will work everywhere else.
No, your point was that it *should* work everywhere else.  A failure
to work everywhere else has already happened to us once and who knows
what will actually happen when Tiger comes out.  (I am definitely 
intending to drop 10.2 support at that point).

Roger
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Main Python on Mac version?

[Bob Ippolito]

On Feb 11, 2005, at 11:59 AM, Roger Binns wrote:
The standard library is large, it's entirely possible that five 
bugfix releases go by and don't touch anything you use.
I think some of the weakref bugfixes (ie in the C core) may be relevant
although it I may also have accidentally the usage in such a way that
it works around the problems.
To my knowledge, the weakref stuff fixes some edge cases that you 
probably don't have.  Those bugs have been in weakref for a long time.

If you want to build with a newer version of Python, go ahead, 
there's nothing stopping you and py2app will do the right thing.  
Simply invoke setup.py with the python you want included in the 
application bundle.  The system Python is a special case in that it 
*refuses* to copy it into the bundle for various reasons.
On Linux the pydotorg Python does install into a different directory
structure and all works fine (the base Python on Redhat 9 is 2.2).
I'm sure py2app works fine, but it is trivial compared to my other
dependencies, especially wxPython.  The wxPython page says:
  wxPythonOSX needs a "Framework" build of Python 2.3, also known   as 
MacPython-OSX. If you have OSX 10.3 (Panther) then you already   have 
what you need ...
Yeah, if you want to use a non-system Python with an extension built 
with the system Python there are some potential issues.  Specifically, 
if the extensions were built without PantherPythonFix, then they will 
crash on import unless they have been run through py2app (but not with 
the alias bundle option, it does not touch extensions).  Otherwise, if 
they were built with the fix, then they do not directly reference any 
Python so it is simply ok to just copy them somewhere on the sys.path 
of your non-system Python.

I could write a script (similar to macho_standalone) that sanitizes 
Python extensions so that they may be used with a different Python of 
the same major version, but except for 10.2, the real solution is just 
to use PantherPythonFix and recompile (relink really).

But my point was that you only need to build on the lowest common 
denominator and it will work everywhere else.
No, your point was that it *should* work everywhere else.  A failure
to work everywhere else has already happened to us once and who knows
what will actually happen when Tiger comes out.  (I am definitely 
intending to drop 10.2 support at that point).
This failure was probably due to the fact that you were not using 
py2app at the time.  I bet it was a Version Mismatch issue because the 
extensions that went into the bundle directly referenced 
/Library/Frameworks/Python.framework and the user had a Python 
installed there.  The application would then have two Python 
interpreters in-process and when that happens it goes BOOM.

If you are embedding a non-system Python with py2app, then you will not 
have this issue.

(dropping 10.2 support is going to be a dream come true).
-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Zope py2app, some progress

[Roger Binns]

All the example code is in Objective C.  Quite simply there is
far too steep a learning curve to get through these layers be
it Objective C or pseudo objects in C plus mapping into Python
land.
Uh, no it isn't.  A fair share of the IOKit examples are pure C or C++.
Ok, more accurately the examples that were looking at hierarchies
are in Objective C.  And I'm sure that working with IOKit, in C or 
Objective C, once you have done it a few times is quick and easy.  
If you haven't then a time investment is needed to understand the docs, 
the examples, the types, actually write code that works, map it into 
Python etc.

Roger
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Main Python on Mac version?

[Roger Binns]

To my knowledge, the weakref stuff fixes some edge cases that you 
probably don't have.  Those bugs have been in weakref for a long time.
BitPim also isn't a long running process so leaks wouldn't be that
big a deal.
Yeah, if you want to use a non-system Python with an extension built 
with the system Python there are some potential issues. 
Is there a page somewhere that actually explains what all this
terminology is about (eg Framework, alias bundles and similar).
I am used to the Python files and libraries just existing in a
conventional filesystem.  Nothing complicated.  All very trivial.
Multiple versions can be installed.  A simple --prefix can move
where it is in ./configure.  Each one is an island with no possibility
of sharing extensions or modifications between them.  (That is a very
good thing - keeps it simple.)  wxPython does have some dynamic
linking issues on Unix (it hard codes the path to the wxWidgets
directory at the ELF level, but chrpath fixes that.)
This failure was probably due to the fact that you were not using 
py2app at the time.  
We used to use bundlebuilder.  So it sounds like there is 99.999% chance
we won't have to do seperate 10.4 builds.  Unless we do things like
hook into SpotLight  
Roger
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Louis Pecora]

Brendan Simons wrote:
The IDE thread is a recurring one.  Here's my experience as another 
Python newbie.  I tried SPE, PythonCard, PyOxice, PyPE, eclipse and 
wing (under x11).  All work, but I found that each one had enough 
quirks (mostly UI inconsistencies, but some are downright unstable)  
that I was less productive than without.   Not to sell any short, I'm 
sure they will get better given time.

FWIW, the winning formula for me right now is:
1) Editor:  TextWrangler (http://www.barebones.com/index.shtml).
 -Free, "Made For Mac", Code Colouring,  Method Indexing, The ability 
to run scripts from the editor, More text manipulation options than I 
can count.

2) GuiEditor:  XRCed.py (comes with the wxPython install package).  
(Or code the wxPython by hand, which takes longer, but gives you a 
little more control over the result).

3) And an instance of terminal running python interactive mode.  
Actually, this is the most valuable Python tool I've found so far - 
it's like a scratch pad where I can quickly check assumptions, or test 
out ideas.

The only thing I'm missing now is a debugger with breakpoints, call 
stack, and variable watches.  I'll have to settle for random print 
statements for now.

-Brendan 

You didn't mention the regular Mac Python IDE (maybe you did and I don't 
know it by the names you used).  But it is pretty nice (no syntax 
coloring is the most negative) on the other hand it has a debugger 
that's very nice and easy to use. 

But does it work with wxPython?  I know some things (Tkinter, I think) 
doesn't play nice with MacPython. 

I really like the ability to edit and just hit cmd-R to run the script. 

The IDE could use some updating and wart removal.  Syntax coloring, 
better scrolling (that's damaged right now), use of scroll wheel (if 
present), a few other interface changes.

In the end it's my tool.  

I don't really understand how your are doing the development.  You have 
to jump to a term window to run the script?

--
Cheers,
Lou Pecora
Code 6362
Naval Research Lab
Washington, DC  20375
USA
Ph:  +202-767-6002
email:  [EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Roger Binns]

I don't really understand how your are doing the development.  You have 
to jump to a term window to run the script?
I use xemacs as my editor.  The main functionality used is the syntax
colouring.  It also has a menu bar plugin (IM-Python) that lists the
classes and methods in the current file and lets you jump to them.
And a seperate terminal window to run things in.  I use this same
setup on Windows, Linux and Mac.  For a debugger I just place this
wherever I need to have a deeper look at what is going on:
 import pdb ; pdb.set_trace()
My wxPython code is hand coded.  I haven't found any of the design
tools to be much good for non-trivial projects.  For example try
doing something like the wxPython demo with one of them.  They
also don't work well if you have custom widgets, which is a lot 
of my UI.

The single biggest factor for productivity I have found is how
much screen space you have, preferably across two (or more) 
monitors.  The more you can see and the more context you can have
at once, the quicker you work and the less errors you make.  It 
is really nice to have one place where you are writing code, one
where you are looking at what you are calling, one for documentation
and one for where the output of your program is.  (I guess that is
4 monitors :-)

Roger
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Main Python on Mac version?

[Bob Ippolito]

On Feb 11, 2005, at 12:34, Roger Binns wrote:
Yeah, if you want to use a non-system Python with an extension built 
with the system Python there are some potential issues.
Is there a page somewhere that actually explains what all this
terminology is about (eg Framework, alias bundles and similar).
Framework, Application Bundle, etc. is all described at 
developer.apple.com.  Alias bundle is py2app terminology, the only 
documentation I've written for it beyond what made it to this list and 
what's in --help is in the PyObjC tutorial: 
http://pyobjc.sourceforge.net/doc/tutorial.php

Basically, an alias bundle is for development only, and is roughly 
similar in purpose to Xcode's ZeroLink feature.  Instead of scanning 
your applications for dependencies, rewriting Mach-O headers, etc. it 
rigs an application bundle such that it runs directly out of your 
source directory and your development environment, making symlinks and 
aliases where necessary, so you can have a really quick edit/run cycle. 
 You only have to build the alias bundle once, unless you add 
additional data files that need to be symlinked into the bundle.

I am used to the Python files and libraries just existing in a
conventional filesystem.  Nothing complicated.  All very trivial.
Multiple versions can be installed.  A simple --prefix can move
where it is in ./configure.  Each one is an island with no possibility
of sharing extensions or modifications between them.  (That is a very
good thing - keeps it simple.)  wxPython does have some dynamic
linking issues on Unix (it hard codes the path to the wxWidgets
directory at the ELF level, but chrpath fixes that.)
Frameworks and application bundles are an extension to this concept.
py2app operates at the Mach-O level (roughly equivalent to ELF) and 
automatically locates all link-time dependencies and does the 
equivalent of chrpath so that they work in the application bundle.

This failure was probably due to the fact that you were not using 
py2app at the time.
We used to use bundlebuilder.  So it sounds like there is 99.999% 
chance
we won't have to do seperate 10.4 builds.  Unless we do things like
hook into SpotLight  
It's totally possible to build your software such that it detects the 
version of Mac OS X at runtime and enables/disables functionality.  
This is common practice.  If you are using a Mac OS X 10.2 compiled 
version of PyObjC and you run it on Mac OS X 10.3, you will simply see 
more classes and new functionality on existing classes.  The correct 
way to determine if the functionality exists is to simply see if the 
class is there or the class responds to new methods.

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Bob Ippolito]

On Feb 11, 2005, at 12:51, Roger Binns wrote:
I don't really understand how your are doing the development.  You 
have to jump to a term window to run the script?
I use xemacs as my editor.  The main functionality used is the syntax
colouring.  It also has a menu bar plugin (IM-Python) that lists the
classes and methods in the current file and lets you jump to them.
And a seperate terminal window to run things in.  I use this same
setup on Windows, Linux and Mac.  For a debugger I just place this
wherever I need to have a deeper look at what is going on:
 import pdb ; pdb.set_trace()
Use this instead:
  import pdb; pdb.Pdb().set_trace()
It is more convenient in that you end up at the stack level you 
actually want to be at, rather than inside py2app.

The single biggest factor for productivity I have found is how
much screen space you have, preferably across two (or more) monitors.  
The more you can see and the more context you can have
at once, the quicker you work and the less errors you make.  It is 
really nice to have one place where you are writing code, one
where you are looking at what you are calling, one for documentation
and one for where the output of your program is.  (I guess that is
4 monitors :-)
Yeah, I use two 1600x1024 LCDs most of the time.  I can also be pretty 
productive on my 15" laptop, where I just use 80 char wide terminal 
windows.  I have been playing around with Desktop Manager 
 (GPL) on the laptop in order to 
keep coding on one desktop and email/etc. on another.  It seems to work 
pretty well, but I haven't used it enough to "get the hang of it" yet.

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Bob Ippolito]

On Feb 11, 2005, at 12:36, Louis Pecora wrote:
Brendan Simons wrote:
The IDE thread is a recurring one.  Here's my experience as another 
Python newbie.  I tried SPE, PythonCard, PyOxice, PyPE, eclipse and 
wing (under x11).  All work, but I found that each one had enough 
quirks (mostly UI inconsistencies, but some are downright unstable)  
that I was less productive than without.   Not to sell any short, I'm 
sure they will get better given time.

FWIW, the winning formula for me right now is:
1) Editor:  TextWrangler (http://www.barebones.com/index.shtml).
 -Free, "Made For Mac", Code Colouring,  Method Indexing, The ability 
to run scripts from the editor, More text manipulation options than I 
can count.

2) GuiEditor:  XRCed.py (comes with the wxPython install package).  
(Or code the wxPython by hand, which takes longer, but gives you a 
little more control over the result).

3) And an instance of terminal running python interactive mode.  
Actually, this is the most valuable Python tool I've found so far - 
it's like a scratch pad where I can quickly check assumptions, or 
test out ideas.

The only thing I'm missing now is a debugger with breakpoints, call 
stack, and variable watches.  I'll have to settle for random print 
statements for now.

You didn't mention the regular Mac Python IDE (maybe you did and I 
don't know it by the names you used).  But it is pretty nice (no 
syntax coloring is the most negative) on the other hand it has a 
debugger that's very nice and easy to use.
But does it work with wxPython?  I know some things (Tkinter, I think) 
doesn't play nice with MacPython.
The MacPython IDE runs all Python interpreters in-process and therefore 
can't run *any* GUI scripts/applications correctly using that feature.

I really like the ability to edit and just hit cmd-R to run the script.
The IDE could use some updating and wart removal.  Syntax coloring, 
better scrolling (that's damaged right now), use of scroll wheel (if 
present), a few other interface changes.

In the end it's my tool.
I don't really understand how your are doing the development.  You 
have to jump to a term window to run the script?
The source code for the old MacPython IDE is extremely ancient and 
nobody has expressed interest in updating it...

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac User Python Newbies

[Bob Ippolito]

On Feb 11, 2005, at 14:29, Bob Ippolito wrote:
On Feb 11, 2005, at 12:51, Roger Binns wrote:
I don't really understand how your are doing the development.  You 
have to jump to a term window to run the script?
I use xemacs as my editor.  The main functionality used is the syntax
colouring.  It also has a menu bar plugin (IM-Python) that lists the
classes and methods in the current file and lets you jump to them.
And a seperate terminal window to run things in.  I use this same
setup on Windows, Linux and Mac.  For a debugger I just place this
wherever I need to have a deeper look at what is going on:
 import pdb ; pdb.set_trace()
Use this instead:
  import pdb; pdb.Pdb().set_trace()
It is more convenient in that you end up at the stack level you 
actually want to be at, rather than inside py2app.
Er.. rather than inside pdb.. ugh.
-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] MacPython 2.3.5 for OS9 Release Candidate available

[Jack Jansen]

Hot on the heels of 2.3.5 for 10.2 another installer is available for 
testing: MacPython 2.3.5 for MacOS9. Again, download it via 


As it is likely that this is the very last release of Python for 
classic MacOS, marking the end of Python on the platform on which it 
was originally implemented initially many years ago, I suggest that if 
you think you may ever again need Python on MacOS9 (or Python in the 
Classic environment on MacOSX) you want to give this installer a quick 
test.

Also, there is some time pressure on getting the MacOS9 release right: 
the license for Installer Vise will expire within a month, and it would 
be silly to shell out another $1000 for another year.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig