Showing content from http://mail.python.org/pipermail/python-dev/attachments/20161024/5de65b70/attachment.html below:
<div dir="ltr">Before the horse is totally dead... (maybe it already is), a couple comments:<div class="gmail_extra"><div class="gmail_quote"><div>Â </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In such cases, an extension module written in something like Cython, C<br>
or Rust would be a better fit, </blockquote><div><br></div><div>well, yes, but:</div><div>Â </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">From that perspective, adding "[bytes/bytearray].frombuffer" </blockquote><div><br></div><div>this would be used for the fairly simple use case of passing stuff around between different modules, which would probably be written in something lower lever -- unless they too, only passed data around. Passign data around is a pretty good use-case for Python.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">is adding<br>
complexity to the core language for the sake of giving people one<br>
small additional piece of incremental performance improvement </blockquote><div><br></div><div>here's the thing: this is a very small increase in complexity in exchange for a small increase in performance -- really not a big deal either way. If either of those were large, hte decision would be a no brainer.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
By contrast, a library that provided better low level data buffer<br>
manipulation that was suitable for asyncio's needs is *much* easier to<br>
emulate on older versions, and provides more scope for extracting<br>
efficient data manipulation patterns beyond this one very specific<br>
case of more efficiently snapshotting a subset of an existing buffer.<br></blockquote><div><br></div><div><br></div><div>IS this na either-or? IF someone is proposing a nice lib for "low level data buffer</div>manipulation", then yes, putting frombuffer() in there would be a fine idea.</div><div class="gmail_quote"><br></div><div class="gmail_quote">But if there is no such proposal on the table, then I think adding a frombuffer method to the bytes object is a small improvement that we can do now.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><a href="https://blog.sentry.io/2016/10/19/fixing-python-performance-with-rust.html" rel="noreferrer" target="_blank">https://blog.sentry.io/2016/<wbr>10/19/fixing-python-<wbr>performance-with-rust.html</a></blockquote></div><div><br></div><div>pretty cool -- I guess I should take a look at Rust...</div><div><br></div><div>Thanks,</div><div><br></div><div>Â -CHB</div><div><br></div><div><br></div><div><br></div>-- <br><div class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R Â Â Â Â Â Â (206) 526-6959Â Â voice<br>7600 Sand Point Way NE Â Â (206) 526-6329Â Â fax<br>Seattle, WA Â 98115 Â Â Â Â (206) 526-6317Â Â main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4