#27 Add support for python 3.6 #30
Conversation
Changes: - Update config and docs to reference 3.6 - Add backports of dataclasses and datetime.fromisoformat for python_version<"3.7" - Support both 3.7 and 3.6 usages of undocumented __origin__ attribute on typing objects - Make github ci run tests for python 3.6 as well
|
In the build job py-37, it appears that the virtualenv created uses cpython 3.6.9... That doesn't seem right. Must be some environment reuse going on, or caching. Build job: https://github.com/danielgtaylor/python-betterproto/runs/558815488 |
|
@cetanu How odd, it seems pipenv doesn't acknowledge the good work of the setup-python workflow by default. I pushed a fix, so now you can see pytest reports that it is using the expected python. |
|
Looks good, thanks for submitting this ❤️ |
|
Just curious, is there any deprecation schedule planned for Python versions, something like this? |
I'm not aware of plans regarding that. Personally, I think the project is still in a very early stage to make formal commitments towards long-term support. I'd like to first get towards a stable version where the most common use cases work well, bug free. Our current commitment is that it works, and we're still not there ;-) But I think it's good to have this on our radar and that you bring it up. How many versions we can support also depends on the number of contributors, and how much we like to prioritize stability and long term support versus cranking out features. In the end if someone wants to backport it to 3.5, they are also welcome, so it all depends on us :-) To get more to the point, I would like to keep supporting 3.6 going forward. I can't imagine good reasons to drop support other than a lack of capacity. We can build everything with just python 3.6 features, and anything that is intrinsically tied to new language features won't be of use to 3.6 users, so we can just omit those features for 3.6. |
@adriangb @boukeversteegh I'd say it makes sense as a default policy to officially support the officially supported versions of python. This implies maintaining 3.6 support till the end of 2021. |
|
That's one way to do it, but that's quite a long time to wait to use 3.7
only features (I'm specifically thinking of postponed annotation
evaluation)! I linked the numpy doc because that's the way the entire
PyData ecosystem does deprecation, it's a bit of a shorter timeframe.
…On Sat, Jul 18, 2020, 1:11 PM nat ***@***.***> wrote:
Just curious, is there any deprecation schedule planned for Python
versions, something like this
<https://github.com/numpy/numpy/blob/master/doc/neps/nep-0029-deprecation_policy.rst>
?
@adriangb <https://github.com/adriangb> @boukeversteegh
<https://github.com/boukeversteegh> I'd say it makes sense as a default
policy to officially support the officially supported versions of python.
This implies maintaining 3.6 support till the end of 2021
<https://devguide.python.org/#status-of-python-branches>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#30 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANMPP2MNNPHM2YCQQ4ZO43R4HQVTANCNFSM4L4IXF6A>
.
|
That's sounds like a reasonable timeframe. I would be ok with following official python. |
|
@adriangb yes, that might take a long time... But, to clarify, if we can make the experience for 3.7+ better, without breaking compatibility with 3.6, we can do that of course. For the generated code, we would have quite some flexibility (in theory at least), in the sense that if users would like to generate code that is only compatible with 3.8 because they use advanced features, that is still Ok for betterproto, as long as the library can still work with 3.6 and it is possible to generate 3.6 compatible code. You mentioned late evaluated annotations, or the like. That sounds interesting. How would you apply that feature in betterproto? |
|
Super easy! See [PEP-563](https://www.python.org/dev/peps/pep-0563/)
```python3
a: "MyClass"
class MyClass:
pass
```
Becomes
```python3
from __future__ import annotations
a: MyClass
class MyClass:
pass
```
|
I'm not familiar with the feature of postponed evaluation. I meant to say, could you explain the benefit of it, and in what part of betterproto we could use it? Like, what possibility would it open up for the library. Improved performance or something else? |
|
It just means that you don't have to quote your annotations with strings, which leads to better linting and IDE integration. It basically means that the annotations work just like classes where you can use it before it's defined. |
#27
Changes: