Koos Zevenhoven wrote:
See my comment below (from this thread, but there were no reactions). I'm not sure if that option was ever considered. Can we let DirEntry dictate the future of Python?
No. On the other hand, we'd need a /really/ good reason to change it now.
Actually, now that .path is not out yet, would it make sense to call it Path.str or Path.strpath instead, and introduce the same thing on DirEntry and guarantee a str (instead of str or bytes as DirEntry.path now does)? Maybe that would lead to fewer broken implementations in third-party libraries too?
DirEntry needs to return the same type it was given, and one can give it both bytes and strings.
Your first point /may/ be valid. The big question is: is DirEntry provisional? I don't think it is. In which case, we're stuck with .path on DirEntry, and may as well use the same name for the same idea on pathlib.Path.