Re: [Pythonmac-SIG] Qualcomm Purevoice codec

Yeah, well, I don't think anyone else here has much of an idea, but would be a good place to start. I can tell you from experience that QuickTime is a bit of a pain I had hoped from Jack's original message that it would be a lot e

[Pythonmac-SIG] malloc error with imaplib or socket on OS X

Hi, I have recently come across what looks like a serious bug with Python on OS X. While writing a program using imaplib to connect to some IMAP4 servers I encountered a MemoryError exception with a malloc() error which was easily reproducible with my data at the time. The malloc error wa

Re: [Pythonmac-SIG] CFURL Pain

Bob wrote: I wonder if it'd be easier just to hand-code wrappers Actually, the easiest way is to just use PyObjC! Maybe that's the way to go for CF stuff then: delegate the problem to PyObjC and get rid of the Carbon.CF extension completely (no sense in keeping broken modules if they're not worth

Re: [Pythonmac-SIG] malloc error with imaplib or socket on OS X

On Mar 1, 2005, at 9:01 AM, Chris Miles wrote: Hi, I have recently come across what looks like a serious bug with Python on OS X. While writing a program using imaplib to connect to some IMAP4 servers I encountered a MemoryError exception with a malloc() error which was easily reproducible w

Re: [Pythonmac-SIG] CFURL Pain

On Mar 1, 2005, at 9:55 AM, has wrote: Bob wrote: I wonder if it'd be easier just to hand-code wrappers Actually, the easiest way is to just use PyObjC! Maybe that's the way to go for CF stuff then: delegate the problem to PyObjC and get rid of the Carbon.CF extension completely (no sense in keep

Re: [Pythonmac-SIG] malloc error with imaplib or socket on OS X

On Tue, Mar 01, 2005 at 02:01:29PM +, Chris Miles wrote: > The data that was causing the MemoryError was a 9 MB mail message on > the IMAP server. After I deleted this message the program on the Mac > ran fine. The other messages were max 1 MB in size and there were > about 114 of them.

Re: [Pythonmac-SIG] malloc error with imaplib or socket on OS X

On Mar 1, 2005, at 10:54 AM, John P Speno wrote: On Tue, Mar 01, 2005 at 02:01:29PM +, Chris Miles wrote: The data that was causing the MemoryError was a 9 MB mail message on the IMAP server. After I deleted this message the program on the Mac ran fine. The other messages were max 1 MB in siz

Re: [Pythonmac-SIG] CFURL Pain

Bob wrote: Maybe that's the way to go for CF stuff then: delegate the problem to PyObjC and get rid of the Carbon.CF extension completely (no sense in keeping broken modules if they're not worth fixing). Unfortunately getting rid of an extension is a lot harder than it sounds. Better is to just

Re: [Pythonmac-SIG] CFURL Pain

On Mar 1, 2005, at 11:58 AM, has wrote: Bob wrote: This still leaves Carbon APIs to deal with, however. It's unlikely that anyone is going to ever bother doing a better job wrapping Carbon than is already done, because it's a hell of a lot of work and Carbon isn't really the best way to do most

Re: [Pythonmac-SIG] CFURL Pain

Bob wrote: Instead of fixing OSA, you can write an alternative that isn't bgen based. If I do that, will the current OSA.so be thrown out (preferably right now) and replaced with my version once it's done? Unlikely, but what does it matter? 1. What's the point of adding a new extension to the stan

Re: [Pythonmac-SIG] CFURL Pain

On Mar 1, 2005, at 1:21 PM, has wrote: Bob wrote: Instead of fixing OSA, you can write an alternative that isn't bgen based. If I do that, will the current OSA.so be thrown out (preferably right now) and replaced with my version once it's done? Unlikely, but what does it matter? 1. What's the p

Re: [Pythonmac-SIG] CFURL Pain

Bob wrote: 1. What's the point of adding a new extension to the standard library when that extension is not only untested but _already known_ to be broken? They're automatically generated, these things happen. Absolutely. I have no problem with mistakes being made. It's setting them in stone tha

Re: [Pythonmac-SIG] CFURL Pain

On Mar 1, 2005, at 3:08 PM, has wrote: Bob wrote: 1. What's the point of adding a new extension to the standard library when that extension is not only untested but _already known_ to be broken? They're automatically generated, these things happen. Absolutely. I have no problem with mistakes be