Re: [Python-Dev] Adding bytes.frombuffer() constructor to PEP 467 (was: [Python-ideas] Adding bytes.frombuffer() constructor
On 25 October 2016 at 02:53, Chris Barker wrote: > IS this na either-or? IF someone is proposing a nice lib for "low level data > buffer > manipulation", then yes, putting frombuffer() in there would be a fine idea. > > 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. The suggestion came from folks working on asyncio performance improvements, and we already got the entire ``selectors`` abstraction from the original asyncio implementation work, as well as Yury's new libuv-based ``uvloop`` asyncio event loop implementation. Given that "make OpenStack/SDN/NFV run faster" is a key point of interest for folks like Intel and Red Hat, I'm *absolutely* suggesting that they put some paid time and energy into a lower level buffer manipulation library between now and the Python 3.7 feature freeze in 12+ months, as I think that will have longer term pay-offs well beyond the scope of the original use cases :) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding bytes.frombuffer() constructor to PEP 467 (was: [Python-ideas] Adding bytes.frombuffer() constructor
On 25 October 2016 at 17:25, Nick Coghlan wrote: > as well as Yury's new > libuv-based ``uvloop`` asyncio event loop implementation. Oops, I phrased that badly - the default asyncio event loop implementation is still pure Python, but uvloop is a drop-in Cython based replacement. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Default formatting
Classes that doesn't define the __format__ method for custom PEP 3101 formatting inherits it from parents. Originally the object.__format__ method was designed as [1]: def __format__(self, format_spec): return format(str(self), format_spec) An instance is converted to string and resulting string is formatted according to format specifier. Later this design was reconsidered [2], and now object.__format__ is equivalent to: def __format__(self, format_spec): assert format_spec == '' return format(str(self), '') Non-empty format specifier is rejected. But why call format() on resulting string? Why not return resulting string as is? object.__format__ could be simpler (not just implementation, but for understanding): def __format__(self, format_spec): assert format_spec == '' return str(self) This can change the behaviour in corner case. str(self) can return not exact string, but string subclass with overloaded __format__. But I think we can ignore such subtle difference. [1] https://www.python.org/dev/peps/pep-3101/ [2] http://bugs.python.org/issue7994 ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding bytes.frombuffer() constructor to PEP 467 (was: [Python-ideas] Adding bytes.frombuffer() constructor
On Tue, Oct 25, 2016 at 12:25 AM, Nick Coghlan wrote: > The suggestion came from folks working on asyncio performance > improvements, > I'm *absolutely* suggesting > that they put some paid time and energy into a lower level buffer > manipulation library between now and the Python 3.7 feature freeze in > 12+ months, as I think that will have longer term pay-offs well beyond > the scope of the original use cases :) > Sounds good -- let's hope something comes of that. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
