Originally reported by: Christoph Reiter (Bitbucket: <a href="http://bitbucket

Original comment by Christoph Reiter (Bitbucket: <a href="http://bitb

easyid3.py module raises ValueError instead of KeyError about mutagen HOT 4 CLOSED

quodlibet commented on June 4, 2024

easyid3.py module raises ValueError instead of KeyError

from mutagen.

Comments (4)

lazka commented on June 4, 2024

Original comment by Christoph Reiter (Bitbucket: lazka, GitHub: lazka):

From [email protected] on January 08, 2010 15:20:33

In fact my idea was so good I implemented it months ago. The current EasyID3 module
raises a subclass of KeyError and ValueError, and mutagen.id3.error, for all the
reasons described above.

Status: Invalid

from mutagen.

lazka commented on June 4, 2024

Original comment by Christoph Reiter (Bitbucket: lazka, GitHub: lazka):

From [email protected] on January 08, 2010 15:16:19

Status: Accepted

from mutagen.

lazka commented on June 4, 2024

Original comment by Christoph Reiter (Bitbucket: lazka, GitHub: lazka):

From [email protected] on January 06, 2010 08:52:50

I think __getitem__ (and __delitem__) should never be raising a ValueError. A missing
key and an unsupported key are identical from the perspective of the getter, since an
unsupported key is always missing.

setitem should probably throw a custom subclass of both KeyError and ValueError,
for compatibility.

from mutagen.

lazka commented on June 4, 2024

Original comment by Christoph Reiter (Bitbucket: lazka, GitHub: lazka):

From [email protected] on January 05, 2010 20:01:40

What you propose would make it nearly impossible for a program to determine if a key
was rejected for being missing or for being unsupported. Support varies for keys
across different versions of mutagen.

The current state of play is...

KeyError indicates data not present (read).
ValueError indicates feature not present (read/write).

from mutagen.

Recommend Projects