Don't parse items from a string; pass an iterable
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
flufl.enum |
Fix Released
|
High
|
Barry Warsaw |
Bug Description
As discussed in email. The make_enum helper accepts a string that it splits into enum items at intervening whitespace.
Doing it that way implicitly prevents whitespace in enum items, but then why not also split on enumeration and such? Because it would become arbitrary and messy, that's why. But do accidental whitespace and accidental punctuation in the string really deserve to be treated differently?
Moreover, what happens when an item contains unintended whitespace? You'd get two (or more) items where you expected one. Some of them may clash with other values in the enum. Later values have their integer values shifted because of the extras. And the value you expected may be missing. That's a lot of different ways for the same simple mistake to manifest itself, on top of the totally different error you might get for other kinds of invalid characters.
So I emphatically recommend taking an iterable of strings instead, and making sure there's a single, unambiguous, and immediate error when invalid characters sneak in.
Changed in flufl.enum: | |
status: | New → Confirmed |
importance: | Undecided → High |
Changed in flufl.enum: | |
status: | Confirmed → Fix Committed |
assignee: | nobody → Barry Warsaw (barry) |
Changed in flufl.enum: | |
status: | Fix Committed → Fix Released |
Signalling an error when invalid characters are used should already work, because we do a check for valid Python identifiers. However, I agree that the API would be better if it took an iterator rather than a space-separated string. It would better match namedtuple() for example.
Care to take a crack at a patch/branch? Note that we have to keep the old interface for backward compatibility, though it can be deprecated. If you don't have time for that, let me know and I'll work on the patch. Thought you might have fun with it though :).