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

Initial implementation of context #57

Merged
merged 20 commits into from
Jul 27, 2019
Merged

Initial implementation of context #57

merged 20 commits into from
Jul 27, 2019

Conversation

reyang
Copy link
Member

@reyang reyang commented Jul 18, 2019

This is based on the work in opencensus-context.

@reyang reyang added the WIP Work in progress label Jul 18, 2019
@c24t c24t mentioned this pull request Jul 18, 2019
@c24t
Copy link
Member

c24t commented Jul 18, 2019

Some questions about the context. These might have easy answers, I just don't know them:

Do we need a context API instead of using contextvars directly? What are the consequences if we use the contextvars backport on python < 3.6?

Do we expect implementations to override BaseRuntimeContext (or are these classes only in the API because we need them in the default tracer implementation that ships with the API)? Should users expect to be able to swap out context implementations the way they can SDKs?

@c24t
Copy link
Member

c24t commented Jul 18, 2019

IMHO the point of adding type annotations to API code is to make implementers' lives easy and give them the option to do type checking. The annotations here don't do much to describe the behavior of the class, add a lot of boilerplate code, and (at least in my experience) add significant friction while writing the code.

reyang pushed a commit that referenced this pull request Jul 19, 2019
slot = self._slots[name]
slot.set(value)

def with_current_context(
Copy link
Member

Choose a reason for hiding this comment

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

would there be value in exposing a contextmanager like this as well?

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't know at this moment. I'm open to add it if we find it helpful.

@reyang
Copy link
Member Author

reyang commented Jul 25, 2019

Do we need a context API instead of using contextvars directly? What are the consequences if we use the contextvars backport on python < 3.6?

Yes for now, although our direction is to use contextvars in the future.
There are three reasons:

  1. We support Python 3.4 currently, which doesn't have contextvars.
  2. We want to work with frameworks which haven't moved to contextvars yet, examples are tornado and gevent.
  3. We need some utility functions for across thread/multiprocessing propagation.

Do we expect implementations to override BaseRuntimeContext (or are these classes only in the API because we need them in the default tracer implementation that ships with the API)? Should users expect to be able to swap out context implementations the way they can SDKs?

There will be cases like this, for example https://github.com/census-instrumentation/opencensus-python/tree/master/contrib/opencensus-ext-gevent.


# user can propagate context explicitly
thread = Thread(
target=Context.with_current_context(work),
Copy link
Member

Choose a reason for hiding this comment

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

this helps clear up the value of with_current_context. Nice!

I feel like the need to add with_current_context will probably be a gotcha in many cases. It's too bad there isn't a way to make this something that is implicitly shared.

Copy link
Member Author

Choose a reason for hiding this comment

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

When the day comes that contextvars or some built-in Python lib support such scenario, we can say goodbye to this Context class and never need to reinvent wheels again :)

@reyang reyang removed the WIP Work in progress label Jul 26, 2019

from opentelemetry.context import Context

class Span(object):
Copy link
Member Author

Choose a reason for hiding this comment

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

@c24t this should unblock your work on the actual span creation and tracer context update.

self.parent,
))

async def __aenter__(self):
Copy link
Member Author

Choose a reason for hiding this comment

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

This example only works on Python3.7+ due to the new async/await syntax.
We can explore more in #62.

Copy link
Member

@c24t c24t left a comment

Choose a reason for hiding this comment

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

LGTM!

def call_with_current_context(
*args: 'object',
**kwargs: 'object',
) -> 'object':
Copy link
Member

Choose a reason for hiding this comment

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

Since we don't expect users to bring their own context impl (as we do with trace and metrics) I think it's fine to lose the type annotations in this module, especially when they're this useless.


if __name__ == '__main__':
asyncio.run(main())
"""
Copy link
Member

Choose a reason for hiding this comment

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

How about adding this module to the sphinx docs?

Copy link
Member Author

Choose a reason for hiding this comment

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

Sure, I'll send a follow up PR to add test cases and docs.

@reyang reyang merged commit 7c5e018 into master Jul 27, 2019
@reyang reyang deleted the context branch July 27, 2019 03:06
@c24t c24t mentioned this pull request Jan 16, 2020
srikanthccv pushed a commit to srikanthccv/opentelemetry-python that referenced this pull request Nov 1, 2020
* Add TraceState

* Fix review comments

* Minor Fix, add TODOs

* Use Map to preserve ordering

* Add underscore for private methods & rename variable

- Give more descriptive name than `s` to variable.
- Private properties prefixed with an underscore for JavaScript users.
- Private methods prefixed with an underscore for JavaScript users.

* Remove TEST_ONLY methods

* Add comment about TraceState class

* Add unset method
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.

3 participants