Issue 2715: Remove carbon-specific code from binhex (original) (raw)

Created on 2008-04-29 00:08 by brett.cannon, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (9)
msg65947 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2008-04-29 00:08
There is carbon-specific code in binhex. It really should go so that the module is completely platform-independent. This is especially pertinent for 3.0 as all Mac-specific modules are slated to go.
msg66150 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2008-05-03 08:36
Have you read that code? The Carbon-specific code in there is needed to make the module behave correctly in OSX: the Carbon specific code is used to get and set some Mac-specific file attributes. It should be easy enough to move that code into a small C extensions though, that way binhex will no longer depent on the Carbon python package.
msg66166 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2008-05-03 19:46
On Sat, May 3, 2008 at 1:36 AM, Ronald Oussoren <report@bugs.python.org> wrote: > > Ronald Oussoren <ronaldoussoren@mac.com> added the comment: > > Have you read that code? Not in detail, no. > The Carbon-specific code in there is needed to > make the module behave correctly in OSX: the Carbon specific code is used > to get and set some Mac-specific file attributes. > > It should be easy enough to move that code into a small C extensions > though, that way binhex will no longer depent on the Carbon python > package. OK.
msg91193 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-08-02 18:46
This came up again recently in issue 6621. What's the current status of the binhex module in py3k? It looks as though the Carbon-specific code has been *partially* but not completely removed. In particular, there are references to FSSpec remaining, but no FSSpec is imported anywhere. The references to FSSpec are all inside "if os.name == 'mac': ... " blocks. On my 10.5/Intel and 10.4/PPC systems os.name gives 'posix', so these blocks never get executed. Is it safe to simply remove these blocks?
msg91195 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2009-08-02 19:15
From my understanding the mac platform is OS 9, so that code in those 'if' blocks can go.
msg91201 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-08-02 20:10
Thanks, Brett. I've removed those blocks in r74289 (py3k) and r74290 (release31-maint).
msg91202 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-08-02 20:13
It looks to me as though this issue can now be closed. Ronald, any comments?
msg104542 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-04-29 17:36
I would close this, but I am not sure what the resolution should be.
msg104547 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-04-29 17:54
Closing as fixed.
History
Date User Action Args
2022-04-11 14:56:33 admin set github: 46967
2010-04-29 17:55:05 mark.dickinson set status: open -> closed
2010-04-29 17:54:55 mark.dickinson set resolution: fixedmessages: +
2010-04-29 17:36:00 terry.reedy set status: pending -> opennosy: + terry.reedymessages: +
2009-08-02 20:13:08 mark.dickinson set status: open -> pendingmessages: +
2009-08-02 20:10:59 mark.dickinson set messages: +
2009-08-02 19:15:39 brett.cannon set messages: +
2009-08-02 18:47:20 mark.dickinson link issue6621 superseder
2009-08-02 18:46:13 mark.dickinson set nosy: + mark.dickinsonmessages: +
2008-05-03 19:46:57 brett.cannon set messages: +
2008-05-03 08:36:44 ronaldoussoren set nosy: + ronaldoussorenmessages: +
2008-04-29 00:08:06 brett.cannon create