ENH: pyvo.registry.regtap.RegistryResource.access_modes to return sorted set

[bsipocz]

Follow-up for #289: having a deterministic order would be nice.

See: scientific-python/pytest-doctestplus#182

[msdemlei]

[Sent this in by mail on 2022-06-02; not sure why it didn't make it here]

I see... on the other hand, the set this function returns right now is a very appropriate representation to what this is: A set of ways a service can be accessed. Being frank here is relevant because, for instance, it clearly states that there are never duplicates in what is returned (where a resource may have multiple capabilities with the same standardID).

And of course the natural operation on the result is asking "is there a TAP service in here?", whereas "what's the position of the TAP service?" is utterly meaningless.

Making things easily testable is one thing, but we shouldn't forsake appropriate data structures for that; pllim's argument over at the doctestplus bug would mean set-returning functions are out, which seems wrong to me (but then I give them it's not entriely trivial to fix given the way doctests work; perhaps they should have a

  +PARSE_USING: set({})

modifier that would let you say "compare stuff not after serialisation, but de-serialise the result literal and compare then"?).

If this were a normal doctest, I'd fix it by writing list(sorted(res.access_modes())).

That, however, is not an option for actual documentation, as that would defeat its purpose (at least here).

Frankly: I'd say the +IGNORE_OUTPUT feels really rational to me here.

[bsipocz]

Yes, I feel you're right. There are a few shortcomings of the doctesting, I will raise it with others as this may be a limitation for other packages, too.

[msdemlei]

On Wed, Jun 01, 2022 at 12:27:16PM -0700, Brigitta Sipőcz wrote: Having a deterministic order would be nice. See: scientific-python/pytest-doctestplus#182

I see... on the other hand, the set this function returns right now is a very appropriate representation to what this is: A *set* of ways a service can be accessed. Being frank here is relevant because, for instance, it clearly states that there are never duplicates in what is returned (where a resource may have multiple capabilities with the same standardID). And of course the natural operation on the result is asking "is there a TAP service in here?", whereas "what's the position of the TAP service?" is utterly meaningless. Making things easily testable is one thing, but we shouldn't forsake appropriate data structures for that; pllim's argument over at the doctestplus bug would mean set-returning functions are out, which seems wrong to me (but then I give them it's not entriely trivial to fix given the way doctests work; perhaps they should have a +PARSE_USING: set({}) modifier that would let you say "compare stuff not after serialisation, but de-serialise the result literal and compare then"?). If this were a normal doctest, I'd fix it by writing list(sorted(res.access_modes())). That, however, is not an option for actual documentation, as that would defeat its purpose (at least here). Frankly: I'd say the +IGNORE_OUTPUT feels really rational to me here.