[Python-3000] Making more effective use of slice objects in Py3k (original) (raw)
Josiah Carlson jcarlson at uci.edu
Tue Aug 29 23:58:41 CEST 2006
- Previous message: [Python-3000] Making more effective use of slice objects in Py3k
- Next message: [Python-3000] Making more effective use of slice objects in Py3k
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Barry Warsaw <barry at python.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 29, 2006, at 5:01 PM, Jim Jewett wrote: > Why is it essential that string views be a different type, rather than > an internal implementation detail, like long vs int? Today's strings > can already return a new object or an existing one which happens to be > equal. > > Is this just a matter of efficiency, or are you making a fundamental > distinction? This is a good question. I haven't been following this thread in detail, but ISTM that users shouldn't care and that the object itself should do whatever makes the most sense for the most general audience. I'm eager to never have to worry about 8-bit strings vs. unicode strings, how they mix and match, and all the nasty corners when they interact. I'd hate to trade that for the worry about whether I have a string or a string-view.
If views are not automatically returned for methods on strings, then you won't have to worry about views unless you explicitly construct them.
Also, you won't ever have a string-view in py3k, it will be a bytes-view, and if you want to do something like bts.find|index|partition, you are going to need the bytes-view, as bytes don't offer those methods natively.
- Josiah
- Previous message: [Python-3000] Making more effective use of slice objects in Py3k
- Next message: [Python-3000] Making more effective use of slice objects in Py3k
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]