[Python-Dev] Adding bytes.frombuffer() constructor to PEP 467 (was: [Python-ideas] Adding bytes.frombuffer() constructor (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Wed Oct 12 22:54:39 EDT 2016

On 13 October 2016 at 02:37, Stephen J. Turnbull <turnbull.stephen.fw at u.tsukuba.ac.jp> wrote:

Victor Stinner writes: > 2016-10-12 11:34 GMT+02:00 INADA Naoki <songofacandy at 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:

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 | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list