aiohttp 3.0 release

[asvetlov]

I'd like to name the next release 3.0
3.0 means the major.

Let's drop Python 3.4 and use async/await everywhere.
Another important question is what 3.5 release to cut off?

Honestly I want to support 3.5.3+ only: the release fixes well known ugly bug for asyncio.get_event_loop().
Debian stable has shipped with Python 3.5.3, not sure about RHEL.
All other distributions with faster release cycle support 3.5.3 too at least or event 3.6.

The transition should not be done at once.

1. Let's pin minimal required Python version first in setup.py.
2. Translate test suite to use async/await.
3. Modify aiohttp itself to use new syntax.

Every bullet except number one could be done in a long series of PRs, part by part.

BTW at the end I hope to get minor performance increase :)

[samuelcolvin]

async/await everywhere. 🍾 🎆

[kxepal]

I think at 3.0 time it would better to drop even 3.5 support.

[fafhrd91]

+1

We should drop all depredations. Convert write method for response and send method for websockets to real coroutines

[fafhrd91]

@kxepal what we can simplify by dropping 3.5?

[samuelcolvin]

@kxepal what we can simplify by dropping 3.5?

• async generators are way simpler with just 3.6
• f-strings can make formatted strings much cleaner
• less confusion about which patch of 3.5 is support and which not. Simply ">=3.6".

The show stopper I guess is Debian, I don't know when it will upgrade to 3.6.

[asvetlov]

We should drop all deprecations. Convert write method for response and send method for websockets to real coroutines

+100. But let's be careful about dropping everything. Let's look on every deprecation one by one.
Sure, we have a deprecation warning for old-styled middlewares for example.
Removing the support for these middlewares just in two months after introduction is too rude.

[samuelcolvin]

on old middleware: I agree with have to keep it for longer.

[kxepal]

@samuelcolvin
I wonder if we should count one of Linux distributive as stopper for us. So far, we don't target to any specific Linux distro support AFAIK.

[asvetlov]

@samuelcolvin @kxepal I would love to drop 3.5 at all but one of our major downstreams is https://home-assistant.io/
@balloob asked me to keep 3.4 support until RaspberryPi will have 3.5 in batteries by default.
They are depending from Debian. I hope it's done.

aiohttp 2.3 was waiting for a long (we had security issues etc.), I hope to release 3.0 at the end of the year.

[kxepal]

@asvetlov
How about keep 2.3.x release with 3.4 and 3.5 support while drop them for 3.0? IIRC we had some LTS policy for such cases.

I fear that trying to satisfy everyone will keep us slow in adapting new features.

[fafhrd91]

@asvetlov
I am talking about deprecations that was introduced <= 2.0, sure deprecation from 2.3 we should keep.

@kxepal
3.5 does not make code backward incompatible like 3.4,
we still can implement async generators, they are just not supported by 3.5

-1 for dropping 3.5

[fafhrd91]

big -1 for splitting release branches.

[jettify]

Since 3.7 coming soon 3.5.3+ sound reasonable, but dropping 3.5 altogether might be very problematic for home-assistant.io people.

[kxepal]

Ok, not today, 3.5, not today (:

P.S. May be offtopic, but why it's so problematic for home-asistant.io to move to 3.6?