[Python-ideas] RFC: bytestring as a str representation [was: a new bytestring type?]
Ron Adam
ron3200 at gmail.com
Thu Jan 9 21:01:17 CET 2014
On 01/07/2014 04:36 PM, Alexander Heger wrote:
>>> >>Of course I'm unhappy with it, it doesn't behave the way I think it should,
>>> >>and it's not consistent.
>> >Consistent with what? (Before you rush in an answer, remember that
>> >there are almost always multiple sides to a consistency argument.)
>> >I don't see what's wrong with those. Both produce valid expressions
>> >that, when entered, compare equal to the object whose repr() was
>> >printed. What more would you*want*?
> I find that the definition str is inconsistent indeed, because the
> items in a string are strings again, not characters (or code points).
> I don't think there is too many other examples in Python where the
> same is true; indexing a list does not give a list but the item that
> is at the point.
If you use slices, then it's more consistent with strings. A slice of a
list gives you a list, a slice of a string gives you a string.
The idea of sub-components always breaks down at some level. Then it
shifts to equivalent translations, rather than smaller units. Like
converting strings to bytes, and back again. They aren't sub components of
each other.
Where you draw the lines is dependent on how close you look. (Python,
bytecode, C code, assemby, bytes, bits, voltages, ...)
We can stay at the python level if we choose the viewpoint that an object
is the Python code that creates that object. We have to allow for the
execution of that code in our understanding of it.
Cheers,
Ron
More information about the Python-ideas
mailing list