Misleading exception message from `pathlib.PurePath()` when mixing str and bytes arguments

[barneygale]

Since 6716254, attempting to create a pathlib.PurePath or Path object with mixed str and bytes arguments raises a TypeError (yay!) with a misleading message (booo!):

>>> import pathlib
>>> pathlib.Path('foo', b'bar')
TypeError: Can't mix strings and bytes in path components

This message implies that bytes are supported, as long as we don't mix them with strings. And yet when we try that:

>>> pathlib.Path(b'foo', b'bar')
TypeError: argument should be a str or an os.PathLike object where __fspath__ returns a str, not 'bytes'

This message is better, and should be used in the former case.

Linked PRs

• GH-103525: Improve exception message from pathlib.PurePath() #103526

[terryjreedy]

The following

>>> pathlib.Path('foo', 1)
Traceback (most recent call last):
  File "C:\Programs\Python312\Lib\pathlib.py", line 703, in __init__
    super().__init__(*args)
  File "C:\Programs\Python312\Lib\pathlib.py", line 279, in __init__
    path = self._flavour.join(*args)
  File "<frozen ntpath>", line 149, in join
  File "<frozen genericpath>", line 164, in _check_arg_types
TypeError: join() argument must be str, bytes, or os.PathLike object, not 'int'

raises a message again implying that bytes would be accepted. It would be nicer if this also got the improved message about Path args.
ADDED: When the new code calls os.fspath(1), the message will be

expected str, bytes or os.PathLike object, not int
which still implies that bytes are accepted.

[barneygale]

That's possible to fix, but it involves either capturing and re-raising the TypeError, or basically re-implementing os.fspath(). This code is pretty performance-sensitive so I don't feel great about it.

Another option would be to add a string_only argument to os.fspath() that rejects bytes and raises an appropriate exception.

[barneygale]

That's possible to fix, but it involves either capturing and re-raising the TypeError, or basically re-implementing os.fspath(). This code is pretty performance-sensitive so I don't feel great about it

^ nevermind, I'm wrong. Thanks for the suggestion on the PR!

[barneygale]

Fixed in #103526 / 8611e7b. Not backported as the bug only affects 3.12.