(Since bytes may be used for file names I think they should get this new capability too.)
I don’t really care one way or another, but is it really still the case that bytes need to be used for filenames? For uses other than just passing them around?
Yes, Linux in particular does not guarantee that file names are using any particular encoding (let alone a consistent encoding for different files). The only two bytes that are special are '\0' and '/'.
Sigh.
Indeed, especially since macOS *does* guarantee that filenames are Unicode (even using a specific normalization) and Windows represents filenames internally as UTF-16, IIRC.
In any case, while it’s fine to consider the bytes issue in choosing a name, I hope it doesn’t derail the whole idea.
I didn't like the name stripstr anyway. :-)
-CHB
On Fri, Mar 06, 2020 at 03:33:49PM -0800, Ethan Furman wrote:
> I think we should have a `stripstr()` as an alias for strip, and a new
> `stripchr()`.
Shouldn't they be the other way around?
`strip` removes chars from a set of chars; the proposed method will
remove a prefix/suffix.
> And I'm perfectly okay with bytes() not having those methods. ;-)
If heavy users of bytes want these methods, they can request them
separately. There's no backwards compatibility requirement for new
string methods to be automatically added to bytes.
I guess the question now is do we need a PEP?