New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Result type depends on order of operands for bytes and bytearray #57507
Comments
In a recent python-ideas discussion of the differences between concatenation and augmented assignment on lists, I pointed out the general guiding principle behind Python's binary operation semantics was that the type of a binary operation should not depend on the order of the operands. That is "X op Y" and "Y op X" should either consistently create results of the same type ("1 + 1.1", "1.1 + 1") or else throw an exception ("[] + ()", "() + []"). This principle is why list concatenation normally only works with other lists, but will accept arbitrary iterables for augmented assignment. collections.deque exhibits similar behaviour (i.e. strict on the binary operation, permissive on augmented assignment). However, bytes and bytearray don't follow this principle - they accept anything that implements the buffer interface even in the binary operation, leading to the following asymmetries: >>> b'' + bytearray()
b''
>>> b'' + memoryview(b'')
b''
>>> bytearray() + b''
bytearray(b'')
>>> bytearray() + memoryview(b'')
bytearray(b'')
>>> memoryview(b'') + b''
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'memoryview' and 'bytes'
>>> memoryview(b'') + bytearray(b'')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'memoryview' and 'bytearray' Now, the latter two cases are due to a known problem where returning NotImplemented from sq_concat or sq_repeat doesn't work properly (so none of the relevant method implementations in the stdlib even try), but the bytes and bytearray interaction is exactly the kind of type asymmetry the operand order independence guideline is intended to prevent. My question is - do we care enough to try to change this? If we do, then it's necessary to decide on more appropriate semantics:
Or just accept that this really is more of a guideline than a rule and adjust the documentation accordingly. |
I think the current behaviour is fine, in that the alternatives are not better at all. In the absence of a type inherently "superior" to the others (as float can be to int, except for very large integers :-)), it makes sense to keep the type of the left-hand argument. Note that .join() has a slightly different behaviour: >>> b"".join([bytearray(), b""])
b''
>>> bytearray().join([bytearray(), b""])
bytearray(b'')
>>> b"".join([bytearray(), memoryview(b"")])
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: sequence item 1: expected bytes, memoryview found |
> Note that .join() has a slightly different behaviour:
>
> >>> b"".join([bytearray(), b""])
> b''
> >>> bytearray().join([bytearray(), b""])
> bytearray(b'')
> >>> b"".join([bytearray(), memoryview(b"")])
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> TypeError: sequence item 1: expected bytes, memoryview found I thinks this is worth fixing. Is there an issue already? |
We can just use this one - it was more in the nature of a question "is there anything we want to change about the status quo?" than a request for any specific change. I'm actually OK with buffer API based interoperability, but if we're going to offer that, we should be consistent:
Since we're tinkering with builtin behaviour, 1 & 2 should probably be brought up on python-dev once someone checks if there is anything other than .join() that needs updating. |
An issue with bytes.join() is already fixed (bpo-15958). |
Reproduced on 3.11. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: