Open noahlt opened 3 weeks ago
The changes to OutputFormat look good. Are they backwards compatible?
Still investigating/thinking about this. If someone was calling isinstance(output_format, OutputFormat)
it will now fail. And like I said, I'm not even sure what type benefits we're getting. So I'm thinking about just adding these validation checks to the OutputFormat constructor, but I can't do that while keeping it a TypedDict.
If someone here is very opinionated about Python stuff and familiar with the ecosystem and modern conventions, I'm all ears — I haven't primarily used Python in a long time.
Instead of change_voice_file and change_voice_bytes, I think just bytes and file would be a little bit cleaner, since the API then looks like client.voice_changer.bytes() instead of client.voice_changer.change_voice_bytes().
Yeah I'll make this change.
Even better would be if you can pass a file-like object to a single function bytes and it figures out whether it's a file or not.
I like the convenience of the current function signature, where you pass in file paths as strings, so client code doesn't have to manage file handles and with
blocks. But then again, I'm out of the loop with current python conventions.
@noahlt Let's make it so that when you pass in a file, it decides whether it's:
If it's a string, maintain the current behavior. If it's a file, skip reading.
Summary
Adds:
Cartesia.voice_changer.change_voice_bytes
, which takes raw bytesCartesia.voice_changer.change_voice_file
, which takes filepaths for in/out and handles file writingThis change also adds some type trickery for
OutputFormat
, which I'm not 100% convinced is good. Namely: if we're doing runtime validation forOutputFormat
, then it's not clear that the type guarantees ofStrictOutputFormat
really buy us that much.Remaining work
OutputFormat
,StrictOutputFormat
,MP3Format
,WAVFormat
, andRawFormat
— if we like this, I have to update internal usage fromOutputFormat
toStrictOutputFormat
, but maybe this isn't actually worth it