-
Notifications
You must be signed in to change notification settings - Fork 651
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
Ensure the API returns right value types #307
Conversation
Signed-off-by: Alex Boten <aboten@lightstep.com>
Signed-off-by: Alex Boten <aboten@lightstep.com>
Codecov Report
@@ Coverage Diff @@
## master #307 +/- ##
==========================================
- Coverage 86.05% 85.88% -0.17%
==========================================
Files 33 33
Lines 1628 1630 +2
Branches 182 182
==========================================
- Hits 1401 1400 -1
- Misses 181 182 +1
- Partials 46 48 +2
Continue to review full report at Codecov.
|
I think the |
Signed-off-by: Alex Boten <aboten@lightstep.com>
Good idea! I added the remainder of the strict flags into |
Is assigning default values for every argument part of the "strictness"? |
It is |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two blocking comments, but this looks good otherwise. It's encouraging that you got --strict
to work with so few changes.
Something to think about: since type checks aren't enforced at run time, using non-null default values for args that can't meaningfully be null means we either have to (1) explicitly handle nulls or (2) decide not to handle them and leave it up to the user to deal with the inevitable TypeError
s, AttributeError
s and etc. This isn't to say this isn't the right approach, just that we have to deal with a different set of problems than we do for null default values.
@@ -145,7 +145,7 @@ class SpanKind(enum.Enum): | |||
class Span: | |||
"""A span represents a single operation within a trace.""" | |||
|
|||
def end(self, end_time: int = None) -> None: | |||
def end(self, end_time: int = 0) -> None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
0
already has a well-defined meaning: even if we don't expect users to want to end spans on the unix epoch, I don't think the API should prohibit it. Optional/none seems like a better default here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call. Updated to Optional[int]
, I updated the SDK as well
@@ -174,7 +176,7 @@ def add_event( | |||
self, | |||
name: str, | |||
attributes: types.Attributes = None, | |||
timestamp: int = None, | |||
timestamp: int = 0, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment about the epoch here.
opentelemetry-api/tests/test_app.py
Outdated
from opentelemetry import metrics, trace | ||
|
||
|
||
class TestAppWithAPI(unittest.TestCase): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test looks great, but might be hard to understand out of context. An explanation in the test or module docstring and reference to the other test in each file would help, especially since we'll need to keep these in sync with each other.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a comment to help clarify it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer having that comment as the docstring for the test class instead of the test module, since I routinely skip until after the import statements when reading a file. But that's just my personal preference.
Signed-off-by: Alex Boten <aboten@lightstep.com>
Signed-off-by: Alex Boten <aboten@lightstep.com>
Signed-off-by: Alex Boten <aboten@lightstep.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks basically good to me, but I find the test class names confusing.
opentelemetry-api/tests/test_app.py
Outdated
from opentelemetry import metrics, trace | ||
|
||
|
||
class TestAppWithAPI(unittest.TestCase): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer having that comment as the docstring for the test class instead of the test module, since I routinely skip until after the import statements when reading a file. But that's just my personal preference.
opentelemetry-api/tests/test_app.py
Outdated
from opentelemetry import metrics, trace | ||
|
||
|
||
class TestAppWithAPI(unittest.TestCase): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this called TestAppWithAPI
? From that name I had expected it to run the example app (which would actually be nice too). I suggest the name TestAPIOnlyImplementation
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the suggestion, it's much clearer. I've renamed the files to test_implementation as well.
opentelemetry-sdk/tests/test_app.py
Outdated
from opentelemetry.trace import INVALID_SPAN, INVALID_SPAN_CONTEXT | ||
|
||
|
||
class TestAppWithSDK(unittest.TestCase): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now I'm confused. Why is there App
in the name again? And aren't these already covered by other unit tests?
Signed-off-by: Alex Boten <aboten@lightstep.com>
https://github.com/open-telemetry/opentelemetry-python/issues/142 | ||
""" | ||
|
||
def test_tracer(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice!
closes open-telemetry#307 Signed-off-by: Olivier Albertini <olivier.albertini@montreal.ca>
Fixes #142
Enabling
--strict
mode for mypy. Added a test in the sdk and the same test in the api to test the different behaviours between the Tracer, Span and Metric classes.Signed-off-by: Alex Boten aboten@lightstep.com