You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
While implementing, I realized that we come up with any (in)valid decision point inside the registered namespace test. However, we don't have a place to test namespace things with a registered namespace that is invalid - i.e. not registered.
Describe the solution you'd like
I think it would be helpful to reserve the registered namespace invalid - comparable to the .invalid assignment in DNS.
Describe alternatives you've considered
Using random namespace that are not yet registered: You can't be sure that they won't be registered in the future.
This should also be done for the unregistered space (starts with x_invalid.)
I tried adding x_invalid to the enumerated list, but it fails to validate against the NS pattern because it starts with x_ but does not contain a fragment. So right now #915 only adds invalid. (Which I understand is the point of it being invalid, but it breaks a unit test in a way that I can't investigate right now.
deftest_namespaced_create(self):
# use the official namespace valuesfornsinNameSpace:
>obj=_Namespaced(namespace=ns)
Epydantic_core._pydantic_core.ValidationError: 1validationerrorfor_NamespacedEnamespaceEStringshouldmatchpattern'^(?=.{3,1000}$)(x_([a-z]|[0-9])(((([a-z]|[0-9])|-)){,61}([a-z]|[0-9]))?(\.([a-z]|[0-9])(((([a-z]|[0-9])|-)){,61}([a-z]|[0-9]))?)+\#(([a-z]|[0-9]))+([.\-](([a-z]|[0-9]))+)*|[a-z]([a-z]|[0-9])([.\-]?(([a-z]|[0-9]))+)+(\#(([a-z]|[0-9]))+([.\-](([a-z]|[0-9]))+)*)?)((/|/(([a-zA-Z]{2,3}(-[a-zA-Z]{3}(-[a-zA-Z]{3}){,2})?|[a-zA-Z]{4,8})(-[a-zA-Z]{4})?(-([a-zA-Z]{2}|[0-9]{3}))?(-(([a-zA-Z0-9]){5,8}|[0-9]([a-zA-Z0-9]){3}))*(-[0-9A-WY-Za-wy-z](-([a-zA-Z0-9]){2,8})+)*(-[xX](-([a-zA-Z0-9]){2,8})+)?|[xX](-([a-zA-Z0-9]){2,8})+|i-default|i-mingo))((/((([a-zA-Z]{2,3}(-[a-zA-Z]{3}(-[a-zA-Z]{3}){,2})?|[a-zA-Z]{4,8})(-[a-zA-Z]{4})?(-([a-zA-Z]{2}|[0-9]{3}))?(-(([a-zA-Z0-9]){5,8}|[0-9]([a-zA-Z0-9]){3}))*(-[0-9A-WY-Za-wy-z](-([a-zA-Z0-9]){2,8})+)*(-[xX](-([a-zA-Z0-9]){2,8})+)?|[xX](-([a-zA-Z0-9]){2,8})+|i-default|i-mingo)|\.([a-z]|[0-9])(((([a-z]|[0-9])|-)){,61}([a-z]|[0-9]))?(\.([a-z]|[0-9])(((([a-z]|[0-9])|-)){,61}([a-z]|[0-9]))?)+\#(([a-z]|[0-9]))+([.\-](([a-z]|[0-9]))+)*|\.(([a-z]|[0-9])(((([a-z]|[0-9])|-)){,61}([a-z]|[0-9]))?(\.([a-z]|[0-9])(((([a-z]|[0-9])|-)){,61}([a-z]|[0-9]))?)+|([a-z]|[0-9])(((([a-z]|[0-9])|-)){,61}([a-z]|[0-9]))?(\.([a-z]|[0-9])(((([a-z]|[0-9])|-)){,61}([a-z]|[0-9]))?)+\#(([a-z]|[0-9]))+([.\-](([a-z]|[0-9]))+)*)\$(([a-zA-Z]{2,3}(-[a-zA-Z]{3}(-[a-zA-Z]{3}){,2})?|[a-zA-Z]{4,8})(-[a-zA-Z]{4})?(-([a-zA-Z]{2}|[0-9]{3}))?(-(([a-zA-Z0-9]){5,8}|[0-9]([a-zA-Z0-9]){3}))*(-[0-9A-WY-Za-wy-z](-([a-zA-Z0-9]){2,8})+)*(-[xX](-([a-zA-Z0-9]){2,8})+)?|[xX](-([a-zA-Z0-9]){2,8})+|i-default|i-mingo)))+)?)?$' [type=string_pattern_mismatch, input_value=<NameSpace.X_INVALID: 'x_invalid'>, input_type=NameSpace]
EForfurtherinformationvisithttps://errors.pydantic.dev/2.11/v/string_pattern_mismatch
@ahouseholder I should clarify: my idea was (in the first place) to add them in the documentation as "reserved" namespaces for special purpose - similar how we did this with example, test and with x_example
I guess we should make those reserved namespaces more consistent in the ways they are defined - if I look at example, test vs. x_example I guess I think the latter is more clear in its appearance.
I'm afraid I've lost the plot here. Is this issue requesting a code change or just documentation? If documentation, what are we changing in which files?
The documentation with x_example alone pre-dates the "all x_ must have a # fragment" requirement we added later.
My experience in trying to add x_invalid to the registered enum makes me suspect that x_example will also fail for the same reason.
In the namespace documentation, we will say something like "The namespaces invalid and x_invalid are reserved" with some explanation that this reservation is provided for testing purposes only, and that these will not pass object validators.
I'll add an explicit reject to the namespace validator method to explicitly reject these two strings even though they match the ns pattern.
Activity
[-]Add registered namespace `invalid`[/-][+]Reserve registered namespace `invalid`[/+]tschmidtb51 commentedon Aug 25, 2025
This should also be done for the unregistered space (starts with
x_invalid.)SSVC
SSVC
ahouseholder commentedon Aug 26, 2025
I tried adding
x_invalidto the enumerated list, but it fails to validate against the NS pattern because it starts withx_but does not contain a fragment. So right now #915 only addsinvalid. (Which I understand is the point of it beinginvalid, but it breaks a unit test in a way that I can't investigate right now.tschmidtb51 commentedon Aug 26, 2025
@ahouseholder I should clarify: my idea was (in the first place) to add them in the documentation as "reserved" namespaces for special purpose - similar how we did this with
example,testand withx_exampleI guess we should make those reserved namespaces more consistent in the ways they are defined - if I look at
example,testvs.x_exampleI guess I think the latter is more clear in its appearance.ahouseholder commentedon Aug 27, 2025
I'm afraid I've lost the plot here. Is this issue requesting a code change or just documentation? If documentation, what are we changing in which files?
The documentation with
x_examplealone pre-dates the "allx_must have a#fragment" requirement we added later.My experience in trying to add
x_invalidto the registered enum makes me suspect thatx_examplewill also fail for the same reason.ahouseholder commentedon Sep 9, 2025
Okay, so my current understanding is as follows:
invalidandx_invalidare reserved" with some explanation that this reservation is provided for testing purposes only, and that these will not pass object validators.fix #907 add reserved ns warning to docs