Add OpenTracing propagator

[ocelotl]

Description

Adds propagator for OpenTracing.

Fixes #294

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Test A

Does This PR Require a Core Repo Change?

• Yes. - Link to PR:
• No.

Checklist:

See contributing.md for styleguide, changelog guidelines, and more.

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[codeboten]

Looks good, just a few minor suggestions

[codeboten]

@ocelotl can you add an entrypoint for the ottrace propagator: https://github.com/open-telemetry/opentelemetry-python/blob/59fc285333041f3dc45a1c82563f531711bf63a5/propagator/opentelemetry-propagator-b3/setup.cfg#L51-L53

See the spec here: open-telemetry/opentelemetry-specification@2f63e91?short_path=adf3b6d#diff-adf3b6d20af39e3109b1907f4b1f356e90912b893693a308955dea13dd97612f

[ocelotl]

@ocelotl can you add an entrypoint for the ottrace propagator: https://github.com/open-telemetry/opentelemetry-python/blob/59fc285333041f3dc45a1c82563f531711bf63a5/propagator/opentelemetry-propagator-b3/setup.cfg#L51-L53

See the spec here: open-telemetry/opentelemetry-specification@2f63e91?short_path=adf3b6d#diff-adf3b6d20af39e3109b1907f4b1f356e90912b893693a308955dea13dd97612f

Sure, adding entry point...

[aabmass]

nit CONSTANT_CASE

[ocelotl]

Sorry, what is the issue here?

[aabmass]

just a nit, if these are constants consider _valid_header_name -> _VALID_HEADER_NAME

[ocelotl]

PEP8 says that is how constants should be cased. AFAIK, constants are only True, False, None, strings, and numerical values.

[aabmass]

Some compiled regexes in constant case here as well https://github.com/open-telemetry/opentelemetry-python/blob/0fe1f476a05bfa055a868d8433488a785bb65cdc/opentelemetry-api/src/opentelemetry/util/tracestate.py#L49-L52

I believe the purpose of this casing is to indicate the variable is a constant and shouldn't be modified, which is the intention here. int, float, bool, string, etc. aren't special in python, they are just classes right?

[ocelotl]

Some compiled regexes in constant case here as well https://github.com/open-telemetry/opentelemetry-python/blob/0fe1f476a05bfa055a868d8433488a785bb65cdc/opentelemetry-api/src/opentelemetry/util/tracestate.py#L49-L52

Yeah..., we should also fix those 😅

I believe the purpose of this casing is to indicate the variable is a constant and shouldn't be modified, which is the intention here. int, float, bool, string, etc. aren't special in python, they are just classes right?

Hmnot really. int, float, bool, None, strings are special, because they are actually constants and they are created only once. This can be checked like this:

ocelotl@harrison:~$ python
Python 3.8.3 (default, Jun 29 2020, 18:03:36) 
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> a = 1
>>> b = 1
>>> id(a)
93987911005952
>>> id(b)
93987911005952
>>> a is b
True
>>> a = "a"
>>> b = "a"
>>> id(a)
140646739870512
>>> id(b)
140646739870512
>>> a is b
True
>>> a = None
>>> b = None
>>> id(a)
93987910826592
>>> id(b)
93987910826592
>>> a is b
True
>>> 

As it can be seen here, any variable assigned to the same int will "point" to the same object, ints are true constants in that sense, they will not change during the program execution.

The same does not happen for other objects:

ocelotl@harrison:~$ python
Python 3.8.3 (default, Jun 29 2020, 18:03:36) 
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> class Test:
...     pass
... 
>>> a = Test()
>>> b = Test()
>>> id(a)
139882366030992
>>> id(b)
139882366749904
>>> a is b
False
>>> 

Now, let's try with compiled regular expressions:

ocelotl@harrison:~$ python
fPython 3.8.3 (default, Jun 29 2020, 18:03:36) 
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from re import compile as re_compile
>>> a = re_compile(r"abc")
>>> b = re_compile(r"abc")
>>> id(a)
140532296161216
>>> id(b)
140532296161216
>>> a is b
True
>>> 

Now, this looks like compiled regular expressions are indeed constants the same as ints are, but that is just an illusion caused by an implementation detail. The re module uses an artificial cache as an optimization to keep there already compiled regular expressions. That cache has a limit so at some moment even compiled regular expressions may be compiled again for the exact same pattern and flags. Now, I am getting just pretty pedantic here with the definition of a constant, 😅 but I wanted to explain why compiled regular expressions are not constants in the most strict sense.

[aabmass]

LGTM

[lzchen]

Question about version number.