[issue24019] str/unicode encoding kwarg causes exceptions

Mahmoud Hashemi added the comment: I would urge you all take a stronger look at usability, rather than parroting the current state of the design and docs. Python gained renown over the years for its ability to stay flexible while maturing. Focusing on purity and ignoring the needs of practical

[issue24019] str/unicode encoding kwarg causes exceptions

Changes by Benjamin Peterson : -- resolution: -> rejected status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing

[issue24019] str/unicode encoding kwarg causes exceptions

Marc-Andre Lemburg added the comment: I agree with closing this as "won't fix". It is true that the encoding keyword argument is only useful when passing in byte strings or (and that's also where it originated in Python 2: the default string type is a byte string), but even in Python 3, this i

[issue24019] str/unicode encoding kwarg causes exceptions

R. David Murray added the comment: Sounds like we should close this as rejected, then. Serhiy's point is a good one. Maybe not the way we'd design the api from scratch, but it's what we've got and it serves a purpose. -- ___ Python tracker

[issue24019] str/unicode encoding kwarg causes exceptions

Martin Panter added the comment: I thought it might be okay to use codecs.decode() instead for those cases, though it doesn’t check for text encodings. And support for arbitrary bytes-like object doesn’t seem to be documented (though seems to work in reality). --

[issue24019] str/unicode encoding kwarg causes exceptions

Serhiy Storchaka added the comment: Please don't deprecate the encoding parameter in str. It has a use case. str constructor works with any bytes-like objects, even with these that don't have the decode method. It raises more appropriate TypeError instead of AttributeError, so often you don't

[issue24019] str/unicode encoding kwarg causes exceptions

Changes by Berker Peksag : -- nosy: +berker.peksag ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue24019] str/unicode encoding kwarg causes exceptions

Eric V. Smith added the comment: I agree with deprecating (in the documentation) but never removing the encoding argument to str() in Python 3. .decode() is the better way to convert a bytes-like object to a str. Every change proposed here would be an enhancement in 2.7, and we are not implem

[issue24019] str/unicode encoding kwarg causes exceptions

Martin Panter added the comment: Okay, I was trying to confirm your proposal in Python 3 terms, because in Python 2, str has a different meaning and I was confused. I agree that the existence of the decoding mode is a design bug, so how would you feel about deprecating it, at least in the docu

[issue24019] str/unicode encoding kwarg causes exceptions

R. David Murray added the comment: It does feel like the encoding argument is left over from the translation of the unicode constructor into the str constructor. I wouldn't be opposed to deprecating it, myself, though we'd probably never remove it. I would be opposed to making it work on non

[issue24019] str/unicode encoding kwarg causes exceptions

Mahmoud Hashemi added the comment: Martin, it sounds that way because that is what is being proposed: "Merging and simplifying the two modes". Given the existence of .decode() on bytestrings, the only objects that generally need decoding in Python 2 and 3, the existence of str/unicode's second

[issue24019] str/unicode encoding kwarg causes exceptions

Martin Panter added the comment: I don’t think changes to Python 2 are considered here, unless they are bug fixes, and this does not sound like a bug fix. For Python 3, it sounds like you are proposing that str() accept encoding arguments even when not decoding from bytes. It sounds like this

[issue24019] str/unicode encoding kwarg causes exceptions

Mahmoud Hashemi added the comment: Python already has one approach that fails to decode non-bytestrings: the .decode() method. This is about removing unicode barriers to entry and making the str constructor in Python 3 as succinctly useful as possible. There are several problems the helper d

[issue24019] str/unicode encoding kwarg causes exceptions

Eric V. Smith added the comment: As this is an enhancement request, I've changed the versions. I'm opposed to this change. If I pass an encoding along with a type for which it makes no sense, I'd prefer an error instead of silently ignoring the encoding. I think your helper function is an app

[issue24019] str/unicode encoding kwarg causes exceptions

New submission from Mahmoud Hashemi: The encoding keyword argument to the Python 3 str() and Python 2 unicode() constructors is excessively constraining to the practical use of these core types. Looking at common usage, both these constructors' primary mode is to convert various objects into