The resource file for Python on OSX should be reorganized. Some of the resources are only used by specific modules such as EasyDialogs, these should go into private resource files. Some are used by the interpreter itself (The "Estr" resource that maps error numbers to strings comes to mind). The most obvious place for these would be the resource file of the framework, but these may also be useful in non-framework builds (where you now get the uninformative 'MacOS.Error: Error -1234').

Logged In: YES 
user_id=92689

The Estr resource: is this resource generated, and if so
how? Would it be  an idea to generate a Python module instead?

The macresource module also has issues: eg. for EasyDialogs
it looks for "dialogs.rsrc" in
os.path.dirname(EasyDialogs.__file__), which doesn't work
when EasyDialogs is loaded from a zip file. If it would
(additionally) look on sys.path it could work for standalone
apps created by bundlebuilder: it should simply be included
in <appname>.app/Contents/Resources/ then.

Logged In: YES 
user_id=45365

Okay with me, as long as you look on sys.path *after* checking the __file__. So the order would be
1) Check wheter it happens to be available already
2) Check whether __file__ gives a clue
3) check sys.path

An alternative solution would be that bundlebuilder takes the .rsrc file for each module automatically and combines them all (including errors.rsrc)into the resource file that is automatically opened when the .app starts (I think it's <executablename>.rsrc, check the apple docs).

A Python module in stead of the Estr resource I'm not too thrilled about: there are a lot of error messages, and if it was a Python module then they would all be in-core once you import the module.

I'm assigning this over to you, close it when you're done (the rest of the reorganization is finished).

Logged In: YES 
user_id=92689

Ok, I checked in a change to macresource.py to this effect
(it simply adds sys.path to searchdirs, after
os.path.dirname(__file__).

Apart from Estr, how about trying to use nibs instead of res
files? I think this is meant to work for OS9 as well, but
would require interfacing some *FromNib API's in Carbon.Win
and Carbon.Dlg. Just a thought.

Either way, we should use a strict naming convention, eg.
EasyDialogs.py's resources should be in a file called
EasyDialogs.rsrc (and/or EasyDialogs.nib if we take the
above route).

Logged In: YES 
user_id=92689

Wait, there already is Carbon.IBCarbon, cool! Shall I try to
find out what it takes to convert EasyDialogs to use it?

Logged In: YES 
user_id=45365

Yes, if you want to put some effort into this: please do!

Logged In: YES 
user_id=92689

Ok, I've played around a bit and it's certainly doable: I
have a simple dialog running from a nib. It would still be a
fairly major rewrite of EasyDialogs as DialogRef's are not
supported in IBCarbon: must use straight windows.

One thing that's missing is the ability to load nibs from a
path, as opposed to finding them by name from an app bundle:
for this we need to create
Carbon.IBCarbon.CreateNibReferenceWithCFBundle(), and for
that to work we need CFBundle support in Carbon.CF.

Logged In: YES 
user_id=45365

Just, this error report has drifted quite a bit from the original intention: it was about splitting the .rsrc files into separate files living with the modules they belong to, but now it is about phasing out .rsrc files.

The former has been finished a while ago, how about closing this bug and opening a new one with a better title and description?

Logged In: YES 
user_id=92689

Sure. But I must warn you: my incentive to rewrite EasyDialogs using Carbon nibs has dropped to pretty much below zero...