Fix and improve tests for Python != 3.7#95
Conversation
| - '3.6' | ||
| - '3.7' | ||
| - 'pypy3.5' | ||
| - '3.8-dev' |
There was a problem hiding this comment.
Nice. However, we really don't need to have 3.8-dev, and specially the nightly one, IHMO (even with the allow_failures flag) ;)
There was a problem hiding this comment.
I don't think there's any benefit IHMO. dev can change relatively a lot. I don't think there's any value in having it here honestly (unless we were married to some internal or prototype feature of it).
Anyway, I wouldn't totally be against this, so I will leave others give their opinion ;)
There was a problem hiding this comment.
Python 3.8 is almost there, so it makes sense to have tests for it.
In addition, I believe that it's always better to know about any incompatibilities sooner rather than later.
Especially if running the tests costs nothing.
There was a problem hiding this comment.
It does make builds slower. But I have no strong opinion on dev either. I also believe that nightly is too much, things can still change there so if we fix an error in nightly and then nightly changes to make the fix unnecessary, we wasted time.
There was a problem hiding this comment.
Hi @carlosalberto and @Oberon00,
I've removed nightly for now.
|
Hi @Jamim thanks for your PR! 🎉 Python 3.4 has reached end of life and I would imagine OpenTelemetry would not add support for this version of Python since this software will be released after the end-of-life. That being said, ultimately the maintainers have control over the project direction regarding Python 3.4 😄 |
|
|
||
| from contextlib import contextmanager | ||
| import typing | ||
| from typing import Callable |
There was a problem hiding this comment.
IIRC we decided to import modules, i.e. typing, rather than importing individual members (not sure we documented it anywhere, btw).
There was a problem hiding this comment.
Please reconsider this.
_TRACER_FACTORY: typing.Optional[
typing.Callable[[typing.Type[Tracer]], typing.Optional[Tracer]]] = Nonelooks really terrible.
There was a problem hiding this comment.
One could also argue the same with importing a different class per line ;) I've never liked this in Java, for example. You can also always put each parameter in a new line. Oh well, a matter of taste, I guess.
Maybe @reyang happens to remember whether we had some style guidelines?
There was a problem hiding this comment.
One could also argue the same with importing a different class per line ;)
We have to say "thank you" to isort for that.
There was a problem hiding this comment.
I'd like to propose to change preferences for isort to make imports less ugly.
There was a problem hiding this comment.
This was documented in #36. I'm not entirely sure but if isort doesn't complain it should be fine? My opinion was that we definitely must not have from x import y with the same x multiple times (like this does), and we definitely must not have an import x, y (multiple modules in the same import). If we want to discuss other aspects, we should not do this here but reopen #36 or create a new issue. I agree that both possibilities that isort allows now are suboptimal (multiple from import for the same module is something I definitely don't want though).
|
Hello @a-feld, Thank you for the feedback. |
I'm wondering about this too. Initially we decided to support this, but I started having second thoughts on this ;) Worth discussing it again in #25 (and maybe in the SIG this Thursday as well). |
| self.assertEqual(value, b"*") | ||
| except StopIteration: | ||
| self.span_context_manager.__exit__.assert_called() | ||
| self.span_context_manager.__exit__.assert_called_with( |
There was a problem hiding this comment.
Too bad we need this change. 🙁 Which Python version requires it?
There was a problem hiding this comment.
We need it for 3.5 and 3.4.
The assert_called method was introduced in 3.6.
|
|
||
| from contextlib import contextmanager | ||
| import typing | ||
| from typing import Callable |
There was a problem hiding this comment.
This was documented in #36. I'm not entirely sure but if isort doesn't complain it should be fine? My opinion was that we definitely must not have from x import y with the same x multiple times (like this does), and we definitely must not have an import x, y (multiple modules in the same import). If we want to discuss other aspects, we should not do this here but reopen #36 or create a new issue. I agree that both possibilities that isort allows now are suboptimal (multiple from import for the same module is something I definitely don't want though).
|
|
||
|
|
||
| Context: typing.Optional[BaseRuntimeContext] | ||
| Context = ( # pylint: disable=invalid-name |
There was a problem hiding this comment.
This makes me wonder if we shouldn't relax the pylint rule for "constants" (maybe even to .*) since there are so many things it demands UPPER_CASE for which are not really constants. Then this could be a single line without the awkward parens.
|
@Jamim thank you for taking care of this! 🎉 |
|
|
|
Hello @carlosalberto and @Oberon00, |
|
@carlosalberto I can extract b05f347 and c9821ec into a separate PR. |
|
LGTM now, but the style changes need further discussion (though I like them personally). So splitting this up is probably for the best. |
|
Hello @carlosalberto and @Oberon00, I've excluded b05f347 and c9821ec for now. Thanks! |
|
The only thing that keeps me from approving now is the long list of |
I believe it would be nice to have tests on CI not only for Python 3.7, but for all supported Python versions. These changes: - fix compatibility with Python 3.5 and 3.4 - add tests for various Python versions on CI - allow running tests for any branches
It's done. |
Oberon00
left a comment
There was a problem hiding this comment.
LGTM. Several questions were spawned by this PR (Python 3.4 support, import style, pylint constant naming rule) but they can be discussed independently later.
|
Hello @carlosalberto, |
|
@Jamim remind me ;) (it's approved now) |
|
Hi everyone, |
|
Done! Thx for the reminder! |
These changes follow up the "Fix and improve tests for Python != 3.7" PR. The multi_line_output was already set to 3 in the "Add initial black formatting" PR, so after rebasing to master this commit contains only comment that describes a magic number from the isort configuration file. Corresponding PR: - open-telemetry#109 Related discussions: - open-telemetry#95 (comment) - open-telemetry#95 (comment)
These changes follow up the "Fix and improve tests for Python != 3.7" PR. The multi_line_output was already set to 3 in the "Add initial black formatting" PR, so after rebasing to master this commit contains only comment that describes a magic number from the isort configuration file. Corresponding PR: - #109 Related discussions: - #95 (comment) - #95 (comment)
These changes follow up the "Fix and improve tests for Python != 3.7" PR. The multi_line_output was already set to 3 in the "Add initial black formatting" PR, so after rebasing to master this commit contains only comment that describes a magic number from the isort configuration file. Corresponding PR: - open-telemetry/opentelemetry-python#109 Related discussions: - open-telemetry/opentelemetry-python#95 (comment) - open-telemetry/opentelemetry-python#95 (comment)
Hello everyone,
I believe it would be nice to have tests on CI not only for Python 3.7, but for all supported Python versions.
These changes:
fix(already fixed by Fix test failures involving contextvars. #96)test_span_memberstestrelax the(moved to Relax the pylint rule for constants #108)pylintrule for constantsupdate(moved to Describe isort's multi_line_output setting #109)isortsettingsCheers!