Re: [Pythonmac-SIG] Carbon bindings' future

On 19 May, 2008, at 16:36, Daniel Miller wrote: Ronald, This version is now merged into urllib and commited as revision 63159 in the trunk. Ahh, sorry I'm late. I was on vacation last week when you posted this. Here's an updated version with a bit less duplication (about 55 lines remo

Re: [Pythonmac-SIG] Carbon bindings' future

Ronald, This version is now merged into urllib and commited as revision 63159 in the trunk. Ahh, sorry I'm late. I was on vacation last week when you posted this. Here's an updated version with a bit less duplication (about 55 lines removed). This seems like it will be much easier to mai

Re: [Pythonmac-SIG] Carbon bindings' future

On 12 May, 2008, at 12:49, Ronald Oussoren wrote: On 12 May, 2008, at 12:37, Ronald Oussoren wrote: Folks, Here's an updated version of Daniels work. Changes w.r.t. to Daniels version: Almost, but not quite. This version actually works (the "enabled" keys in the SystemConfiguration d

Re: [Pythonmac-SIG] Carbon bindings' future

On 12 May, 2008, at 12:37, Ronald Oussoren wrote: Folks, Here's an updated version of Daniels work. Changes w.r.t. to Daniels version: Almost, but not quite. This version actually works (the "enabled" keys in the SystemConfiguration dictionary have a CFNumber as theire value, not a CF

Re: [Pythonmac-SIG] Carbon bindings' future

Folks, Here's an updated version of Daniels work. Changes w.r.t. to Daniels version: * Remove all version except the one using SystemConfiguration * Add "noproxy" function * Add support for https, ftp and gopher * More defensive programming I'm going to do some testing with this version i

Re: [Pythonmac-SIG] Carbon bindings' future

On 14 Apr, 2008, at 14:24, Daniel Miller wrote: Thanks Nicholas, The general CF rule is that if you use a function named *Get*, then you don't need to CFRelease; if you use a function named *Copy* or *Create*, you do. So, what you've written looks fine. With that in mind one further modi

Re: [Pythonmac-SIG] Carbon bindings' future

Try again...that last file was my scratch file I was using for development. Here's the real thing. Sorry for the mess. ~ Daniel def getproxies_internetconfig(): """Return a dictionary of scheme -> proxy server URL mappings. This function has 'internetconfig' in its name for histo

Re: [Pythonmac-SIG] Carbon bindings' future

Thanks Nicholas, The general CF rule is that if you use a function named *Get*, then you don't need to CFRelease; if you use a function named *Copy* or *Create*, you do. So, what you've written looks fine. With that in mind one further modification seems to be necessary. Take three attac

Re: [Pythonmac-SIG] Carbon bindings' future

On Apr 11, 2008, at 3:50 PM, Daniel Miller wrote: > BTW, I'm not sure if I'm doing the memory management correctly, > especially with the values returned from CFDictionaryGetValue (it > might need a CFRelease in there). Could someone double-check me on > that please? The general CF rule is

Re: [Pythonmac-SIG] Carbon bindings' future

Take two (attached). BTW, I'm not sure if I'm doing the memory management correctly, especially with the values returned from CFDictionaryGetValue (it might need a CFRelease in there). Could someone double-check me on that please? ~ Daniel def getproxies_internetconfig(): """Return

Re: [Pythonmac-SIG] Carbon bindings' future

Internet Config is deprecated in 10.5; you should use SCDynamicStoreCopyProxies instead (see SCDynamicStoreCopySpecific.h). -- Nicholas Riley <[EMAIL PROTECTED]> | ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.

Re: [Pythonmac-SIG] Carbon bindings' future

Hi Ronald, Will this work (see attached)? ~ Daniel def getproxies_internetconfig(): """Return a dictionary of scheme -> proxy server URL mappings. By convention the mac uses Internet Config to store proxies. An HTTP proxy, for instance, is stored under the HttpProxy key.

Re: [Pythonmac-SIG] Carbon bindings' future

Folks, The removal of the Carbon bindings shouldn't impact the functionality of the rest of the standard library. This means we need to do some work though, because urllib relies on the Carbon bindings to get the current proxy settings. The best way to fix that (IMO of course) is to writ

Re: [Pythonmac-SIG] Carbon bindings' future

On 10 Apr, 2008, at 11:46, has wrote: On 9 Apr 2008, at 06:56, Ronald Oussoren wrote: On 3 Apr, 2008, at 15:46, has wrote: it would be nice to have complete bindings to the bits of Carbon that still make sense. Yes, although I'd repeat my earlier suggestion that the most economically via

Re: [Pythonmac-SIG] Carbon bindings' future

On 9 Apr 2008, at 06:56, Ronald Oussoren wrote: > > On 3 Apr, 2008, at 15:46, has wrote: >> >>> it would be nice to have complete bindings to the bits of >>> Carbon that still make sense. >> >> Yes, although I'd repeat my earlier suggestion that the most >> economically viable way to provide Carb

Re: [Pythonmac-SIG] Carbon bindings' future (was: Re: eliminating appscript-triggered Dock icon)

On 9-Apr-2008, at 07:56 , Ronald Oussoren wrote: Even fixing bgen isn't that much work, once you understand the code. The problem is that bgen is a nearly vertical learning curve and Jack seems to be the only person that understands enough of bgen to be able to hack on it. I'm definitely

Re: [Pythonmac-SIG] Carbon bindings' future (was: Re: eliminating appscript-triggered Dock icon)

On 3 Apr, 2008, at 15:46, has wrote: One of the nice things of the current Carbon bindings is that a large portion of the API is just there and you probably don't have to write C code when you want to use an API. Sadly enough that's only true of API's that were present in OS9, but the idea s

Re: [Pythonmac-SIG] Carbon bindings' future

has wrote: > > As a long-term strategy for Python as a whole, sure. The above > suggestion was for Kevin as a solution to his own more immediate needs. > Well, my commercial Python application isn't going to break tomorrow if I don't remove the Carbon bits, but it seems the long-term tides a

Re: [Pythonmac-SIG] Carbon bindings' future (was: Re: eliminating appscript-triggered Dock icon)

On 3 Apr 2008, at 13:17, Ronald Oussoren wrote: > > On 1 Apr, 2008, at 22:09, has wrote: >> On 1 Apr 2008, at 19:03, Kevin Walzer wrote: >> >> >>> Yuk. Looks like I will have to remove the Carbon bits from my app at >>> some point! >> >> Or just do what I did with appscript: fork off the bits you n