Nicholas Riley wrote: > > > 2.3 ic -- Access to Internet Config > > > > No idea about this. Anyone else know if this is still working/relevant? > >It is basically deprecated for LaunchServices now.
Righto, add it to the 'deprecate' list then. > It would be really good if we could get a decent LaunchServices binding - as > of now, there are several, all of which have some problems (?). Bob did an LS wrapper early on, but it's long been superceded by the one in Python 2.4's standard library, which is the only one that counts. If there's deficiencies in that then bug reports, feature requests, patches, etc. should be filed on that. But this is a topic for a different thread. > > > 4.1 Carbon.AE -- Apple Events > > > > Ronald's been thinking it might be best to deprecate both Carbon.AE > > and Carbon.OSA and keep all the AE/OSA/appscript stuff > > together. > >How far do you think your stuff is from being able to be incorporated >in the standard library? Like PyObjC, I'm in no rush. Keeping things outside of the stdlib has its advantages too. Personally I think Win32All has the right idea: put all the platform-specific extensions in a separate all-in-one collection. Then they're not at the mercy of Python proper's development cycle. But this is also a topic for another thread. :) >It'd be much nicer to just replace it rather than removing it. Mind that deprecating Carbon.AE != removing it. It'll be a couple more Python revisions before the possibility of removal even arises, and there's no requirement to drop it even then. I suspect Ronald's reasoning is that it'd be more hassle to merge CarbonX.AE and CarbonX.OSA back into the standard library than leave them where they are. There's precious few parties using these extensions anyway - appscript and co. are the major ones - so reincorporating them doesn't really gain you anything beyond a warm-n-fuzzy sense of "completeness". Nice; but why make extra work for oneself? Anyway... I'll be using my own copies of AE.so and OSA.so for the forseeable future anyhow (backwards' compatibility), so I couldn't care less either way what happens to Carbon.AE and Carbon.OSA. > > > 4.20 Carbon.Res -- Resource Manager and Handles > > > > According to Apple's docs, RM is historical, but I'm not sure about > > alternatives; need to check out Bundle Services. For now, probably do > > nothing. > >Resources are still used quite a bit by OS X; don't think it's worth >deprecating. Resources are still in use, but the crusty old Resource Manager API itself has been superceded by the modern Bundle Services API which is what folks should be using nowadays. But since Carbon.CF doesn't seem to include Bundle Services, it's probably preferable to leave RM as-is on account of something is better than nothing. (Unless it's actually broken, of course.) > > Presumably in the same boat as '2.3 ic'. Anyone? > >Yeah, deprecate for LaunchServices. Yep, agree with that. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
