Serhiy Storchaka <storchaka+cpyt...@gmail.com> added the comment:
We provide Python implementations for fnmatch, glob, realpath even if there are corresponding libc functions. This makes them available even on platforms that doesn't have native implementations in libc, avoids C limitations, and allow to add new options. I think it is not wrong to provide a Python implementation for get_current_dir_name(). My concerns are that while it can be useful for people that search for get_current_dir_name() in Python, it can be confused for other people. * getcwd() and get_current_dir_name() are very similar, but have very different names. In what cases the one or other is preferable? * On Windows getcwd() returns a path without resolved symbolic links, the same as get_current_dir_name(). Shouldn't we provide an option for getting current working directory with resolved symbolic links on all platforms? This will give us three options: resolved symlinks, unresolved symlinks, and platform-depended default. * get_current_dir_name() works as desired only when current working directory was not changed since the start of the program. Any call of chdir() will make it an alias to getcwd(). * For some libc functions we add options to existing functions rather of duplicating the number of names in the os module. For example the dir_fd option instead of *at() functions. Wouldn't be better to add a buulean parameter (with platform-depending default) to getcwd()? * What about pathlib? Does it need corresponding feature? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue1154351> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
