Jeffrey C. Ollie

IMHO, trying to create a formal model for addresses is creating more work than it's worth for NetBox. I'd say leave the addresses as a free-form box. If individual implementations...

> It would solve this because parsing freeform addresses is extremely difficult--it's pretty easy to turn a structured address back into a freeform address if another system requires that, and...

I don't know if I'd recommend using regular expressions to validate the data. I'd use dnspython. It has a really handy function dns.rdata.from_text() for parsing the data: ``` >>> import...

> @zachmoody I’d say PR #426 could be merged as it is. I think it is the most important here as it fixes an actual bug. What objections are there...

Adding this patch to my local copy of pynetbox lets API calls that delete or update plugin objects work.

Personally, I'd like to see custom objects turned into ```Record```s. I'd be OK if that was behind a feature flag if performance suffers. There's also the issue of creating/modifying custom...

A thought that I just had... If NetBox was to return a list of the fields that were custom objects or JSON fields with every API call that would save...

> Personally I'm leaning towards not doing anything in `pynetbox` I don't think that's an option because pynetbox cannot currently update objects that contain JSON or object custom fields.

> TBH, I don't get the purpose of "`k: v if not isinstance(v, dict) else v["value"]`" in `flatten_custom()`: basically it says that if the custom field data is a dict,...

> But `flatten_custom()` is only used for custom fields, see the line #456 in the snippet above thinking Not saying it makes sense, just trying to guess what the author...