On Wed, Feb 21, 2018 at 12:39 PM, Steve Holden <steve at holdenweb.com> wrote: > I think the chances of a "byte" object are about as good as the chances of > a character object > probably right. > (though one can always implement such in C extensions, that wouldn't build > them into the syntax). > I think you could simply subclass, too (overriding __new__ and a couple methods). But that would do exactly no good, unless you used your own custom string and bytes objects, too. The whole point is that iterating over a string (Or bytes) always returns an also-iterable object, ad-infinitum. This is the cause of the major remaining common "type error" in Python. (the old integer division used to be the big one) > The fact that characters are single-byte strings is responsible for > certain anomalies with (e.g.) the __contains__ operator (list elements > aren't lists, but string element are strings), but overall the choices made > lead to sensible, comprehensible code. > I'm pretty convinced that the choice not to have a character type has had basically zero benefits to sensible, comprehensible code, though it's not a very big deal, either. not a big enough deal for the churn it would cause to introduce it now, that's for sure. so +1 for this PEP as is. -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 Chris.Barker at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180221/a1f531b5/attachment.html>
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