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

aiohttp 3.5 support #3588

Closed
asvetlov opened this issue Jan 30, 2019 · 10 comments
Closed

aiohttp 3.5 support #3588

asvetlov opened this issue Jan 30, 2019 · 10 comments
Labels

Comments

@asvetlov
Copy link
Member

asvetlov commented Jan 30, 2019

@socketpair asked me about 3.5 LTS policy: #3568 (comment)

I see the rule is not pronounced yet.
Let me fix this point of misunderstanding.

  1. aiohttp 4.0 is the next major release.
  2. Major means a great chance to get rid of the deprecated code. Drop something, convert soft deprecation warning into strict exceptions etc. New features are welcome but don't expect too much from 4.0. Please consider it as housekeeping release. The main point is to clean up the library to allow future awesome changes later.
  3. I will do backporting bugfix Pull Requests from master to 3.5 branch if the backport can land without merge conflicts or the conflicts are resolved easy.
  4. aiohttp 3.5 is not LTS release in terms of commitment to support it in 3-5 years. When 3.5 and master branches will diverge too much -- the support of 3.5 will be dropped.

Thoughts? Comments? Proposals?

@asvetlov asvetlov added the meta label Jan 30, 2019
@aio-libs aio-libs deleted a comment from aio-libs-bot Jan 30, 2019
@samuelcolvin
Copy link
Member

Personally, I'm pro dropping support for python 3.5.

Maybe elegant, maybe very confusing that aiohttp==3.5 is the last version that supports python 3.5. 😄

@samuelcolvin
Copy link
Member

Also, if we dropped 3.5, we could swap from using attr to dataclasses (via a backport for 3.6).

If we wanted strict type checks we could use pydantic.dataclasses (admission: I built pydantic, so I'm biased). But I'm not sure that's necessary.

attr does some pretty crazy things with compile and exec and I suspect is fairly slow, thus slowing down aiohttp loading.

dataclasses are the pythonic way to do, are much faster and should play nicely with type hinting.

I'd be happy to do this work if agreed.

@socketpair
Copy link
Contributor

I vote FOR removal.

Build system must check Python version for those who will try to build new aiohttp using old Python.

Also I vote for removal of different obsolete wrappers not connected with Python > 3.5.

@kxepal
Copy link
Member

kxepal commented Feb 1, 2019

+1 to drop Python 3.5 support.

@asvetlov
Copy link
Member Author

asvetlov commented Feb 1, 2019

I see problems with attr -> dataclasses smooth migration.
The API is similar but slightly different.
User code will be broken hard.

Regarding Python 3.5 drop: Debian Stretch is shipped with Python 3.5.
Debian Buster will have 3.7 but the release date is not scheduled yet. It will be at mid-2019.
On other hands, preparing to aiohttp 4.0 will take a while anyway. I want to keep 3.5 maintenance and work on new (maybe non-compatible) features.

Perhaps I have to post my wishlist on the tracker. I'm on a business trip now and have very limited capacity for this month.
Also, I have a commitment to implement several features for Python 3.8, which is scheduled already,
everything should be done before 3.8-beta (feature freeze).

That's why I cannot spend too much time on aiohttp right now, unfortunately. I don't give up but have a limited capacity. It can shift aiohttp 4.0 release date.

@samuelcolvin
Copy link
Member

Ok.

Please could you give more details on the move from attrs to dataclasses?

@asvetlov
Copy link
Member Author

asvetlov commented Feb 1, 2019

attr.field() and other introspection functions don't work with dataclasses, obviously.
The type is different, it can break type checkers etc.
We can live with these problems may be (but I predict that somebody will start crying and blaming).
Moreover, attr.evolve() should be replaced with dataclasses.replace().

BTW, dataclasses calls exec() internally as well: https://github.com/python/cpython/blob/master/Lib/dataclasses.py#L386 :)

@lphuberdeau
Copy link
Contributor

I don't know if a decision was made on dropping python 3.5 support, but it seems like it effectively is dropped in aiohttp==3.5.4

    from aiohttp import web
  File "/usr/local/lib/python3.5/dist-packages/aiohttp/__init__.py", line 6, in <module>
    from .client import (
  File "/usr/local/lib/python3.5/dist-packages/aiohttp/client.py", line 12, in <module>
    from typing import (  # noqa
ImportError: cannot import name 'Coroutine'

@asvetlov
Copy link
Member Author

aiohttp 3.x requires Python 3.5.3+
Please check your python version.
Moreover, please check pip version as well, looks like you have a very obsolete one.
A new pip (18.0+ at least) respects python version spec, aiohttp provides correct metadata for this value.

leoluk referenced this issue in b-harvest/terra_oracle_voter_deprecated Mar 16, 2020
@asvetlov
Copy link
Member Author

Python 3.5 support is dropped

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants