Open andrewvaughan opened 9 months ago
The implementation comes from a time before there was enum in the standard library. Switching to the built-in enum might be a breaking change in some way. But implementing the name
and value
properties makes sense to me.
there's no easy way for me to just get CBR as you've forced the string representation to be BitrateMode.CBR. I have no idea why anyone would ever want the Enum class in their string representation and is very non-standard.
I wouldn't call it "very non-standard". It is exactly what Python's enum.__str__
does as well:
from enum import Enum
Color = Enum('Color', ['RED', 'GREEN', 'BLUE'])
str(Color.RED) # This is "Color.RED"
https://github.com/quodlibet/mutagen/blob/f95d3ae19e25e3f0a91061566551843d799317c5/mutagen/mp3/__init__.py#L36
This is a very unusable implementation - namely because it requires a
match/case
or similar anti-pattern to be implemented as you've created a fairly whacky method of returning a string representation.For example, if I simply want to record that the bit-rate mode of an MP3 was CBR - there's no easy way for me to just get
CBR
as you've forced the string representation to beBitrateMode.CBR
. I have no idea why anyone would ever want the Enum class in their string representation and is very non-standard.Either this, or please implement the standard
.name
and.value
properties in normal Pythonenum
to make this possible.https://docs.python.org/3/library/enum.html#enum.Enum