gh-94991 Make wave._wave_params public -> wave.wave_params

[f4hy]

This namedtuple is the public interface for Wave_write.setparams, making this private does not allow users to create an input that is typechecked to Wave_write.setparams.

If this were public users could call with more readable code such as:

import wave
with wave.open("test.wav", "wb") as wav_file:
    params = wave.wave_params(
        nchannels=1, sampwidth=2, framerate=16_000, nframes=0, comptype="NONE", compname="NONE",
    )
    wav_file.setparams(params)

rather than the less readable

import wave
with wave.open("test.wav", "wb") as wav_file:
    params = (1, 2, 16_000, 0, "NONE", "NONE")
    wav_file.setparams(params)

This is even worse in a typed environment where the private type of wave._wave_params is the only way to call setparams which use of private values from the stdlib should be avoided.

• Issue: _wave_parameters in wave.py should be public #94991

[ghost]

All commit authors signed the Contributor License Agreement.

[bedevere-bot]

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

[mbeijen]

Hi, this seams very reasonable and I think it should be merged in python!

I created a small drop-in replacement for stdlib wave: newwave, available on pypi. I added this PR to that package, thanks!!

But I also added wave.write() as 'syntactic sugar' on top of `wave.open(..., 'wb'):

# Using the convenience function
with newwave.write('output.wav', channels=2, sampwidth=2, framerate=44100) as w:
    w.writeframes(audio_data)

That is even easier!! What do you think?

[encukou]

This could go together with adding a non-positional format attribute, as needed by #60729.

But I also added wave.write() as 'syntactic sugar' on top of `wave.open(..., 'wb'):

I wouldn't mind this in wave.Wave_write.__init__ itself.
Or if we're doing better user-facing names, prehaps wave.Writer?

[github-actions]

This PR is stale because it has been open for 30 days with no activity.