Finishing up PEP 3108
The issues related to PEP 3108 now total 14. With the beta (supposedly) in a week, I am hoping the last minor details can be pulled together or decisions made on what can be postponed and what should definitely be considered a release blocker. Issue 2847 - the aifc module still imports the cl module in 3.0. Problem is that the cl module is gone. =) So it seems silly to have the imports lying about. This can probably be changed to critical. Issue 2848 - mimetools has been deprecated for a while, but it is still used in a bunch of places. Since this has been deprecated in PEP 4 for a long time, should we add the removal warning in 2.6 now and then make its actual removal of usage something to do by another beta? Issue 2849 - rfc822 is the same problem as mimetools. Issue 2854 - gestalt needs to be added back into 3.0. This is Benjamin's issue. =) Issue 2873 - htmllib is slated to go, but pydoc still uses it. Then again, pydoc is busted thanks to the new doc format. Issue 2874 - the stat module is not so useful anymore, but it still has functions that are useful. Currently the value returned by os.stat() is a named tuple, but that won't support methods. So the object returned by os.stat() needs to probably become a proper object in posix. Issue 2876 - The UserDict module has been removed in 3.0, but two classes were moved and renamed in collections and another was removed. The removal is a 3.0 warning, but the class renaming might be a tricky 2to3 fixer (not sure if the fix_imports fixer can be tweaked to handle this). Issue 2877 - UserString.UserString moved. Just need to apply the patch. Issue 2878 - Ditto for UserList. Issue 2885 - Creation of the urllib package. Jeremy has been working on this. I believe his patch is up on rietveld. Issue 2917 - This is merging pickle and cPickle. Alexandre's thing. Issue 2918 - Same for StringIO/cStringIO. Issue 2919 - profile and cProfile needs to be merged. This has not been dealt with yet. Would it be reasonable to deprecate importing cProfile directly in 2.6 with the assumption the merge will work out for 3.0? So that is everything that's left. Issue 2775 is the tracking issue so you can look there to see what issues are still open and need work. I was hoping to spend Monday and Tuesday trying to tie up as many loose ends as possible, but the conference paper I have been working on that was due Sunday is now due a week later, and so Monday and Tuesday will be spent on that (supervisor's orders). Plus I am flying out Wednesday for 10 days to help my mother move and I don't know when I will get Net again. In other words, I still need help. =) -Brett P.S.: A huge thanks goes to everyone who has helped so far. My life has been nothing but stress for a while now and you guys have helped keep the stress from reaching epic proportions.
Brett Cannon schrieb:
The issues related to PEP 3108 now total 14. With the beta (supposedly) in a week, I am hoping the last minor details can be pulled together or decisions made on what can be postponed and what should definitely be considered a release blocker.
Issue 2847 - the aifc module still imports the cl module in 3.0. Problem is that the cl module is gone. =) So it seems silly to have the imports lying about. This can probably be changed to critical.
It shouldn't be a problem to rip everything cl-related out of aifc. The question is how useful aifc will be after that ...
Issue 2848 - mimetools has been deprecated for a while, but it is still used in a bunch of places. Since this has been deprecated in PEP 4 for a long time, should we add the removal warning in 2.6 now and then make its actual removal of usage something to do by another beta?
Issue 2849 - rfc822 is the same problem as mimetools.
The problem is that nobody seems to know what exactly distinguishes mimetools/rfc822' classes and its successor's (email's) classes, so it's hard to replace it in the stdlib.
Issue 2873 - htmllib is slated to go, but pydoc still uses it. Then again, pydoc is busted thanks to the new doc format.
I will try to handle this in the coming week.
Issue 2919 - profile and cProfile needs to be merged. This has not been dealt with yet. Would it be reasonable to deprecate importing cProfile directly in 2.6 with the assumption the merge will work out for 3.0?
That's not the right way to go, you don't want to deprecate cStringIO or cPickle either.
So that is everything that's left. Issue 2775 is the tracking issue so you can look there to see what issues are still open and need work. I was hoping to spend Monday and Tuesday trying to tie up as many loose ends as possible, but the conference paper I have been working on that was due Sunday is now due a week later, and so Monday and Tuesday will be spent on that (supervisor's orders). Plus I am flying out Wednesday for 10 days to help my mother move and I don't know when I will get Net again. In other words, I still need help. =)
Let's hope we get this right in time. Then again, there are lots of other release blockers, so it may well be that the beta is delayed by some time. Georg
On Thu, May 29, 2008 at 9:12 AM, Georg Brandl <g.brandl@gmx.net> wrote:
Brett Cannon schrieb:
The issues related to PEP 3108 now total 14. With the beta (supposedly) in a week, I am hoping the last minor details can be pulled together or decisions made on what can be postponed and what should definitely be considered a release blocker.
Issue 2847 - the aifc module still imports the cl module in 3.0. Problem is that the cl module is gone. =) So it seems silly to have the imports lying about. This can probably be changed to critical.
It shouldn't be a problem to rip everything cl-related out of aifc. The question is how useful aifc will be after that ...
Has someone already used that module ? I took a look into it, but I'm a bit confused about the various compression types, case-sensitivity and compatibility issues [1]. Are Apple's "alaw" and SGI's "ALAW" really the same encoding ? Can we use the audioop module for ALAW, just like it's already done for ULAW ? [1] http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/AIFF.html Quentin
<snip>
Issue 2847 - the aifc module still imports the cl module in 3.0. Problem is that the cl module is gone. =) So it seems silly to have the imports lying about. This can probably be changed to critical.
It shouldn't be a problem to rip everything cl-related out of aifc. The question is how useful aifc will be after that ...
Has someone already used that module ? I took a look into it, but I'm a bit confused about the various compression types, case-sensitivity and compatibility issues [1]. Are Apple's "alaw" and SGI's "ALAW" really the same encoding ? Can we use the audioop module for ALAW, just like it's already done for ULAW ?
There is just one alaw I've ever come across (G.711), and the audioop implementation could be used (audioop's alaw support is younger than the aifc module, BTW) The capitalisation is confusing, but your document [1] says: "Apple Computer's QuickTime player recognize only the Apple compression types. Although "ALAW" and "ULAW" contain identical sound samples to the "alaw" and "ulaw" formats and were in use long before Apple introduced the new codes, QuickTime does not recognize them." So this seems just a matter of naming in the AIFC, but not a matter of two different alaw implementations. - Lars [1] http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/AIFF.html
On Thu, May 29, 2008 at 4:56 PM, Lars Immisch <lars@ibp.de> wrote:
<snip>
Issue 2847 - the aifc module still imports the cl module in 3.0. Problem is that the cl module is gone. =) So it seems silly to have the imports lying about. This can probably be changed to critical.
It shouldn't be a problem to rip everything cl-related out of aifc. The question is how useful aifc will be after that ...
Has someone already used that module ? I took a look into it, but I'm a bit confused about the various compression types, case-sensitivity and compatibility issues [1]. Are Apple's "alaw" and SGI's "ALAW" really the same encoding ? Can we use the audioop module for ALAW, just like it's already done for ULAW ?
There is just one alaw I've ever come across (G.711), and the audioop implementation could be used (audioop's alaw support is younger than the aifc module, BTW)
The capitalisation is confusing, but your document [1] says: "Apple Computer's QuickTime player recognize only the Apple compression types. Although "ALAW" and "ULAW" contain identical sound samples to the "alaw" and "ulaw" formats and were in use long before Apple introduced the new codes, QuickTime does not recognize them."
So this seems just a matter of naming in the AIFC, but not a matter of two different alaw implementations.
- Lars
Ok, I'll handle this issue. I'll be using the audioop implementation as a replacement of the SGI compression library. I'll also create a test suite, as Brett mentioned in the bug tracker the module was missing one. Quentin
[1] http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/AIFF.html
I've uploaded a patch for the aifc module (http://bugs.python.org/issue2847). I'm still working on the testsuite. Comments are welcome! Quentin On Thu, May 29, 2008 at 5:39 PM, Quentin Gallet-Gilles <qgallet@gmail.com> wrote:
On Thu, May 29, 2008 at 4:56 PM, Lars Immisch <lars@ibp.de> wrote:
<snip>
Issue 2847 - the aifc module still imports the cl module in 3.0. Problem is that the cl module is gone. =) So it seems silly to have the imports lying about. This can probably be changed to critical.
It shouldn't be a problem to rip everything cl-related out of aifc. The question is how useful aifc will be after that ...
Has someone already used that module ? I took a look into it, but I'm a bit confused about the various compression types, case-sensitivity and compatibility issues [1]. Are Apple's "alaw" and SGI's "ALAW" really the same encoding ? Can we use the audioop module for ALAW, just like it's already done for ULAW ?
There is just one alaw I've ever come across (G.711), and the audioop implementation could be used (audioop's alaw support is younger than the aifc module, BTW)
The capitalisation is confusing, but your document [1] says: "Apple Computer's QuickTime player recognize only the Apple compression types. Although "ALAW" and "ULAW" contain identical sound samples to the "alaw" and "ulaw" formats and were in use long before Apple introduced the new codes, QuickTime does not recognize them."
So this seems just a matter of naming in the AIFC, but not a matter of two different alaw implementations.
- Lars
Ok, I'll handle this issue. I'll be using the audioop implementation as a replacement of the SGI compression library. I'll also create a test suite, as Brett mentioned in the bug tracker the module was missing one.
Quentin
[1] http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/AIFF.html
On Thu, May 29, 2008 at 12:12 AM, Georg Brandl <g.brandl@gmx.net> wrote:
Brett Cannon schrieb:
The issues related to PEP 3108 now total 14. With the beta (supposedly) in a week, I am hoping the last minor details can be pulled together or decisions made on what can be postponed and what should definitely be considered a release blocker.
Issue 2847 - the aifc module still imports the cl module in 3.0. Problem is that the cl module is gone. =) So it seems silly to have the imports lying about. This can probably be changed to critical.
It shouldn't be a problem to rip everything cl-related out of aifc. The question is how useful aifc will be after that ...
If it ends up not being useful then the module can just go.
Issue 2848 - mimetools has been deprecated for a while, but it is still used in a bunch of places. Since this has been deprecated in PEP 4 for a long time, should we add the removal warning in 2.6 now and then make its actual removal of usage something to do by another beta?
Issue 2849 - rfc822 is the same problem as mimetools.
The problem is that nobody seems to know what exactly distinguishes mimetools/rfc822' classes and its successor's (email's) classes, so it's hard to replace it in the stdlib.
Right. I have looked myself over the years and it never seemed brain-dead simple.
Issue 2873 - htmllib is slated to go, but pydoc still uses it. Then again, pydoc is busted thanks to the new doc format.
I will try to handle this in the coming week.
Fred had the interesting suggestion of removing pydoc in Py3K based on the thinking that documentation tools like pydoc should be external to Python. With the docs now so easy to generate directly, should pydoc perhaps just be gutted to only what is needed for help() to work?
Issue 2919 - profile and cProfile needs to be merged. This has not been dealt with yet. Would it be reasonable to deprecate importing cProfile directly in 2.6 with the assumption the merge will work out for 3.0?
That's not the right way to go, you don't want to deprecate cStringIO or cPickle either.
Yeah, sorry, you're right. Guess my brain was not fully working when I wrote that. =)
So that is everything that's left. Issue 2775 is the tracking issue so you can look there to see what issues are still open and need work. I was hoping to spend Monday and Tuesday trying to tie up as many loose ends as possible, but the conference paper I have been working on that was due Sunday is now due a week later, and so Monday and Tuesday will be spent on that (supervisor's orders). Plus I am flying out Wednesday for 10 days to help my mother move and I don't know when I will get Net again. In other words, I still need help. =)
Let's hope we get this right in time.
Then again, there are lots of other release blockers, so it may well be that the beta is delayed by some time.
Guess it depends on the whim of the release manager. =) -Brett
On 29/05/2008, at 14:32, Brett Cannon wrote:
On Thu, May 29, 2008 at 12:12 AM, Georg Brandl <g.brandl@gmx.net> wrote:
Issue 2848 - mimetools has been deprecated for a while, but it is still used in a bunch of places. Since this has been deprecated in PEP 4 for a long time, should we add the removal warning in 2.6 now and then make its actual removal of usage something to do by another beta?
Issue 2849 - rfc822 is the same problem as mimetools.
The problem is that nobody seems to know what exactly distinguishes mimetools/rfc822' classes and its successor's (email's) classes, so it's hard to replace it in the stdlib.
Right. I have looked myself over the years and it never seemed brain-dead simple.
Well, as documented in issue 2849, rfc822 is almost gone. I've already removed it from mailbox and test_urllib2 modules. It seems that there remains only one important use of it, which is in cgi.FieldStorage.read_multi(). I couldn't figure out how to replace it there, though, as read_multi's current implementation relies on the fact that rfc822.Message(fp) advances the file pointer just by the amount it needs, while email.parser.Parser.parse() reads the whole file. I believe that read_multi can be rewritten in a way that's compatible with email.parser, but I don't know how to do that... :\ -- Humberto Diógenes http://humberto.digi.com.br
On Thu, May 29, 2008 at 1:49 PM, Benjamin Peterson <musiccomposition@gmail.com> wrote:
On Wed, May 28, 2008 at 11:38 PM, Brett Cannon <brett@python.org> wrote:
Issue 2854 - gestalt needs to be added back into 3.0. This is Benjamin's issue. =)
Is that your way of say "Check in the patch!" ? :)
More or less; specifically, "don't forget to do this." =) -Brett
participants (6)
-
Benjamin Peterson -
Brett Cannon -
Georg Brandl -
Humberto Diogenes -
Lars Immisch -
Quentin Gallet-Gilles