[Pythonmac-SIG] emergency python recovery

[John Hunter]

I was in the process of getting ready for a talk this morning at 9AM,
one that was largely a demo of python for scientific computing, when I
inadvertently did

  > sudo rm -rf 
/System/Library/Frameworks/Python/.framework/Versions/2.3/lib/python2.3

Ouch!  I had meant to just remove site-packages/matplotlib for a clean
install, and just screwed up.

Is there an easy way to get this directory back -- eg an installer or
package?

If not, could someone just tar up that directory and share it with me?
I'm using OS X 10.3 on a 12 inch powerbook G4.

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

Re: [Pythonmac-SIG] emergency python recovery

[Kevin Dangoor]

Just an FYI to anyone else who sees this... I've tarred up the files for 
John.

Kevin
John Hunter wrote:
I was in the process of getting ready for a talk this morning at 9AM,
one that was largely a demo of python for scientific computing, when I
inadvertently did
 > sudo rm -rf 
/System/Library/Frameworks/Python/.framework/Versions/2.3/lib/python2.3
Ouch!  I had meant to just remove site-packages/matplotlib for a clean
install, and just screwed up.
Is there an easy way to get this directory back -- eg an installer or
package?
If not, could someone just tar up that directory and share it with me?
I'm using OS X 10.3 on a 12 inch powerbook G4.
Thanks!
JDH
___
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] emergency python recovery

[Bob Ippolito]

It's also possible to unpax them BSD(somethingoranother).pkg somewhere  
on one of the Panther install CDs.

-bob
On Mar 17, 2005, at 8:26, Kevin Dangoor wrote:
Just an FYI to anyone else who sees this... I've tarred up the files  
for John.

Kevin
John Hunter wrote:
I was in the process of getting ready for a talk this morning at 9AM,
one that was largely a demo of python for scientific computing, when I
inadvertently did
 > sudo rm -rf  
/System/Library/Frameworks/Python/.framework/Versions/2.3/lib/ 
python2.3

Ouch!  I had meant to just remove site-packages/matplotlib for a clean
install, and just screwed up.
Is there an easy way to get this directory back -- eg an installer or
package?
If not, could someone just tar up that directory and share it with me?
I'm using OS X 10.3 on a 12 inch powerbook G4.
Thanks!
JDH
___
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
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] py2app on Tiger

[Charles Hartman]

On Mar 16, 2005, at 9:39 PM, Bob Ippolito wrote:
You *may* need to compile the Python framework and all of the 
extensions that you use on Mac OS X 10.3 (Panther).  If you *do* 
compile them on Mac OS X 10.3, then they will surely work on Mac OS X 
10.3.  If you compile them on Mac OS X 10.4 (Tiger), they *might* work 
on Mac OS X 10.3.  It really depends on how they're written, what they 
link to, and how they link to it.  Testing is necessary.
Do I have this straight:
1. *Until* I upgrade to Tiger (proably a few months), I can keep 
working on 10.3, and what I build (using Apple-distributed framework 
2.3 and wxPython 2.5.3.x or 2.5.4.x when I upgrade that) will work on 
*both* 10.3 and 10.4?

2. Once I upgrade, I will need to keep a 10.3 partition around until I 
decide to stop supporting 10.3, if ever? Not a cheery prospect, but I 
want to make sure I at least understand what it is.

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

Re: [Pythonmac-SIG] py2app on Tiger

[Bob Ippolito]

On Mar 17, 2005, at 10:37, Charles Hartman wrote:
On Mar 16, 2005, at 9:39 PM, Bob Ippolito wrote:
You *may* need to compile the Python framework and all of the 
extensions that you use on Mac OS X 10.3 (Panther).  If you *do* 
compile them on Mac OS X 10.3, then they will surely work on Mac OS X 
10.3.  If you compile them on Mac OS X 10.4 (Tiger), they *might* 
work on Mac OS X 10.3.  It really depends on how they're written, 
what they link to, and how they link to it.  Testing is necessary.
Do I have this straight:
1. *Until* I upgrade to Tiger (proably a few months), I can keep 
working on 10.3, and what I build (using Apple-distributed framework 
2.3 and wxPython 2.5.3.x or 2.5.4.x when I upgrade that) will work on 
*both* 10.3 and 10.4?
I didn't say that.  I said it would work if you compiled a Python 
framework.  I said nothing of whether using the Apple-distributed 
framework would be compatible.  Applications using the stock Python 
2.3.x might (let's upgrade that to "will probably") work on both 10.3 
or 10.4, but there is no guarantee, and it's unlikely to work after 
that.

2. Once I upgrade, I will need to keep a 10.3 partition around until I 
decide to stop supporting 10.3, if ever? Not a cheery prospect, but I 
want to make sure I at least understand what it is.
Compiling extensions on 10.3 is the only way to guarantee they will 
work on 10.3.  Testing on 10.3 is the only way to know if your app 
works on 10.3.  The degree to which you need 10.3 depends on how often 
you need to compile extensions, and how actively you're going to 
support it by testing.

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

Re: [Pythonmac-SIG] py2app on Tiger

[Charles Hartman]

Thanks, that clarifies it. Since I'm not -- at least in my main current 
project -- compiling any extensions, just using off-the-shelf Python 
2.3 and wxPython, it sounds as though my life shouldn't get *too* much 
more compicated too soon. I'm pretty sure my fairly straightforward 
code isn't using anything in 2.3 that will turn out not to work in 2.4. 
(Famous last words?)

Probably like a lot of people, I don't care much about supporting 
versions of the OS that "nobody" (???) is using. Not only don't I have 
an OS9 version of my application, I don't worry about the absence of a 
10.2 version, because "people" -- which means everyone I know in the 
audience for my weird app -- will have upgraded to 10.3 by now. That 
implies that, from now on, I'll need to keep one (1) bootable partition 
around with the previous x in 10.x, but no more. I'm counting on the 
herd instinct, here.

Charles Hartman
On Mar 17, 2005, at 10:48 AM, Bob Ippolito wrote:
On Mar 17, 2005, at 10:37, Charles Hartman wrote:
On Mar 16, 2005, at 9:39 PM, Bob Ippolito wrote:
You *may* need to compile the Python framework and all of the 
extensions that you use on Mac OS X 10.3 (Panther).  If you *do* 
compile them on Mac OS X 10.3, then they will surely work on Mac OS 
X 10.3.  If you compile them on Mac OS X 10.4 (Tiger), they *might* 
work on Mac OS X 10.3.  It really depends on how they're written, 
what they link to, and how they link to it.  Testing is necessary.
Do I have this straight:
1. *Until* I upgrade to Tiger (proably a few months), I can keep 
working on 10.3, and what I build (using Apple-distributed framework 
2.3 and wxPython 2.5.3.x or 2.5.4.x when I upgrade that) will work on 
*both* 10.3 and 10.4?
I didn't say that.  I said it would work if you compiled a Python 
framework.  I said nothing of whether using the Apple-distributed 
framework would be compatible.  Applications using the stock Python 
2.3.x might (let's upgrade that to "will probably") work on both 10.3 
or 10.4, but there is no guarantee, and it's unlikely to work after 
that.

2. Once I upgrade, I will need to keep a 10.3 partition around until 
I decide to stop supporting 10.3, if ever? Not a cheery prospect, but 
I want to make sure I at least understand what it is.
Compiling extensions on 10.3 is the only way to guarantee they will 
work on 10.3.  Testing on 10.3 is the only way to know if your app 
works on 10.3.  The degree to which you need 10.3 depends on how often 
you need to compile extensions, and how actively you're going to 
support it by testing.

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

Re: [Pythonmac-SIG] py2app fails with 'optimize'

[Roger Binns]

Perhaps I should make the official installer install whatever is in SVN 
at the time instead of having a release tarball at all :)
Ximian used to start the install process for Gnome by doing something 
like:

 wget -dump http://./install.sh | sh
Note that I don't care how you do thinks behind the scenes only
that it is one step to install and one to uninstall and the likely
hood of hosing anything else is zero.
This is open source and the version number is way less than 1.0.
There isn't any harm in doing lots of little point releases, aka
release early and release often.
Sure there is, it takes up time better spent on other things.
It depends on whose time you want to spend.  There is your time
once, vs the time of all the individual people you asked to test
things.
Since the existing release already works for me (with my small
change to get optimize to work), there is little motivation
to test things under development that require more work to get
going and back out of.  The lack of a point release also makes
it harder to reproduce things on multiple machines.
Roger
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] "Launching" a file on a mounted server.

[Stephen Hansen]

Hello all :) I'm in the progress of porting our Python program over to
the Mac, and I've run into a snag or two.

We're running Python2.3 on MacOSX 10.3

I have two files:  /Volumes/server/file1.jpg
and: /Volumes/server/element/file2.jpg

If I do: fs1 = Carbon.File.FSRef('/Volumes/server/file1.jpg') 
and: fs2 = Carbon.File.FSRef('/Volumes/server/element/file2.jpg')

then if I use findertools.launch(fs1) it works, but
findertools.launch(fs2) does not. It throws the following traceback:

Traceback (most recent call last):
  File "/falcon/apt/system/editorial/library/ResourceGrid.py", line
162, in OnLeftDoubleClick
cb(self, row, rec, line)
  File "/falcon/apt/system/editorial/application/client/Client.py",
line 558, in OnQueue_DoubleClick
findertools.launch(Carbon.File.FSRef(path))
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/findertools.py",
line 45, in launch
return finder.open(fss)
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac/lib-scriptpackages/Finder/Standard_Suite.py",
line 250, in open
raise aetools.Error, aetools.decodeerror(_arguments)
aetools.Error: (-1, 'errAEEventFailed', None)


Now, i can browse into that directory (QA_Edit40->element) and run
that file fine, and if i copy that file onto the roof of the share (so
it becomes /Volumes/server/file2.jpg) it runs fine.. Just not in the
subdirectory...
-- 
Stephen Hansen
Development
Advanced Publishing Technology

[EMAIL PROTECTED]
(818) 557-3035 x330
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] "Launching" a file on a mounted server.

[Bob Ippolito]

On Mar 17, 2005, at 16:49, Stephen Hansen wrote:
Hello all :) I'm in the progress of porting our Python program over to
the Mac, and I've run into a snag or two.
We're running Python2.3 on MacOSX 10.3
I have two files:  /Volumes/server/file1.jpg
and: /Volumes/server/element/file2.jpg
If I do: fs1 = Carbon.File.FSRef('/Volumes/server/file1.jpg')
and: fs2 = Carbon.File.FSRef('/Volumes/server/element/file2.jpg')
then if I use findertools.launch(fs1) it works, but
findertools.launch(fs2) does not. It throws the following traceback:
I would suggest not using those functions at all.  Either use the 
LaunchServices module from Python23Compat (backported from Python 2.4), 
or use the NSWorkspace methods in PyObjC (easier).

The findertools stuff is *ancient* API.  God knows why it doesn't work, 
but I'm not surprised in the least.

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

[Pythonmac-SIG] ANN: py2app 0.1.8

[Bob Ippolito]

(see also: 
)

`py2app`_ is the bundlebuilder replacement we've all been waiting for.  
It is implemented as a distutils command, similar to `py2exe`_, that 
builds Mac OS X applications from Python scripts, extensions, and 
related data files.  It tries very hard to include all dependencies it 
can find so that your application can be distributed standalone, as Mac 
OS X applications should be.

`py2app`_ 0.1.8 will be included in the installer for `PyObjC`_ 1.3.  
If you have installed `PyObjC`_ 1.3, then you already have `py2app`_ 
0.1.8 installed.

Download and related links are here: http://undefined.org/python/#py2app
py2app 0.1.8 is a major enhancements release:
Bugs fixed:
- Symlinks in included frameworks should be preserved correctly
  (fixes Tcl/Tk)
- Fixes some minor issues with alias bundles
- Removed implicit SpiderImagePlugin -> ImageTk reference in PIL
  recipe
- The ``--optimize`` option should work now
- ``weakref`` is now included by default
- ``anydbm``'s dynamic dependencies are now in the standard implies
  list
- Errors on app launch are brought to the front so the user does
  not miss them
- bdist_mpkg now compatible with pychecker (data_files had issues)
Options changed:
- deprecated ``--strip``, it is now on by default
- new ``--no-strip`` option to turn off stripping of executables
New features:
- Looks for a hacked version of the PyOpenGL __init__.py so that
  it doesn't have to include the whole package in order to get
  at the stupid version file.
- New ``loader_files`` key that a recipe can return in order to
  ensure that non-code ends up in the .zip (the pygame recipe
  uses this)
- Now scans all files in the bundle and normalizes Mach-O load
  commands, not just extensions.  This helps out when using the
  ``--package`` option, when including frameworks that have plugins,
  etc.
- An embedded Python interpreter is now included in the executable
  bundle (``sys.executable`` points to it), this currently only
  works for framework builds of Python
- New ``macho_standalone`` tool
- New ``macho_find`` tool
- Major enhancements to the way plugins are built
- bdist_mpkg now has a ``--zipdist`` option to build zip files
  from the built package
- The bdist_mpkg "Installed to:" description is now based on the
  package install root, rather than the build root
.. _`py2app`:  http://undefined.org/python/#py2app
.. _`pyobjc`: http://pyobjc.sourceforge.net/
.. _`py2exe`: http://starship.python.net/crew/theller/py2exe/
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] ANN: PyObjC 1.3b1

[Bob Ippolito]

NOTE:
This is an announcement for a BETA release of `PyObjC`_.  Though we 
know it to be quite stable, and have been using it on a daily basis for 
quite some time, use it at your own risk.  1.3.0 will be out in a 
matter of days, but it is essential that we get some eyes on this!

.. _`PyObjC`: http://pyobjc.sourceforge.net/
Installer package available from:
http://pythonmac.org/packages/ (note that the installer also 
contains `py2app`_ 0.1.8)

.. _`py2app`: http://undefined.org/python/#py2app
Source:
http://svn.red-bean.com/pyobjc/tags/pyobjc-1.3b1/
Version 1.3 (2005-03-??)

- The bridge now maintains object identity across the bridge
  in both directions. Previous versions of the bridge only did this when
  bridging from Objective-C to Python.
  Exceptions: NSString and NSNumber do not have unique proxies. NSString
  never will have. Python numbers and strings are converted, not 
proxied and
  therefore also don't get unique proxies.

  And finally, any python object that is proxied using the 
``__pyobjc_object__``
  interface will only get a unique proxy if the ``__pyobjc_object__`` 
method
  implements that feature.

- New ``objc.protocolsForClass`` function that returns a list of 
protocols
  that the class directly claims to conform to.

- PyObjC classes can now declare that they implement formal protocols,
  for example::
class MyLockingClass(NSObject, objc.protocolNamed('NSLocking')):
# implementation
pass
  It is also possible to define new protocols::
 MyProtocol = objc.formal_protocol("MyProtocol", None, [
selector(None, selector='mymethod', signature='v@:'),
 ])
  All formal protocols are instances of ``objc.formal_protocol``.
- PyObjCTools.KeyValueCoding has a new ``kvc`` class that allows
  Pythonic Key-Value Coding.
  - ``__getitem__`` is mapped to ``valueForKeyPath:``
  - ``__setitem__`` is mapped to ``setValue:forKeyPath:``
  - ``__getattr__`` is mapped to ``valueForKey:``
  - ``__setattr__`` is mapped to ``setValue:forKey:``
  The ``kvc`` class uses ``__pyobjc_object__``, so it may cross the 
bridge
  as the wrapped object.

- ``NSNumber`` instances are bridged to a ``float``, ``long``, or 
``int``
  subclass that uses ``__pyobjc_object__``.
  ``NSDecimal`` is converted to ``NSDecimalNumber`` when used as an 
object,
  ``NSDecimalNumber`` is not bridged to ``NSDecimal`` because the 
latter is
  a mutable type.

- The Python to Objective-C bridge now looks for a ``__pyobjc_object__``
  attribute to get a PyObjC object from a Python object.
- New IDNSnitch example in Inject that demonstrates how to write an
  monitor for the launch of another application,
  use ``objc.inject`` to load code into a target process,
  and override the implementation of an existing method but still
  call back into the original implementation (method swizzling).
- ``objc.IMP`` should do the right thing now.  This type is returned
  by ``+[NSObject methodForSelector:]`` and
  ``+[NSObject instanceMethodForSelector:]``
- New ToDos example in CocoaBindings that demonstrates how to use
  two array controllers for the same data, and how to use value
  transformers to alter the color of text.  Originally from
  "Cocoa Bindings Examples and Hints", converted to PyObjC by u.fiedler.
- New Bookmarks example in CocoaBindings that demonstrates how to
  subclass ``NSArrayController`` to implement the ``NSTableView``
  delegate drag and drop protocol, including copying of objects between
  documents and accepting URL drops from other applications.  Also
  demonstrates re-ordering of the content array.  Originally from
  "Cocoa Bindings Examples and Hints", converted to PyObjC by u.fiedler.
- New FilteringController example in CocoaBindings that demonstrates
  how to subclass ``NSArrayController`` to implement filtering
  of a ``NSTableView``.  Also demonstrates the use of indexed accessors.
  Originally from "Cocoa Bindings Examples and Hints", converted to 
PyObjC
  by u.fiedler.

- New ControlledPreferences example in CocoaBindings that demonstrates
  how to use Cocoa Bindings to simplify storing and retrieving user
  preferences.  Originally from "Cocoa Bindings Examples and Hints",
  converted to PyObjC by u.fiedler.
- New TemperatureTransformer example in CocoaBindings that demonstrates
  how to use NSValueTransfomers with PyObjC.  Based on Apple's
  "Cocoa: Value Transformers" documentation, converted to PyObjC
  by u.fiedler.
- New CurrencyConvBindings example in CocoaBindings that demonstrates
  a Cocoa Bindings enabled version of the CurrencyConverter example.
  Converted to PyObjC by u.fiedler from the example in Apple's
  "Introduction to Developing Cocoa Applications Using Bindings".
- New ManualBindings example in CocoaBindings that demonstrates how
  to develop programmatic bindings from a PyObjC application.
  Converted to PyObjC by u.fiedler from the "Cocoa Bindings and Hints"
  example of the same name.
- New HotKeyPython example in Ap