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.
Somebody check this in please. (But make sure that running the unit tests doesn't issue the warning.)
- 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/)