-
Notifications
You must be signed in to change notification settings - Fork 270
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
allow enums in containers and support in tableio #978
Conversation
Codacy is just complaining about invalid syntax again -> f-strings. Apart from that, I think it might be fine. |
There is a class |
Might ... but I think converting back into an IntEnum upon reading is impossible without storing the enum class in the meta data. And this must be done upon writing it, no? So what is the point? |
Ah sure. |
Codecov Report
@@ Coverage Diff @@
## master #978 +/- ##
==========================================
+ Coverage 80.44% 83.37% +2.92%
==========================================
Files 193 189 -4
Lines 11051 10700 -351
==========================================
+ Hits 8890 8921 +31
+ Misses 2161 1779 -382
Continue to review full report at Codecov.
|
I contacted them and got the response that they do not yet support python 3.6+ (!!) but are looking into it. So generally we can ignore those errors. I thought I had disabled them in fact, but perhaps it has to be done for each branch? |
d27f533
to
c25ca51
Compare
@cta-observatory/cta-devs I think this might be mergeble |
Connected slightly to #972
just, in case we want to use
enum.Enum
somewhere I thought we might want to be able to serialize them as well.Not sure this is the best way to do it. I've read somewhere that HDF5 natively supports storing enumeration types, so that it deals with the back and forth trafo from the numeric value to the actual enum instance. But for the moment I did this in ctapipes own io layer.