Fix for named values of BITS used via types #6
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When an OBJECT-TYPE definition uses BITS in its SYNTAX, the resulting Python code will add the definition of the bits (each with name and number) to the object as named values, as is intended and expected. However, when an OBJECT-TYPE definition uses a SYNTAX that refers to a simple type (for SMIv1) or a textual convention (for SMIv2) that uses a BITS syntax, then the resulting Python code does *not* make available the bits as named values in any way. Such "indirect" use of BITS via types is however perfectly valid as well, and indeed used in practice. Fortunately, this problem is limited to the Python code generation template, which simply does not generate the named values for the typed (indirect) case. The necessary information is available internally. This commit extends the template to generate the named values for BITS-type simple types and textual conventions. That also makes the generation consistent with similar constructions already present in the template (e.g., for generation of named values for enumerated INTEGERs). The change affects only MIBs whose generated Python code was missing the named values for BITS. New unit test cases are added for the cases that previously failed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a bugfix for an actual pysmi code generation problem that I ran into. Summarizing by example, the following (simplified) construction:
...is parsed properly and makes available bitZero(0) and bitOne(1) for enumeration via
someObject.getSyntax().namedValues, as it should. However, the following (effectively equivalent) alternative:...is also parsed properly, but does not make available bitZero(0) and bitOne(1) for enumeration via
someObject.getSyntax().namedValues, nor in any other way for that matter. Such uses of types with BITS syntax are just as valid as using BITS directly, and so I can only conclude that this behavior is not intended. This issue seems to have been present since at least pysmi's switch to the use of a Jinja2 template. The problem is fortunately also limited to that template.The attached fix addresses the problem, thus ensuring that the bit values also end up in
namedValuesin the second case. I have used my test script from PR #3 to ensure that this fix does not break anything in the mibs.pysnmp.com collection: the exact same statistics come out before and after. However, from that collection, 292 modules end up with additional named-values lists as a result of this fix, and I believe it is therefore purely an improvement for any users of those MIBs.