[Pythonmac-SIG] SetSystemUIMode in python?

[Bob Ippolito]

On May 27, 2005, at 7:22 PM, Kent Quirk wrote:

> Bob wrote:
>
>> * SWIG (ughh)
>> * Write C++ and use Boost.Python (ugh)
>> * Python C API directly (not really *that* bad)
>>
>
> Well, I've looked at all of these, and I've gotta disagree with the  
> Ugh
> on Boost.Python. At least for large projects. If (like me) you have
> large quantities of existing C++ to deal with, Boost.Python is  
> actually
> really nice.

Yes, of course, reusing existing code always wins, but in this case  
there is exactly 0 lines of existing C++ code.  Introducing C++ and  
Boost.Python to the equation sounds quite masochistic to me.

I'm not saying Boost.Python sucks, because it doesn't *if you have C+ 
+ code*.  It is a hammer best suited for nails manufactured in  
another universe.

> You can build Python classes that inherit from C++ classes, you can
> built C++ classes that inherit from Python classes. You can write free
> functions, you can construct enums, and you basically use it by  
> writing
> down some simple definitions. Your C++ code is idiomatic AND your  
> Python
> code is idiomatic.

PyObjC (with Objective-C) gives you this too, minus some of the  
idiomatic on the Python side -- but it requires no glue and happens  
at runtime, which is well worth the trade.

> Example: using Boost.Python, we constructed an Event (publish/ 
> subscribe)
> system that allows for arbitrary data to be passed as Python
> dictionaries. Events, queues and listeners can be constructed on  
> either
> side of the fence and interoperate cleanly. You can have an arbitrary
> number of event queues. It's a remarkably easy and clean way to pass
> messages around between a collection of otherwise-disconnected
> components, and lets us keep static coupling to a minimum.
>
> Boost.Python isn't for everyone, but in our system it was a lifesaver.

Except for the fact its build system is *crazy* and is causing you  
unnecessary headaches on the Mac...

Anyway, I was referring to the fact that Boost.Python would be  
introducing new C++ code where there was none before.  On top of  
that, you'd be adding glue code, another programming language,  
another compiler, a Python extension, and a funky ABI requirement to  
the mix.

Wrapping with Objective-C takes no more effort than C++ (probably  
less), doesn't introduce a new compiler, and doesn't even tie you to  
a particular version of Python (since you just pull in the class from  
your wrapper at runtime, and you have no Python extension module).   
Wrapping in Pyrex is even easier than Objective-C, except when  
dealing with CoreFoundation toll-free bridged types, but can be a  
PITA to debug since it's a pre-processor for C and it does give you a  
Python extension.

Not wrapping at all is best of course, which is why I suggested  
PyObjC's loadBundleFunctions or ctypes.

-bob