Fix documentation build due to class being name shadowed by a singleton

[kitchoi]

Fix #1377

The singleton instance name is the same as its type name. This is confusing sphinx, and is causing the following error with Sphinx 3.4.1 while building doc:

reading sources... [ 51%] traits_api_reference/trait_type                                                                                                                                                                                 
Exception occurred:
  File "/Users/kchoi/Work/ETS/py39-venv/traits-env/lib/python3.9/site-packages/sphinx/util/typing.py", line 160, in _restify_py37
    return ':obj:`%s.%s`' % (cls.__module__, cls.__name__)
AttributeError: 'NoDefaultSpecified' object has no attribute '__name__'
The full traceback has been saved in /var/folders/_6/bw6pnpwx3pzfvhd20ffcpyjm0000gn/T/sphinx-err-4260mu_5.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks!
make: *** [html] Error 2

Checklist

• Tests
• Update API reference (docs/source/traits_api_reference)
• Update User manual (docs/source/traits_user_manual)
• Update type annotation hints in traits-stubs

[kitchoi]

Alternatively we can change the class name to be different. Or maybe there are other tricks. However I find the name NoSpecifiedDefault misleading for an instance.

[mdickinson]

LGTM, but let's make it _no_default_specified, so that it's clearly private, to discourage use elsewhere.

In theory this is an API-breaking change for anyone using NoDefaultSpecified in other packages. In practice I can't find any other uses within ETS, uses outside ETS seem unlikely, and I'm willing to risk the breakage.

We might also consider renaming the class to _NoDefaultSpecified, or even simply using an instance of object as the sentinel, but that can be done in a separate PR.

[kitchoi]

Ah, good point about this being API-breaking.
I think I found instances of importing NoDefaultSpecified to be used in a custom Trait type definition in a private project.

[kitchoi]

I think I found instances of importing NoDefaultSpecified to be used in a custom Trait type definition in a private project.

On closing closer inspection, those codes are actually dead. But the use case remains valid to me :/

[mdickinson]

Okay. The urgent need is to get the doc build fixed, so that CI isn't blocked. For that, how about we simply change the incorrect autoclass entry for NoDefaultSpecified to autodata? We can change the code later.

[kitchoi]

I will merge this to resolve #1377 and unblock CI for PRs.
I will open an issue for revisiting how we want to expose this no-default-value singleton (and if we want to expose it at all).

[mdickinson]

I will merge this to resolve #1377

Please could you make the requested name change before merging?

[mdickinson]

Ah, sorry; too late.

[kitchoi]

Oops, sorry. I thought the name change is related to the new issue.

[mdickinson]

Oops, sorry. I thought the name change is related to the new issue.

Okay; please open the new issue and we'll discuss there. Thanks for the quick fix.

[kitchoi]

Opened #1379