Add UUID generator incorporating dictionary entry keys #164
Conversation
Reviewed-by: Alex Nelson <alexander.nelson@nist.gov> Signed-off-by: Sheldon Douglas <sheldon.douglas@nist.gov>
sldouglas-nist
force-pushed
the
add_dictionary_entry_inherent_iri_generator
branch
from
f8d9851
to
972bf74
Compare
|
CI should finish before this merges. |
| @@ -96,6 +96,15 @@ | |||
| ) | |||
|
|
|||
|
|
|||
| def dictionary_entry_inherence_uuid( | |||
| uco_object_uuid_namespace: uuid.UUID, key_name: str, *args: Any, **kwargs: Any | |||
There was a problem hiding this comment.
Why accept *args and **kwargs if they're silently ignored?
There was a problem hiding this comment.
Fair point. These were my suggestion, so I'll field the question.
This addresses a syntax in Python's function definitions that frequently looks ambiguous to me, where a kind-of-positional spelling can be used at call time.
I've found it helpful to have at least *args always, as a reminder that there's a point in the argument list where the arguments are no longer positional. If it comes at the end, great! All arguments are positional. **kwargs tends to come along as a matter of habit - if there's *args, I tend to want **kwargs as well.
I also include *args and **kwargs in class methods when I know subclasses are going to override the implementations, or use super().
So, by two habits, I use *args and **kwargs in function definitions, and I suggested those to @sldouglas-nist .
|
It looks like a part of the build system post-tests needs fixing. FWIW, it seems out of scope of the changes in this PR, so I think it would be fine to merge this PR, but I'm also fine waiting for CI to pass with another PR merged into |
No description provided.