Greetings all, new Anvil user here.
I’ve been trying to get some python code I previously wrote to work client-side, and the biggest breakage I’ve come across so far is the seeming lack of enum support. Am I correct that this is not supported?
If not, has anyone else come across a similar issue, and would anyone have any pearls of wisdom on what strategies might be best? E.g., would it be worth trying to somehow shim enum? Should I fundamentally rethink my entire implementation? Any advice is welcome.
If enum is indeed missing from Anvil/Skulpt, is there any chance that it might be implemented?
Finally, is there a list somewhere of python 3.6 libraries/syntax that are not available/allowed client-side?
Best, Dan
hi @daniel1 and welcome to the forum
I’d definitely turn this into a feature request. No one has yet requested the Enum module (that i’m aware of).
linked topic: Client side Python and skulpt
I’ve looked at the code for Enum - and you can’t shim it straight from cpython i’m afraid. It relies on metaclasses which are not (yet) supported in anvil/skulpt.
Enum has a lot of functionality involved and I would consider writing a custom class that implements just the parts of Enum that you need. Of course how easy depends on how much of the functionality you need.
If it’s simple functionality then consider namedtuple.
from collections import namedtuple
>>> Color = namedtuple('Color', 'RED, GREEN, BLUE', defaults=[3, 4, 5])
>>> C = Color()
>>> C.RED
3
(You can also subclass from namedtuple which might help to extend the behaviour)
1 Like
In my coding experience, enumeration constants by themselves are rarely enough. Each value ends up being tied to some representation, somewhere: in a database (as a CHAR(1) column), a binary data file (as a single byte), a GUI (as a human-readable choice), an external program or API (an integer or string), a C/C++ program (a named enum constant), …
Usually, it’s several at once. So the end result is really a lookup table, where the rows are enumeration values, and the column identifies the context in which the value appears.
- Add a context? Add a column.
- Add a value? Add a row.
- Need to present the rows in a particular order? Add a sequence_number column for the corresponding context.
- Need to hide a row from a particular context? Yup, another context-specific (boolean) column.
It also extends naturally to a hierarchical outline (as in accounting’s “chart of accounts”), but I’ll leave those additional columns as an exercise.
I find it is often best to maintain a single, central “source of truth” for this lookup table. It could be in any handy format: JSON, CSV, a list of lists, a database table. That can be used to generate subsets, or even code.
In short, I find almost any language’s enum facilities insufficient in themselves. You almost always have to add scaffolding around them to connect them to whatever else is going on. And once you do that, it’s no longer really an enum.
Thank you @stucork and @p.colbert. Yes, it turned out I didn’t exactly need enum for what I was using it for, so being required to excise it didn’t turn out to be such a bad thing. (I think I went a little enum-crazy after learning a smattering of Rust, in which enums really are invaluable.)
-Dan
PS @stucork, congratulations on your adorable baby boy!
1 Like