Josiah Carlson wrote:
> Want my advice? Aim for Py3k text as your primary target, but as a
> wrapper, not as the core type (I put the odds at somewhere around 0 for
> such a core type change). If you are good, and want to make guys like
> me happy, you could even make it support the buffer interface for
> non-text (bytes, array, mmap, etc.), unifying (via wrapper) the behavior
> of bytes and text.
This is still my preferred approach, too - for local optimisation of an
algorithm, a string view type strikes me as an excellent idea. For the core
data type, though, keeping the behaviour comparatively simple and predictable
counterbalances the desire for more speed.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
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