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
On Sun, Feb 15, 2009 at 12:13, Daniel (ajax) Diniz <ajaksu@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
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
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
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.
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
participants (3)
-
Brett Cannon -
Daniel (ajax) Diniz -
Ronald Oussoren