On Sat, May 14, 2016 at 2:33 AM, Sven R. Kunze <srku...@mail.de> wrote: > On 13.05.2016 17:29, Brett Cannon wrote: >> >> 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. > > > Maybe, we have a misunderstanding here. Does "PyUnicode_Check(path)" respect > subclass hierarchies such as isinstance(path, str) does? Could not find the > definition of it in the source. > > You said it's just a pointer comparison. To me that implies it could not > respect subclasses as isinstance does. If that is the case, the C > implementation differs from the Python version in semantics. I'm sorry if I > misunderstood the whole implementation here.
https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_Check https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_CheckExact "Check" accepts subclasses; "CheckExact" doesn't (it's like "type(x) is str"). The question is, which one SHOULD be being done? What should this do: class TmpPath(str): def __fspath__(self): return "/tmp/"+self x = TmpPath("foo/bar") open(x, "w") Does that respect __fspath__, or respect the fact that it's a string? ChrisA _______________________________________________ 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/archive%40mail-archive.com
