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?

[jettify]

As far as I can tell home-asistant.io app runs on ruspberipi, and used by bunch of regular hobbyists, not software engineers. Having prepared by debian python environment simplify a lot of things for them.

[balloob]

Home Assistant has just announced that we're deprecating Python 3.4 support. We are planning to drop support for it in the beginning of 2018.

-1 for dropping Python 3.5 here too. I think that following Debian stable is a good guideline.

[eteamin]

I would love to contribute. Starting right now.

[eteamin]

would you consider creating a new branch for PRs?

[asvetlov]

@eteamin no new branch is needed, just make a PR against master.
I've created 2.3 for bugfixes BTW.

[asvetlov]

Well, the remaining question is minimal 3.5 supported version.
Is there objection for cutting off 3.5.0, 3.5.1 and 3.5.2?
aiohttp will work on Python 3.5.3+

[balloob]

I haven't looked at the different versions of 3.5 yet. However if we are following Debian stable, Python 3.5.3 seems like the way to go 👍

[asvetlov]

The key difference is fixed asyncio.get_event_loop(): the method returns a current loop if called from a coroutine.
Before it always returned the loop set by asyncio,set_event_loop() call.

In 3.5.2 async iterator protocol has changed: __aiter__ is not a coroutine anymore.

[asvetlov]

Also minor but pleasant changes like loop.create_future() and loop.create_task().

[fafhrd91]

I thought loop.create_task is for 3.7

[asvetlov]

No, https://docs.python.org/3/library/asyncio-eventloop.html#tasks
For 3.7 @1st1 has a plan to add calls like asynsio.create_task() and asyncio.create_future(), asyncio.run_in_executor() etc.

BTW, @1st1 do you need help for it? Python 3.7 is coming, I have some spare time ;)

[fafhrd91]

@asvetlov слушай если у тебя есть время можешь этот Тикет доделать? python/cpython#528 (comment)

[fafhrd91]

Oh, I remember now. It was about `current_task`

…

On Oct 19, 2017, at 10:27 AM, Andrew Svetlov ***@***.***> wrote: No, https://docs.python.org/3/library/asyncio-eventloop.html#tasks For 3.8 @1st1 has a plan to add calls like asynsio.create_task() and asyncio.create_future()m asyncio.run_in_executor() etc. BTW, @1st1 do you need help for it? Python 3.7 is coming, I have some spare time ;) — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[kxepal]

🚢 📦 !

[samuelcolvin]

🚀

[samuelcolvin]

would be good to have a list of breaking changes and a pre-release tag before the actual release. This will making it easier to make sure supporting packages support 3.0 the day it's released.

Perhaps we should also have a list of packages which we aim to have compatible the day of release?
Just a rough guess:

• aiohttp-session
• aiohttp-jinja
• aiohttp-devtools

Any more, any less?

[asvetlov]

Beta tag is building right now: https://pypi.python.org/pypi/aiohttp/3.0.0b0
Jinja and session should just work (I believe).
For devtools better to switch on app runners for starting debug application.

Rough list of breaking changes is generated by towncrier --draft run.
I'll make a separate page in docs with instructions for migration from 2.x to 3.0

[samuelcolvin]

For devtools better to switch on app runners for starting debug application.

Can you explain this a little more please.

[samuelcolvin]

Also https://pypi.python.org/pypi/aiohttp/3.0.0b0 doesn't show changes since 2.3.10

[asvetlov]

You dont need app.make_handler() and app._init_loop() anymore (but still supports it).
New approach is described here: https://docs.aiohttp.org/en/latest/web_advanced.html#application-runners

Nope, I didn't generate changelog for 3.0 yet, will do it soon along with migration document.

[webknjaz]

The linux wheel builder job is stuck https://travis-ci.org/aio-libs/aiohttp/jobs/338922307#L882. Can anyone test this in docker in their local machine plz?

[asvetlov]

Investigating

[pfreixes]

Good news, agree lets make the first step. We can iterare with other bits in minor releases. In my backlog I have at least two pending things.

[webknjaz]

$ tools/run_docker.sh aiohttp
...
io/tests/test_websocket_writer.py ...........                            [ 97%]
io/tests/test_worker.py ............................................

This is happening to me at my laptop as well.

@asvetlov it looks like a sane idea to add this wheel building job at least to cron runs for sanity test (w/o deployment of course)

[asvetlov]

Sounds good, especially if you'll setup everything yourself :)

[webknjaz]

it's not that hard: just a bit of copy-paste involved :)

[asvetlov]

Everything is done.
https://pypi.python.org/pypi/aiohttp/3.0.0b4 is available for testing.
I'll publish release tomorrow if nobody will report about problems

[fafhrd91]

you should for couple more days

[asvetlov]

On Monday?

[fafhrd91]

Monday is good, people can test over weekend

[asvetlov]

ok

[samuelcolvin]

aiohttp-devtools is ready for a new release as soon as aiohttp is released, required a big rewrite to use AppRunner in a coroutine rather than multiple processes.

[asvetlov]

cool!
Checked aiohttp-jinja2 and aiohttp-session, they didn't require changes.

[asvetlov]

release is out

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a [new issue] for related bugs.
If you feel like there's important points made in this discussion, please include those exceprts into that [new issue].
[new issue]: https://github.com/aio-libs/aiohttp/issues/new