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?
Purposeful change. It was what I had in my head after I posted my "groups" breakdown email and what Guido suggested as well independently. This helps alleviate any perf worries as type checks in C are pointer checks that are cheap to make compared to attribute lookup. And even if we do get the community to move on to path objects the check is still cheap enough to not worry. And finally, this is simply how we have almost always coded this kind of special-casing at the C level throughout Python and the stdlib, so it now is more inline with standard coding practices than the original proposal in the PEP.
> 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.
Yes, I was very much asleep. :)
-Brett
> 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@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@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/k7hoven%40gmail.com