aiohttp 3.0 release

async/await everywhere. :champagne: :fireworks:

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

+1

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

@kxepal what we can simplify by dropping 3.5?

@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.

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.

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

@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.

@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.

@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.

@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

big -1 for splitting release branches.

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

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?

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.

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.

I would love to contribute. Starting right now.

would you consider creating a new branch for PRs?

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

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+

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 👍

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.

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

I thought loop.create_task is for 3.7

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 ;)

@asvetlov слушай если у тебя есть время можешь этот Тикет доделать? https://github.com/python/cpython/pull/528#issuecomment-335862442

Oh, I remember now. It was about current_task

On Oct 19, 2017, at 10:27 AM, Andrew Svetlov notifications@github.com 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.

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

I discussed some of these with Guido, and I need to wrap my head around a few things before I move forward. I'll ping you in a week or two about it.

@1st1 thanks

@fafhrd91 посмотрю завтра

@fafhrd91 do you agree for supporting python 3.5.3+ by aiohttp 3.0?
For now cut off in master branch is Python 3.5.0.
I love to have loop.create_future()/loop.create_task() and especially fixed asyncio.get_event_loop() behavior.

Thanks to contributors for moving to async/await syntax.
The task is trivial but time consuming. I very appreciate your help.
Maybe you will take a look on #2395 also? Documentation is even more important for newbies than source code, please help them.

I think python3.5.3 makes sense.

Ubuntu LTS 16.04 supports Python 3.5.2 only.
Honestly I don't care: people can install Python 3.6 on it by https://launchpad.net/~fkrull/+archive/ubuntu/deadsnakes PPA
New LTS release is expected at 2018 April.

I think it is fine. It will take time until people start migration to aiohttp 3.0, by that time next Lts should be available

Good. By this comment we finally decided to support Python 3.5.3+ in aiohttp 3.0.
Left it just for note :)

There are many thinks tagged for this milestone [1], all of them are a must or there are some nice to have? Would be nice have a list with some priority of issues that are still pending and are a must
.

[1] https://github.com/aio-libs/aiohttp/milestone/17

Everything is a whishlist.
It is Open Source, people works on features they want/like to work.
Release date is not scheduled, development is in free mode.
The list of blockers will appear close to release after declaring an estimated release date.

Let's make the release.
Changelog is pretty long, the master is stable.
Many bugs are fixed.
We can do all pending issues later in 3.1

🎉🎉🎉

🚢 📦 !

:rocket:

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?

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

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

Can you explain this a little more please.

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

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.

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?

Investigating

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.

$ 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)

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

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

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

you should for couple more days

On Monday?

Monday is good, people can test over weekend

ok

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.

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

release is out

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].