bytes should implement __new__

[mystor]

This seems like a similar issue to #2091. The bytes type implements __init__ but doesn't appear to provide an overload for __new__. This makes it harder for subclasses of bytes to define their own behaviour for __new__.

typeshed/stdlib/3/builtins.pyi

Lines 344 to 355 in 9c3978e

	class bytes(ByteString):
	@overload
	def __init__(self, ints: Iterable[int]) -> None: ...
	@overload
	def __init__(self, string: str, encoding: str,
	errors: str = ...) -> None: ...
	@overload
	def __init__(self, length: int) -> None: ...
	@overload
	def __init__(self) -> None: ...
	@overload
	def __init__(self, o: SupportsBytes) -> None: ...

This also appears to be the case for some of the other builtins (e.g. str)

typeshed/stdlib/3/builtins.pyi

Lines 267 to 272 in 9c3978e

	class str(Sequence[str]):
	@overload
	def __init__(self, o: object = ...) -> None: ...
	@overload
	def __init__(self, o: bytes, encoding: str = ..., errors: str = ...) -> None: ...

[srittau]

Could you give an example where this is a problem? bytes and str should inherit __new__ from object if I am not mistaken.

[mystor]

They do, but the argument list is wrong. As a strawman example:

class SHA1Hash(bytes):
    def __new__(cls, b: bytes) -> 'SHA1Hash':
        if len(b) != 20:
            raise ValueError("Invalid SHA1Hash value!")
        return super().__new__(cls, b)

This doesn't typecheck, because the call to super().__new__(cls, b) is inferred to be object.__new__(cls, b) which is incorrect as object.__new__ takes only the cls argument. bytes, on the other hand, takes an argument to create the object.

This is also a bit like the tuple case again in that __init__ doesn't make much sense for bytes or str, as they are non-mutable and can only be constructed with __new__ in the first place.

[srittau]

Thanks for the explanation. Makes sense. We appreciate pull requests!

[sproshev]

str.__new__ had been added in #1352 but then reverted

[mystor]

Figure I should add a ref to the reason it was backed out: #1464

It appears it was backed out because the addition of __new__ to str caused problems for classes deriving from both str and Enum, as the str's __new__ would now take priority rather than the Enum's. I'm guessing this is caused by some magic wrt how str is actually implemented within python :-/

Perhaps there needs to be a special case for these builtins to make constructing them work correctly?

[hauntsaninja]

Closed by #4555 (and thank you for git-revise!)