On 13 October 2016 at 02:37, Stephen J. Turnbull
> 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.
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
Python-Dev mailing list