[PYTHONMAC-SIG] Re: Python and Super/hypercard

[Steven D. Majewski]

On Wed, 20 Nov 1996, John Dunning wrote:
 
> Why are code resources too cramped?  Are code fragments or shared libraries
> better?

Yes. Code resources ( well -- on 68K almost all code is in a
code-resource, but typically, when you're talking about code resources,
you mean independent little pieces of code that may be system-y things
like window or control definitions, or may be application type things 
like plug-in's ( like NIH-Image or Photoshop uses ), but which both 
have quite a few restrictions about what you can and cannot do ( or 
some special tricks like creating A5 worlds, etc. to get things to work. ) 

The code fragment manager gets rid of some of these problems. 
You can do shared libraries with CFM. 
 ASLM - Apple Shared Library Manager is still kicking around and is still
used by some software, but it's been declared obsolete technology -- the
official word from Apple is use CFM or SOM if you want it to work
sometime in the future. There is a "Shared Library Statement of
Directions" or some such title document on Apple's developer web site. 
 IBM's System Object Model has been ported to the Mac and is built on top
of CFM. 
 DLLs and shared libraries work fine for procedural code, but they started
to fall apart when C++ and objects were added. There was no standard way
to store objects -- even among different C++ compilers, let alone cross
language. Thus came COM, SOM and ILU -- trying to solve that problems in
somewhat different ways. ( All the distributed object stuff came later,
but they all started off trying to be dynamic, cross-language object 
libraries. COM is a bit more limited, being mostly a standardization of
C++ object layout, and without inheritence -- typically, you have to 
write some wrapper code to integrate COM objects fully into another 
languages object hierarchy. Not too disimilar to how you have to write
a wrapper around Python's built-in list types so you can then write an
extended list class -- you can't directly inherit the list implementation.) 

> I'm interested in putting the Python interpreter into a shared library that
> will then be loaded as a component into another application.  Is this
> possible?  Has anyone had experience embedding Python into a Mac app?  I've
> read the chapter in Internet Programming with Python about embedding Python
> into the Netscape server, but I would expect there to be many Mac-specific
> pitfalls.
> 

 The core of Python is already in a shared library ( at least on the PPC
Macs and the 69K machines with CFM68K support. ) Did you copy a
Python-CORE extension file into your system extension folder when you
installed it ? That's the shared library.  Many of the toolbox modules,
and a few others are also shared libraries. ( "What exactly is where" is
largely what I meant when I said I needed to catch up with what Jack has
done to MacPython in the last couple of releases! The other bit is what
you ask -- how exactly to embed it and what missing pieces you need to 
supply, etc. ) If you do the embedding in the normal, portable way, I 
don't think you will run into much Mac-specific pitfalls. ( I may be 
wrong -- I haven't tried it yet, and 'not much' includes the typical
Mac-isms that we all complain about! ;-) 

 Re: my references to OSA support: 
 There is also some support of AppleEvents in Python, so you can write
Python code that scripts other OSA scriptable applications, or send
MacPython AppleEvents from another app. Full OSA support basically means
turning Python into a Scripting Component -- which DEFINITELY includes
dealing with a whole n'other layer of Mac-isms -- but which possibly
gets you most of the way to where you first said you wanted to be: 
to make Python an alternate scripting language for Hypercard. 
[ This is also documentation I'm still digesting in between more urgent
 projects, so I could have some fatal misconceptions somewhere here. ] 
This would be embedding it "the Mac Way".  

 Adding SOM support to Python could go in two directions: 
 
 [1] Python objects CAN be in DLL's because Python is written in C, not
  C++, and it provides its own runtime protocol for registering objects
  and their method tables -- you don't even need a very sophisticated 
  DLL ( at least for the MODULE end ), because you only need a single 
  entry point to the module/object initialization routine. 
  You could give Python the ability to import directly from SOM libraries
  -- basically write one module that translates from SOMs object protocol
  to Python's protocol, so you can import any SOM library without having
  to make a separate wrapper. With C++ compilers on the Mac now supporting
  Direct-to-SOM, this could be a big plus on the Mac. ( Same caveat
  applies here -- if I absolutely knew what I was talking about, I would
  have DONE it by now! ) 

 [2] You could also wrap Python and it's object system up into SOM. 
  I haven't the *SLIGHTEST* idea how to do this one, or exactly what it 
  gets you that you don't already get by embedding Python the usual way
  and using the new Abstract Object Interface from C code. I just have
  a inherent desire for symmetry.  


---|  Steven D. Majewski   (804-982-0831)  <sdm7g@Virginia.EDU>  |---
---|  Department of Molecular Physiology and Biological Physics  |---
---|  University of Virginia             Health Sciences Center  |---
---|  P.O. Box 10011            Charlottesville, VA  22906-0011  |---
         By doing just a little every day, you can gradually 
                let the task completely overwhelm you.


=================
PYTHONMAC-SIG  - SIG on Python for the Apple Macintosh

send messages to: pythonmac-sig@python.org
administrivia to: pythonmac-sig-request@python.org
=================