[Pythonmac-SIG] Living dangerously or not?

[Steven D. Majewski]

I suspect: 

 Most developers and serious Mac users are up to at least 8.0. 

 You haven't got most of the 8.5 calls wrapped yet, so 8.0 vs
   8.5 hasn't been an issue. 
 ( You need to have the Universal Interfaces 3.2 for your headers
   to have those calls, and I don't believe CW4 shipped with those --
   you have to download them from Apple. ) 

 Most Python users aren't attempting most of those feature yet. 
 ( I know I'm just trying to figure them out myself, and as I noted
   when I mentioned macintosh C v2.0 -- most of the mac programming
  books don't cover these features yet, so they are likely to be
  overlooked. )  


So I'm not sure we can count on luck lasting!

I tend to agree with Joe -- there is so much overhead in a Python 
function call, that a check for NULL in the C code would likely be
unnoticed. I would LIKE Python to be uncrashable -- as it is now,
you can certainly find ways of crashing it with the toolbox functions,
so it's not near ideal, but I'ld still like to minimize the dangerous
cases, if possible.

I already mentioned the alternative of having Win|Win2, Ctl|Ctl2 
modules -- the appropriate gestalts calls could be done on import
of the *2 modules. But that only handles a single split for 8.5 or
greater. 

  I suppose the other trick would be some sort of fixup done on 
either module init or during import. On module init (in C) it
would have to test a list of pairs of (C-entry-point-symbol,
Python-function) and revector the Python functions for which
C-entry-point is NULL to an error function. (In XlispStat, you
can unload as well as load dynamic libraries, and when you unload
a library, the symbols get mapped to a function that reports 
that the library is unloaded.) 
  It could also be done on import from Python with a wrapper --
sort of a specialized Bastion -- that would need a table of 
functions to export (or exclude) for a given set of Gestalt 
return values.  Is Gestalt callable from Python ?  I said before
I'ld like to avoid MacPython programmers having to worry about
it, but in this case, it would be low level and mostly invisible. 


The NULL test sounds easier, but it defers the error until you
try to call the function. Not finding the symbol might be better
and easier to test for. On the other hand, I don't think I'm 
going to be ambitious enough to try to write Python code for
all the options -- I'll be happy to say "Requires 8.5 of better"
if MacPython can give a reasonable indication that that's the 
problem. 


---|  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  |---

    Caldera Open Linux: "Powerful and easy to use!" -- Microsoft(*)
     (*) <http://www.pathfinder.com/fortune/1999/03/01/mic.html>