Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: content overload signatures #290

Merged
merged 3 commits into from
Sep 13, 2024
Merged

fix: content overload signatures #290

merged 3 commits into from
Sep 13, 2024

Conversation

tdstein
Copy link
Collaborator

@tdstein tdstein commented Sep 13, 2024

Simplifies or, in most cases, corrects the overload signature. Variable names and documentation are updated along the way.

  • Renames kwargs based on context. The variable name conditions is introduced for querying methods. The variable name attributes is introduced for record manipulation. This also signifies that this is not a passthrough method.
  • Documentation is updated to reflect the current state of Posit Connect.
  • Removes deprecations for field names in integration tests.

Resolves #140

Copy link

github-actions bot commented Sep 13, 2024

☂️ Python Coverage

current status: ✅

Overall Coverage

Lines Covered Coverage Threshold Status
1101 1055 96% 0% 🟢

New Files

No new covered files...

Modified Files

File Coverage Status
src/posit/connect/content.py 100% 🟢
TOTAL 100% 🟢

updated for commit: 63c4851 by action🐍

@@ -23,7 +23,7 @@ def test_count(self):
assert self.client.content.count() == 1

def test_get(self):
assert self.client.content.get(self.content.guid) == self.content
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm reaching the edge of my python knowledge here so maybe this is a dumb question but is .guid now a deprecated syntax and did that happen in this PR?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's self-imposed. See #262

We are moving away from attribute-based access for object data.

@tdstein tdstein mentioned this pull request Sep 13, 2024
body = dict(*args, **kwargs)
url = self.params.url + f"v1/content/{self.guid}"
response = self.params.session.patch(url, json=body)
def update(self, **attributes: Any) -> None:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ahh, I love this - definitely much easier to understand what's going on.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🙌🏻

response = self.params.session.patch(url, json=body)
def update(self, **attributes: Any) -> None:
"""Update the content."""
url = self.params.url + f"v1/content/{self['guid']}"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure how to weigh pros / cons here, just an observation - when I'm interacting with an SDK resource, my LSP would give me autocomplete on the deprecated property fields, which I don't get using the new approach. Its harder to explore what fields are available on the resource, or in some cases know where to look at all for that information if it isn't in a docstring.

Its also easier for the LSP to catch typos on properties - if I were to typo a dict key, I would get a more confusing error.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good callout. That is a big downside to this approach and the main reason we tried using attributes originally. I have experimented with defining a TypedDict and then holding data in an internal attribute instead of on self. I abandoned it due to the complexity of maintaining the facade between the internal state and self. I'm open to revisiting it, though.

The other answer is... you always have that problem when using dictionaries in Python. So this isn't anything new 🙃

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, it might just be a matter of making sure we're good with our documentation of resources so we can easily check what's in them.

@tdstein tdstein merged commit c4e761e into main Sep 13, 2024
32 checks passed
@tdstein tdstein deleted the tdstein/overrides branch September 13, 2024 18:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Better docstrings for content.update
3 participants