[Pythonmac-SIG] Python 2.3+Py23Compat/Python 2.4 compatibility problem

[Bob Ippolito]

On May 4, 2005, at 6:13 PM, has wrote:

> Bob wrote:
>
>
>>> I figured that, but I'd rather hoped a more elegant solution  
>>> might be forthcoming at source. Is there a good reason why they  
>>> couldn't both agree on a common location, or at least provide the  
>>> relevant aliases in 2.4 to preserve Python's much-vaunted  
>>> backwards compatibility?
>>>
>>
>> This is *FORWARDS* compatibility, not backwards.  Forwards  
>> compatibility is always messy.
>
> Touché. ;)
>
>> 1) Work around it
>>
>
> On my todo list. (Requiring 2.4 isn't an option as casual Python  
> users are more likely to be using the stock 2.3.5 and won't want to  
> upgrade just on my account.)
>
> Still, can't blame my hoping there might've been a better  
> solution... language warts are always unhappy things, Python warts  
> doubly so. Pity Apple decided to stuff Python.framework into / 
> System instead of /Library, otherwise having Py23Compat install  
> into plat-mac/Carbon might not have been out of the question. I  
> don't suppose Apple would be interested in including these modules  
> (in the correct location) in future Tiger updates...?

Apple did everything the right way.  Why on earth should they put  
System stuff anywhere but? ... and god I hope they don't start  
mangling their Python 2.3 distribution *mid-release* to look Python  
2.4-ish.

This problem wouldn't have existed if these modules weren't part of  
the standard library and/or they weren't part of the Carbon  
namespace.  Ripping them out or replacing them altogether with  
something generated in a more modern way is probably the right thing  
to do, eventually, but so far nobody has cared enough to deal with it.

In any case, basically all Mac OS X APIs (LaunchServices included)  
are better wrapped with PyObjC.  The stuff in Carbon is either  
becoming deprecated or being wrapped by higher-level Objective-C or  
CoreFoundation-style APIs, both of which PyObjC is much more  
appropriate for.  It's really just a question of when PyObjC's header- 
parsing capabilities will be able to wrap CoreFoundation-style stuff  
quickly and correctly.

Fortunately Apple isn't shipping PyObjC with Mac OS X, so we actually  
have the opportunity to implement these things before they become  
frozen in time.

-bob