Using slug constants like "planned" or "reserved" with API

[markkuleinio]

In NetBox 2.7 the change #3569 was implemented to replace numeric constants with string representations in various places, like in device status field. Before that I had a get_choice() function in my toolbelt to map for example device status Planned to the correct numeric value using the various choice retrieval APIs in pynetbox (for example: status_planned = get_choice(nb.dcim.devices.choices(), "status", "Planned")). Now with 2.7+ I can just use the string value planned when creating a new device with the API.

For legacy compatibility I have kept using my trusty get_choice() helper, but now I'm thinking: Now that I've long time ago upgraded all my NetBox systems to 2.7+, is there any reason to use that kind of helper function anymore?

I mean, with NetBox 2.6 and earlier I just couldn't bother with remembering what was the number for Planned status, and there was also a small possibility that somehow the value could be changed later (a point that actually was proven by #3569 itself 😀), so I just created the get_choice() helper and later made it compatible with whatever NetBox version was actually currently running on the server against which my code was being used. But currently the string representations look so useful and obvious by themselves that I'm thinking about just using them directly from now on.

Any thoughts on this? Or rather, would there be any practical downsides in this thinking?

[jeremystretch]

The ability to use human-friendly values directly for these fields (as opposed to integers) was one of the goals of #3569. I can't think of any benefit to keeping the translation layer around, unless you might still need to interface with pre-2.7 instances.