On 13 October 2016 at 02:37, Stephen J. Turnbull <turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Victor Stinner writes: > > 2016-10-12 11:34 GMT+02:00 INADA Naoki <songofaca...@gmail.com>: > > > > I see. My proposal should be another PEP (if PEP is required). > > > > I don't think that adding a single method deserves its own method. > > You mean "deserves own PEP", right? I interpreted Nick to say that > "the reasons that applied to PEP 367 don't apply here, so you can Just > Do It" (subject to the usual criteria for review, but omit the PEP).
Sort of. Adding this to PEP 467 doesn't make sense (as it's not related to easing migration from Python 2 or addressing the mutable->immutable design legacy), but I don't have an opinion yet on whether this should be a PEP or not - that really depends on whether we tackle it as an implementation detail of asyncio, or as a public API in its own right. Method proliferation on builtins is a Big Deal(TM), and efficient buffer management for IO protocol development is a relatively arcane speciality (as well as one where there are dedicated OS level capabilities we may want to exploit some day), which is why I think a dedicated helper module is likely a better way to go. For example: - add `asyncio._iobuffers` as a pure Python memoryview based implementation of the desired buffer management semantics - add `_iobuffers` as an optional asyncio independent accelerator module for `asyncio._iobuffers` If that works out satisfactorily, *then* consider a PEP to either make `iobuffers` a public module in its own right (ala the `selectors` module from the original asyncio implementation), or to expose some of its features directly via the builtin binary data types. The logical leap I strongly disagree with is going straight from "asyncio needs some better low level IO buffer manipulation primitives" to "we should turn the builtin types into low level IO buffer manipulation primitives that are sufficient for asyncio's needs". The notion of "we shouldn't need to define our own domain specific helper libraries" isn't a given for standard library modules any more than it is for 3rd party ones. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com