Re: [Python-Dev] [Python-3000] Finishing up PEP 3108

[Quentin Gallet-Gilles]

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 <[EMAIL PROTECTED]>
wrote:

>
> On Thu, May 29, 2008 at 4:56 PM, Lars Immisch <[EMAIL PROTECTED]> wrote:
>
>> 
>>
>>>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
>>
>
>
___
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] [Python-3000] Finishing up PEP 3108

[Martin v. Löwis]

> The module is currently ~ 400 kb in size. If this is deemed to be a
> problem,
> we could use zlib to compress the contents -- which of course is bad for
> systems without the zlib module (are there any?).

In the distribution, the file gets compressed, anyway. In the
installation, I don't think it is a problem.

Regards,
Martin
___
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] [Python-3000] Finishing up PEP 3108

[Georg Brandl]

Mark Dickinson schrieb:
On Sat, May 31, 2008 at 11:33 AM, Georg Brandl <[EMAIL PROTECTED] 
> wrote:



Now that the docs are reST, the source is almost pretty enough to
display
it raw, but I could also imagine a "text" writer that removes the more
obscure markup to present a casual-reader-friendly text version.

The needed sources could then be distributed with Python -- it shouldn't
be more than about 200 kb.


+1 from me.  Would this mean that htmllib and sgmllib could be
removed without further ado.


OK, I've now implemented this in the trunk (will merge to 3k soon --
htmllib and sgmllib can go then).

The topic help is contained in a new module, pydoc_topics.py, which pydoc
imports to provide this help. The module can be generated with Sphinx
by running "make pydoc-topics" in the Doc/ directory. (This is one more
step for the release process, but it is an easy one.)

The module is currently ~ 400 kb in size. If this is deemed to be a problem,
we could use zlib to compress the contents -- which of course is bad for
systems without the zlib module (are there any?).

Georg

--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] [Python-3000] Finishing up PEP 3108

[Mark Dickinson]

On Sat, May 31, 2008 at 11:33 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:

>
> Now that the docs are reST, the source is almost pretty enough to display
> it raw, but I could also imagine a "text" writer that removes the more
> obscure markup to present a casual-reader-friendly text version.
>
> The needed sources could then be distributed with Python -- it shouldn't
> be more than about 200 kb.
>

+1 from me.  Would this mean that htmllib and sgmllib could be
removed without further ado.

Mark
___
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] [Python-3000] Finishing up PEP 3108

[Lars Immisch]

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
___
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] [Python-3000] Finishing up PEP 3108

[Humberto Diogenes]

On 29/05/2008, at 14:32, Brett Cannon wrote:

On Thu, May 29, 2008 at 12:12 AM, Georg Brandl <[EMAIL PROTECTED]>  
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

___
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] [Python-3000] Finishing up PEP 3108

[Quentin Gallet-Gilles]

On Thu, May 29, 2008 at 4:56 PM, Lars Immisch <[EMAIL PROTECTED]> wrote:

> 
>
>>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
>
___
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