osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] PEP 594: update 1


Dear python-dev,

I'm writing to provide some feedback on PEP-594, primarily the proposed
deprecation and reason for the removal of the aifc and audioop libraries.

The post production film industry continues to make heavy use of AIFFs, as
completely uncompressed audio is preferred. Support for the consumer
alternatives (ALAC, FLAC) is virtually non-existent, with no movement
towards adoption of those formats. Even Apple's own professional editing
tool Final Cut Pro does not support ALAC. Many of the applications also
support WAV, but not all.

Removal of this module from the standard library is complicated by the fact
that a large number of film industry facilities have extremely limited
internet access for security reasons. This does not make it impossible to
get a library from pypi, but speaking to those devs has made me aware of
what a painful process that is for them. They have benefited greatly from
aifc's inclusion in the standard library.

While development of the aifc and audioop libraries has slowed, this looks
consistent with mature projects and file formats that are not undergoing
constant change. Checking the bug tracker for aifc and audioop does not
paint a picture of these being broken or leaky modules requiring a lot of
dev time, and there are 2 community sourced pull requests in progress right
now.

The film industry may not make up a large chunk of python devs, but it is
python that makes tent pole films like Avengers possible. Without the
python digital asset management pipelines, films of that scale wouldn't be
possible.

Thank you for your time and consideration,

Sean Wallitsch
Lead Technical Director, DreamWorks Animation

On Wed, May 22, 2019 at 8:21 AM Brett Cannon <brett at python.org> wrote:

>
>
> On Wed., May 22, 2019, 03:13 Antoine Pitrou, <solipsis at pitrou.net> wrote:
>
>> On Tue, 21 May 2019 17:44:16 -0700
>> Brett Cannon <bcannon at gmail.com> wrote:
>> > >
>> > > So I should never have added those tests and then we wouldn't be
>> talking
>> > > about removing nntplib.
>> > >
>> >
>> > Not necessarily. I suspect it still would have been listed, you would
>> have
>> > objected, and someone may have looked at the tests to point out it was
>> only
>> > unit tests with no integration tests against a live service like e.g.
>> the
>> > pythontest.net-related tests and so it was already neglected.
>>
>> But that's moving the goalposts.
>
>
> I was just replying to your hypothetical with another hypothetical.
>
>   The PEP talks about "cruft,
>> unnecessary duplication of functionality, and dispensable features". Not
>> modules which have an insufficient test suite.
>>
>
> To me, untested code is a potential signal of cruft.
>
>
>> > It also doesn't help that no one is listed in the experts index for the
>> > module either.
>>
>> Right, but that's the case for many modules.
>>
>
> I never said I didn't view this PEP as conservative. ?
>
> Anyway, my support of dropping nntplib is +0 so I personally support
> Christian if he wants to keep on the list but I'm also not that bothered if
> he wants to take it off the list.
>
> -Brett
>
>
>> Regards
>>
>> Antoine.
>>
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/sean.wallitsch%40dreamworks.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190522/794c205f/attachment.html>