[Pythonmac-SIG] error trying to run c extension from carbon P ython

Jack Jansen Jack.Jansen@cwi.nl
Fri, 21 Jun 2002 11:22:46 +0200


On Friday, June 21, 2002, at 03:24 , Magladry, Stephen wrote:

> Thanks for getting me straighten out. I am able to get my sample c 
> library,
> named cheese, executing in the release build. I need to be able to 
> build a
> slightly stripped down version of Python, though. So I grabbed the 
> source
> archive from the Mac Python Site. I started with the 
> PythonStandalone.mcp
> and made the following changes;

Ok, now I see what you're doing. It is possible to build applications 
this way (the
Mac version fo our GRiNS product is done like this), but there are some 
gotchas.

One important one is that you cannot load dynamic modules into a static 
Python.
What happened when you tried this (the "not initialized" error) is that 
you were
actually having *two* Python interpreters in core: the original 
PythonStandalone-based
one, which was initialized, and then your extension module pulled in 
PythonCoreCarbon,
which contained a fresh new interpreter. If you want to go with 
PythonStandalone
you must disable all the dynamic module loading features, as they will 
lead to the disaster
skewtched above, and include all modules you need statically. Add your 
sourcefiles to your
project, put the init routine for your module into macconfig.c and off 
you go.

The other errors you get (about codecs and such) probably all have to do 
with sys.path not being initialized correctly. This is a procedure of a 
couple of steps, especially so you can make things like what you want to 
do work out, but it is a bit convoluted.

1. Get the 'STR ' resource named "PythonPreferencesFileName" (from the 
application, in your case).
2. If this is a non-empty string it contains the filename of the 
preferences file (in System Folder:Preferences). This preferences file 
is opened and put in the resource search list. The steps below will all 
first look in the preferences file for a resource, and if none is found 
there they will look in the application.
3. If it is an empty string this signifies there's no preferences file, 
and all the steps below will only look in the application for 
preferences.
4. Look for all the preferences ('STR#' 228 and 229 for sys.path, 'alis' 
228 and 229 for the Python home folder sys.prefix, 'Popt' 228 and 229 
for the startup options. 'GU<sigma>I' 10240 and 10241 for the GUSI 
options). For each of these we first look for the 229 resource, which is 
the "override". If this isn't found we look for the 228 resource (the 
default).

See macgetpath.c and pythonpath.r for the gory details. To see just the 
end result (i.e. find out what went wrong) option-start your Python, 
select the "verbose import" and "also failures" options and let Python 
run. This will tell you where Python is looking for modules. Also, when 
you have the prompt, print sys.prefix and sys.path. The values here will 
probably tell you what went wrong.

If you want to completely insulate your program from an existing Python 
installation (what I needed to do for GRiNS) there's a few more tricks 
you need. Let me know if you need this and I'll try to remember.
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -