@socketpair asked me about 3.5 LTS policy: https://github.com/aio-libs/aiohttp/pull/3568#issuecomment-457935889
I see the rule is not pronounced yet.
Let me fix this point of misunderstanding.
4.0. Please consider it as housekeeping release. The main point is to clean up the library to allow future awesome changes later.3.5 and master branches will diverge too much -- the support of 3.5 will be dropped.Thoughts? Comments? Proposals?
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. :smile:
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.
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.
+1 to drop Python 3.5 support.
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.
Ok.
Please could you give more details on the move from attrs to dataclasses?
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 :)
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'
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.
Python 3.5 support is dropped
Most helpful comment
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. :smile: