Remove workaround for "values" being both a Mapping method name and STIX property name #331
Conversation
and sometimes a STIX property name. It didn't work (caused crashes under some circumstances). Now, attributes whose names conflict with Mapping methods will have the Mapping interpretation. Same-named STIX object properties will not be accessible as attributes.
Codecov Report
@@ Coverage Diff @@
## master #331 +/- ##
==========================================
- Coverage 98.17% 98.12% -0.05%
==========================================
Files 123 123
Lines 14160 13839 -321
==========================================
- Hits 13902 13580 -322
- Misses 258 259 +1
Continue to review full report at Codecov.
|
|
Looks good. Can we document that any properties with conflicting names can't be accessed this way? I think the place to do so would be in https://github.com/oasis-open/cti-python-stix2/blob/master/docs/guide/creating.ipynb, around in/out cells |
can't be used to access STIX object properties.
|
I added a cell with a prominent warning message. But notice that the notebook metadata had references to python 3 changed to python 2. Dunno if that's a problem. That happened because I used python 2 to make the change. My python 3 stix2 virtualenv was created with python 3.8, which jupyter currently has problems with. So I could either dump the whole thing and recreate with python 3.7, or just use the python 2-based virtualenv I already had. It was much easier to do the latter. But I didn't know it would have that side-effect. Does that cause any problems? |
|
No, there's no issue with the python version change. But the warning gets rendered as an awkward table. Can we match the format of the warning here? cti-python-stix2/docs/guide/workbench.ipynb Line 772 in b9927fd Thanks! |
regarding name collisions between method and property names, to not pick on the Mapping methods specifically. The problem is more general than that: stix objects have more methods than those. Instead of listing them all out, a more general statement is made, that accessing those attributes will result in a bound method, not a STIX property value.
|
The table formatting problem seems to have been the fault of pandoc, which is what sphinx uses as its format converter. It has its own markdown extensions, which unfortunately result in ambiguity: it allows 3+ dashes to indicate a horizontal rule, same as standard markdown, but reuses the same syntax for its tables (several dashes above and below). Jupyter rendered it just fine, so it must use a different system for converting markdown to HTML. That is unfortunate; now we have to keep two systems happy. Anyway, I changed it to the other format, and changed the content to not pick on the Mapping methods, since the problem is more general than that. I didn't give an exhaustive list, only said that accessing certain attributes which collide with method names will return a bound method. |
Fixes #324 .
The workaround didn't work (caused crashes under some circumstances). Now, attributes whose names conflict with Mapping methods will have the Mapping interpretation. Same-named STIX object properties will not be accessible as attributes.