Proposed changes to linuxaudiodev
Hi all --
I've been hacking sporadically on the linuxaudiodev module for the last couple of days. Initial results are in patch #645786 (www.python.org/sf/645786). The main goal of this patch is to make linuxaudiodev objects a thinner wrapper around the underlying OSS device driver, while still providing some highish-level convenience methods -- see my comments in the patch for details.
There's a slight theoretical risk of backwards incompatibility, though. Since this module has never been documented, and since its current behaviour is such that doing anything really funky is severely curtailed, I very much doubt this will be a problem. Is anyone doing anything with linuxaudiodev more sophisticated than playing silly beep sounds? Should I ask around on python-list to be sure I won't ruin anyone's day with this change?
Oh yeah: someone noted in the CVS history that the module is misnamed. This is true; it should probably have been called ossaudiodev -- OSS is the current standard audio API used by Linux and, I think, various BSDs. It's also available for a bunch of commercial Unices.
Greg
I've been hacking sporadically on the linuxaudiodev module for the last couple of days. Initial results are in patch #645786 (www.python.org/sf/645786). The main goal of this patch is to make linuxaudiodev objects a thinner wrapper around the underlying OSS device driver, while still providing some highish-level convenience methods -- see my comments in the patch for details.
There's a slight theoretical risk of backwards incompatibility, though. Since this module has never been documented, and since its current behaviour is such that doing anything really funky is severely curtailed, I very much doubt this will be a problem. Is anyone doing anything with linuxaudiodev more sophisticated than playing silly beep sounds? Should I ask around on python-list to be sure I won't ruin anyone's day with this change?
Oh yeah: someone noted in the CVS history that the module is misnamed. This is true; it should probably have been called ossaudiodev -- OSS is the current standard audio API used by Linux and, I think, various BSDs. It's also available for a bunch of commercial Unices.
I recommend that you simply check in your new code as ossaudiodev and we'll mark the linuxaudiodev module as deprecated.
--Guido van Rossum (home page: http://www.python.org/~guido/)
On 29 November 2002, Guido van Rossum said:
I recommend that you simply check in your new code as ossaudiodev and we'll mark the linuxaudiodev module as deprecated.
Sounds fine to me. Should I worry about adding an official DeprecationWarning to linuxaudiodev.c? Or does that wait until 2.4?
Greg
On Sat, Nov 30, 2002, Greg Ward wrote:
On 29 November 2002, Guido van Rossum said:
I recommend that you simply check in your new code as ossaudiodev and we'll mark the linuxaudiodev module as deprecated.
Sounds fine to me. Should I worry about adding an official DeprecationWarning to linuxaudiodev.c? Or does that wait until 2.4?
Given its lack of official documentation, I'd vote for DeprecationWarning now.
Sounds fine to me. Should I worry about adding an official DeprecationWarning to linuxaudiodev.c? Or does that wait until 2.4?
Given its lack of official documentation, I'd vote for DeprecationWarning now.
+1.
Somebody check this in please. (But make sure that running the unit tests doesn't issue the warning.)
--Guido van Rossum (home page: http://www.python.org/~guido/)
[me]
Sounds fine to me. Should I worry about adding an official DeprecationWarning to linuxaudiodev.c? Or does that wait until 2.4?
[Aahz]
Given its lack of official documentation, I'd vote for DeprecationWarning now.
[Guido]
+1.
Somebody check this in please. (But make sure that running the unit tests doesn't issue the warning.)
Two points:
* ossaudiodev isn't 100% compatible with linuxaudiodev -- does this affect your decision? (Currently the incompatible is limited to subtle behavioural stuff, but I plan to change some peculiar method signatures -- setparameters(), in particular, takes an 'ssize' argument that serves no purpose as near as I can tell.)
* if I remove test_linuxaudiodev.py, which should be fine since I've just created and checked in test_ossaudiodev.py, then the warnings from the test suite won't be an issue. OK if I remove it?
Greg
[me]
Sounds fine to me. Should I worry about adding an official DeprecationWarning to linuxaudiodev.c? Or does that wait until 2.4?
[Aahz]
Given its lack of official documentation, I'd vote for DeprecationWarning now.
[Guido]
+1.
Somebody check this in please. (But make sure that running the unit tests doesn't issue the warning.)
Two points:
- ossaudiodev isn't 100% compatible with linuxaudiodev -- does this affect your decision? (Currently the incompatible is limited to subtle behavioural stuff, but I plan to change some peculiar method signatures -- setparameters(), in particular, takes an 'ssize' argument that serves no purpose as near as I can tell.)
I don't care about API compatibility -- as long as oss lets you do the same stuff (possibly by making different calls) I think it's a good replacement. The deprecation warning for linuxaudiodev doesn't mean it's illegal to use it today -- it means it will go away in the future.
- if I remove test_linuxaudiodev.py, which should be fine since I've just created and checked in test_ossaudiodev.py, then the warnings from the test suite won't be an issue. OK if I remove it?
Typically, we don't remove tests for deprecated code until we remove the deprecated code itself. This saves us from accidentally breaking the deprecated code before it's time to kill it.
--Guido van Rossum (home page: http://www.python.org/~guido/)
participants (3)
-
Aahz -
Greg Ward -
Guido van Rossum