implementing AbstractAsyncAccessLogger

[samuelcolvin]

Continuation from #3557, needs tests and docs.

@asvetlov I guess this is what you mean?

Checklist

• I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes
• If you provide code modification, please add yourself to CONTRIBUTORS.txt
  • The format is <Name> <Surname>.
  • Please keep alphabetical order, the file is sorted by names.
• Add a new news fragment into the CHANGES folder
  • name it <issue_id>.<type> for example (588.bugfix)
  • if you don't have an issue_id change it to the pr id after creating the pr
  • ensure type is one of the following:
    • .feature: Signifying a new feature.
    • .bugfix: Signifying a bug fix.
    • .doc: Signifying a documentation improvement.
    • .removal: Signifying a deprecation or removal of public API.
    • .misc: A ticket has been closed, but it is not of interest to users.
  • Make sure to use full sentences with correct case and punctuation, for example: "Fix issue with non-ascii contents in doctest text files."

[asvetlov]

Looks good!

[codecov-io]

Codecov Report

Merging #3767 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #3767      +/-   ##
==========================================
+ Coverage   97.94%   97.95%   +<.01%     
==========================================
  Files          43       43              
  Lines        8576     8589      +13     
  Branches     1374     1375       +1     
==========================================
+ Hits         8400     8413      +13     
  Misses         74       74              
  Partials      102      102

Impacted Files	Coverage Δ
aiohttp/web_protocol.py	93.45% <100%> (+0.21%)	⬆️
aiohttp/abc.py	100% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e54e7cc...aa659c7. Read the comment docs.

[asvetlov]

Is the PR ready for review?

[samuelcolvin]

Yes

[asvetlov]

web_protocol.RequestHandler is a private class, a part of implementation details.
Would you consider moving access log initialization into web.Server/web.Application.
RequestHandler.__init__ signature can be changed in a wild, e.g. replacement all access_log_class, access_log, access_log_format with access logger instance is totally accepted.

I still have no clear vision of how exactly it should look like, and probably cannot have without prototyping.
If you want to play with the idea -- let me know.

Othervise the PR looks good to me.

[asvetlov]

I'm going to merge the PR as is.
Future improvements can be done in separate pull requests

[asvetlov]

Thanks, @samuelcolvin

[samuelcolvin]

web_protocol.RequestHandler is a private class, a part of implementation details.
Would you consider moving access log initialization into web.Server/web.Application.
RequestHandler.__init__ signature can be changed in a wild, e.g. replacement all access_log_class, access_log, access_log_format with access logger instance is totally accepted.

I still have no clear vision of how exactly it should look like, and probably cannot have without prototyping.
If you want to play with the idea -- let me know.

Othervise the PR looks good to me.

I (partially) understand your concerns here but I'm still not clear what the new interface should be.

Personally I think custom loggers should take app as their own argument when initialising or be a plain coroutine, then custom implementations can access app at request.app and do any setup in startup jobs or before creating the app. But either of those changes sound like a big change to the API.

[asvetlov]

I'm preparing an issue with a better description.

[asvetlov]

See #3795