[Python-Dev] file system path protocol PEP (original) (raw)
Sven R. Kunze srkunze at mail.de
Fri May 13 05:24:57 EDT 2016
- Previous message (by thread): [Python-Dev] file system path protocol PEP
- Next message (by thread): [Python-Dev] file system path protocol PEP
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 13.05.2016 10:36, Koos Zevenhoven wrote:
This has just been discussed very recently in this thread (and earlier too).
Could you point me to that? It seems I missed that part. I only found posts related to performance degradation.
However, the proposed semantics will change if the checks are swapped. So, my actual question is:
Is that an intended API inconsistency or a known bug supposed to be resolved later?
It may make sense, but it's not among our current worries.
It might not be yours but mine. ;) That's why I was asking.
Besides, we already added the new fspath semantics to the PEP.
While I hope Brett is asleep in his time zone, I'm guessing he will agree (just saying this because you write "@Brett"). -- Koos
On Fri, May 13, 2016 at 10:58 AM, Sven R. Kunze <srkunze at mail.de> wrote: On 12.05.2016 18:24, Guido van Rossum wrote: def fspath(p: Union[str, bytes, PathLike]) -> Union[str, bytes]: if isinstance(p, (str, bytes)): return p try: return p.fspath except AttributeError: raise TypeError(...)
@Brett Would you think it makes sense to swap the str/bytes check and the fspath check?
I just thought of a class subclassing str/bytes and defines fspath. Its fspath method would be ignored currently. Best, Sven
Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/k7hoven%40gmail.com
- Previous message (by thread): [Python-Dev] file system path protocol PEP
- Next message (by thread): [Python-Dev] file system path protocol PEP
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]