@alexcjohnson if you have time to look this over we'd be grateful for your feedback

@bmaranville The fileplotly/validators/_validators.json needs to be flagged in thepyproject.toml so that it's included in the built package.

Looks like the correct way is to addvalidators/_validators.json to the list under[tool.setuptools.package-data].

Thanks for the PR@bmaranville ! Other than my comments above, looks good to me. The tests are passing and validation seems to be working as usual in the examples I've tried. (@alexcjohnson I'm curious whether you can see any possible pitfalls or edge cases here -- happy to do more testing of specific cases if you have concerns.)

@bmaranville nice work, this is a clever solution! Two small thoughts about it:

• We should be able to reduce the whitespace significantly, to make the file smaller. Could even collapse it to a single line, I'm not sure there's much value keeping it human-readable, but maybe@emilykl has opinions about this. If we really want to optimize file size we could also change its structure a bit - like if every entry is a dict{params, superclass} this could be converted to a length-2 list. But the whitespace is the biggest piece of this.
• json.load is pretty fast, ~41ms on my computer. But it's even faster if we just make this a Python file. In my quick test I just added:

true=Truefalse=Falsenull=Nonev=

to the beginning of the file to convert the JSON to Python, and thenfrom validators._validators import v took only ~25ms. (If we do this for real we should be able to tweak thejson.dump to output Python in the first place so we don't need to aliastrue,false, andnull)

@emilykl the only thing I'm not 100% confident of is whether this has any type checking implications. I don't think so, I think the only type checking that matters is ongraph_objs, notvalidators, but we do currently haveif TYPE_CHECKING blocks in all the__init__.py files in validators, ensuring that type checkers will load them all. If you haven't done so already it's probably worth playing around on this branch a bit to convince ourselves that we don't lose anything important with this.

@alexcjohnson 👍 on reducing whitespace, but I'd like to merge this one first, then combine it with#5218, and then tidy up the whitespace in the result -#5218 switches code formatting and checking fromblack toruff, so if we're going to figure out how to configure a tool to stay silent about things like long lines, I'd like to do that once. I've created#5225 and will assign it to myself.

• We should be able to reduce the whitespace significantly, to make the file smaller. Could even collapse it to a single line, I'm not sure there's much value keeping it human-readable, but maybe@emilykl has opinions about this.

@alexcjohnson I'm in favor of this. I don't think there's any particular reason to keep it human-readable, although it's also not a HUGE difference with compression. Looks like about 194 KB compressed with whitespace vs. 163 KB compressed without whitespace, from a quick test I did locally.

• json.load is pretty fast, ~41ms on my computer. But it's even faster if we just make this a Python file. ... convert the JSON to Python, and thenfrom validators._validators import v took only ~25ms. (If we do this for real we should be able to tweak thejson.dump to output Python in the first place so we don't need to aliastrue,false, andnull)

@alexcjohnson@gvwilson I'm in favor of this -- that's a big performance improvement. Something for a future PR? (as a bonus, then we wouldn't have to worry about including this file in thepyproject.toml, since Python files are included automatically.)

@emilykl the only thing I'm not 100% confident of is whether this has any type checking implications. I don't think so, I think the only type checking that matters is ongraph_objs, notvalidators, but we do currently haveif TYPE_CHECKING blocks in all the__init__.py files in validators, ensuring that type checkers will load them all. If you haven't done so already it's probably worth playing around on this branch a bit to convince ourselves that we don't lose anything important with this.

I'm not aheavy user of type checking so it's possible I'll miss something here. Syntax highlighting is working as expected with these changes. I turned on stricter Pylance type checking and haven't noticed any issues yet but I'll keep an eye out. Hopefully we can put these changes out in an RC to catch any issues before full release.