Re: [Python-Dev] Closing outdated Mac issues
On 15 Feb, 2009, at 21:13, Daniel (ajax) Diniz wrote: Hi, In the discussion of a feature request for MacPython[1], the OP (hhas) said: As of Python 2.6/3.0, all Mac-specific modules are deprecated/ eliminated from the standard library and there are no longer any plans to submit appscript for possible inclusion. This issue should be rejected and closed. If that is the current state of Mac modules, there are no less than 17 issues* that should be closed, 4 bug reports** that might be kept open and 4 mixed-cases*** that might be obsolete/irrelevant. Besides amounting to 1% of open issues, these can divert efforts to bogus issues: I've submitted a patch for one of the mixed-cases (bug + feature request), but now don't think it was worth it. So, if someone could reassure / clarify the rules for closing these in general and/or take a quick look at specific issues, that would be a great help. The Carbon bindings in 2.6 are deprecated and I don't intend to work on fixing them, and would advise against trying to fix issues with these modules unless you're personally affected by them. Issue lists below. Regards, Daniel [1] http://bugs.python.org/issue916013 Should have been closed ages ago. * Feature requests and implementation polishing issues: http://bugs.python.org/issue706585 Expose FinderInfo in FSCatalogInfo Closed as won't fix. http://bugs.python.org/issue706592 Carbon.File.FSSpec should accept non-existing pathnames Closed as won't fix. http://bugs.python.org/issue776533 Carbon.Snd module SPB constructor shadowed Closed as fixed (after reapplying the patch on the trunk) http://bugs.python.org/issue779285 Carbon Event ReceiveNextEvent Left this open for now, I have to have a better look at the actual code to check if it is worthwhile to keep this issue open. http://bugs.python.org/issue806149 aetools.TalkTo methods can be obscured Closed as won't fix http://bugs.python.org/issue822005 Carbon.CarbonEvt.ReceiveNextEvent args wrong Left this open for now, seems to be related to issue779285. http://bugs.python.org/issue852150 Can't send Apple Events without WindowServer connection Closed as won't fix. http://bugs.python.org/issue853656 Carbon.CF.CFURLRef should be easier to create Closed as won't fix. http://bugs.python.org/issue869649 Quicktime missing funcitonality Closed as won't fix, even the C-level API is deprecated. http://bugs.python.org/issue878560 Add a console window for Carbon MacPython applets Closed as won't fix. [... Skip other issues ... : I'll have a look at these later on ] ** Probably out of date, irrelevant or both: http://bugs.python.org/issue779153 bgen requires Universal Headers, not OS X dev headers Should be closed, I'm not planning on recreating the Carbon bindings. http://bugs.python.org/issue602291 Bgen should learn about booleans This one is not related to OSX, appearently at least some people actually use Bgen for creating wrapper code. http://bugs.python.org/issue775321 plistlib error handling http://bugs.python.org/issue985064 plistlib crashes too easily on bad files Plistlib is in the generic standard library in 2.6 and 3.0. I haven't checked yet if these issues are relevant at this point in time. Ronald ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Closing outdated Mac issues
Hi Ned, Ned Deily wrote: Other than Mac/Modules, the rest of the Mac/ directory is mainly stuff used for building or going into the OS X installer images, including things like IDLE.app. These are used in 2.x and in 3.x. Thanks, knowing that makes the ticket handling easier! There are 40 C files, two headers and 69 python files in /Mac in trunk. The 2.6 (and 2.5.x) docs say development has stopped and that they'd be replaced in 2.5. So ISTM closing RFEs for these modules would be an improvement. Honestly, fixing them is fine but since the modules are deprecated but still in existence in 2.x, but they are definitely nothing above a normal priority issue. OK, I'll let the bug reports open. What about RFEs? I think the reasonable thing to do is close them as not to be fixed/implemented. At this point, the chances that someone would fix them are pretty slim and, in many cases, I'm sure the module is either obsolete because other, and better supported, solutions are now available, like PyObjC or appscript. If people feel strongly about an issue, they can always ask to re-open it. OK, Ronald is helping sort them and I'll clean whatever is left based on your combined feedback. Taking a quick look at your list, the only ones that may be worth looking at are the plistlib ones since it lives on in 3.x. I think all the rest are deprecated and gone in 3.x. OK, plistlib is a keeper in my list now. Thanks a lot for the feedback (and for helping with the Mac installers!) :) Regards, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Closing outdated Mac issues
Hi, Ronald, Ronald Oussoren wrote: On 15 Feb, 2009, at 21:13, Daniel (ajax) Diniz wrote: Hi, In the discussion of a feature request for MacPython[1], the OP (hhas) said: As of Python 2.6/3.0, all Mac-specific modules are deprecated/eliminated from the standard library and there are no longer any plans to submit appscript for possible inclusion. This issue should be rejected and closed. [...] So, if someone could reassure / clarify the rules for closing these in general and/or take a quick look at specific issues, that would be a great help. The Carbon bindings in 2.6 are deprecated and I don't intend to work on fixing them, and would advise against trying to fix issues with these modules unless you're personally affected by them. OK. [1] http://bugs.python.org/issue916013 Should have been closed ages ago. [snip] http://bugs.python.org/issue776533 Carbon.Snd module SPB constructor shadowed Closed as fixed (after reapplying the patch on the trunk) [...] http://bugs.python.org/issue779285 Carbon Event ReceiveNextEvent Left this open for now, I have to have a better look at the actual code to check if it is worthwhile to keep this issue open. Wow, thanks a lot for taking care of all these issues! If you need a hand to close, assign or just update any of them, I'd be glad to help. I'll put any closing of these on hold until you're done, I have no hurry :) http://bugs.python.org/issue779153 bgen requires Universal Headers, not OS X dev headers Should be closed, I'm not planning on recreating the Carbon bindings. OK, I'll add a 'will close unless someone who needs this comes forward' note on this one, but will leave it open for a while as it might help in wrapping code. http://bugs.python.org/issue602291 Bgen should learn about booleans This one is not related to OSX, appearently at least some people actually use Bgen for creating wrapper code. Thanks, will update it and leave open. http://bugs.python.org/issue775321 plistlib error handling http://bugs.python.org/issue985064 plistlib crashes too easily on bad files Plistlib is in the generic standard library in 2.6 and 3.0. I haven't checked yet if these issues are relevant at this point in time. They are not, I'll work on tests/patches for them. Thanks for handling these and for the valuable feedback, Ronald! Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Closing outdated Mac issues
Hi, In the discussion of a feature request for MacPython[1], the OP (hhas) said: As of Python 2.6/3.0, all Mac-specific modules are deprecated/eliminated from the standard library and there are no longer any plans to submit appscript for possible inclusion. This issue should be rejected and closed. If that is the current state of Mac modules, there are no less than 17 issues* that should be closed, 4 bug reports** that might be kept open and 4 mixed-cases*** that might be obsolete/irrelevant. Besides amounting to 1% of open issues, these can divert efforts to bogus issues: I've submitted a patch for one of the mixed-cases (bug + feature request), but now don't think it was worth it. So, if someone could reassure / clarify the rules for closing these in general and/or take a quick look at specific issues, that would be a great help. Issue lists below. Regards, Daniel [1] http://bugs.python.org/issue916013 * Feature requests and implementation polishing issues: http://bugs.python.org/issue706585 Expose FinderInfo in FSCatalogInfo http://bugs.python.org/issue706592 Carbon.File.FSSpec should accept non-existing pathnames http://bugs.python.org/issue776533 Carbon.Snd module SPB constructor shadowed http://bugs.python.org/issue779285 Carbon Event ReceiveNextEvent http://bugs.python.org/issue806149 aetools.TalkTo methods can be obscured http://bugs.python.org/issue822005 Carbon.CarbonEvt.ReceiveNextEvent args wrong http://bugs.python.org/issue852150 Can't send Apple Events without WindowServer connection http://bugs.python.org/issue853656 Carbon.CF.CFURLRef should be easier to create http://bugs.python.org/issue869649 Quicktime missing funcitonality http://bugs.python.org/issue878560 Add a console window for Carbon MacPython applets http://bugs.python.org/issue881824 Add ResolveFinderAliases to macostools module http://bugs.python.org/issue1089399 Carbon.Res misses GetIndString http://bugs.python.org/issue1089624 Carbon.File.FSCatalogInfo.createDate implementation http://bugs.python.org/issue1090958 _AEModule.c patch http://bugs.python.org/issue1113328 OSATerminology still semi-broken http://bugs.python.org/issue1169679 modules missing from list of Carbon modules http://bugs.python.org/issue1254695 QuickTime API needs corrected object types ** Bug reports, might be worth fixing in 2.6: http://bugs.python.org/issue1004810 Carbon.File fails if server vol is mounted after launch http://bugs.python.org/issue1123727 gensuitemodule.processfile fails http://bugs.python.org/issue1700507 Carbon.Scrap.PutScrapFlavor http://bugs.python.org/issue1155 Carbon.CF memory management problem ** Probably out of date, irrelevant or both: http://bugs.python.org/issue779153 bgen requires Universal Headers, not OS X dev headers http://bugs.python.org/issue602291 Bgen should learn about booleans http://bugs.python.org/issue775321 plistlib error handling http://bugs.python.org/issue985064 plistlib crashes too easily on bad files ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Closing outdated Mac issues
On Sun, Feb 15, 2009 at 12:13, Daniel (ajax) Diniz aja...@gmail.com wrote: Hi, In the discussion of a feature request for MacPython[1], the OP (hhas) said: As of Python 2.6/3.0, all Mac-specific modules are deprecated/eliminated from the standard library and there are no longer any plans to submit appscript for possible inclusion. This issue should be rejected and closed. If that is the current state of Mac modules, there are no less than 17 issues* that should be closed, 4 bug reports** that might be kept open and 4 mixed-cases*** that might be obsolete/irrelevant. Besides amounting to 1% of open issues, these can divert efforts to bogus issues: I've submitted a patch for one of the mixed-cases (bug + feature request), but now don't think it was worth it. So, if someone could reassure / clarify the rules for closing these in general and/or take a quick look at specific issues, that would be a great help. As of Python 2.6 everything Mac-specific is deprecated and in 3.0 they are gone (you can read PEP 3108 for the details or just note that the Mac/Modules directory is gone in 3.0). They will still be around in 2.7, though, as these are Py3K deprecations. Not sure what has been left in the Mac directory, but I think it is just random scripts (I never use the Mac-specific stuff so I don't know how useful some of them are to keep). Honestly, fixing them is fine but since the modules are deprecated but still in existence in 2.x, but they are definitely nothing above a normal priority issue. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Closing outdated Mac issues
Looks like the MDS ate the copy sent to the list, here's it again: Brett Cannon wrote: As of Python 2.6 everything Mac-specific is deprecated and in 3.0 they are gone (you can read PEP 3108 for the details or just note that the Mac/Modules directory is gone in 3.0). They will still be around in 2.7, though, as these are Py3K deprecations. OK, I've now read PEPs 3108 and 11, but still would like some ruling about RFEs in these stagnated Mac modules. Maybe PEP 4 could include a note about RFEs in deprecated modules? Not sure what has been left in the Mac directory, but I think it is just random scripts (I never use the Mac-specific stuff so I don't know how useful some of them are to keep). There are 40 C files, two headers and 69 python files in /Mac in trunk. The 2.6 (and 2.5.x) docs say development has stopped and that they'd be replaced in 2.5. So ISTM closing RFEs for these modules would be an improvement. Honestly, fixing them is fine but since the modules are deprecated but still in existence in 2.x, but they are definitely nothing above a normal priority issue. OK, I'll let the bug reports open. What about RFEs? Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Closing outdated Mac issues
In article 2d75d7660902151517p22440361u76f686dc2f0e1...@mail.gmail.com, Daniel (ajax) Diniz aja...@gmail.com wrote: Brett Cannon wrote: As of Python 2.6 everything Mac-specific is deprecated and in 3.0 they are gone (you can read PEP 3108 for the details or just note that the Mac/Modules directory is gone in 3.0). They will still be around in 2.7, though, as these are Py3K deprecations. OK, I've now read PEPs 3108 and 11, but still would like some ruling about RFEs in these stagnated Mac modules. Maybe PEP 4 could include a note about RFEs in deprecated modules? Not sure what has been left in the Mac directory, but I think it is just random scripts (I never use the Mac-specific stuff so I don't know how useful some of them are to keep). Other than Mac/Modules, the rest of the Mac/ directory is mainly stuff used for building or going into the OS X installer images, including things like IDLE.app. These are used in 2.x and in 3.x. There are 40 C files, two headers and 69 python files in /Mac in trunk. The 2.6 (and 2.5.x) docs say development has stopped and that they'd be replaced in 2.5. So ISTM closing RFEs for these modules would be an improvement. Honestly, fixing them is fine but since the modules are deprecated but still in existence in 2.x, but they are definitely nothing above a normal priority issue. OK, I'll let the bug reports open. What about RFEs? I think the reasonable thing to do is close them as not to be fixed/implemented. At this point, the chances that someone would fix them are pretty slim and, in many cases, I'm sure the module is either obsolete because other, and better supported, solutions are now available, like PyObjC or appscript. If people feel strongly about an issue, they can always ask to re-open it. Taking a quick look at your list, the only ones that may be worth looking at are the plistlib ones since it lives on in 3.x. I think all the rest are deprecated and gone in 3.x. -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
