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 _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
