(see an answer to the OP's specific question below)
I don't quite get the point for <module>.supports_stuff. It seems
well-intentioned but misguided.
1. The documentation clearly says that it's supported depending on OS flavor -- so if I want to know if I can supply it, I need to rather
check `os.name`. Those members are thus redundant.
If the distinction is finer than os.name then I'd need some other, case-specific check depending on what the distinction is;
alternatively, I could check the function's signature in its metadata if the support is reflected in it.
2. Support of a parameter is a characteristic of a function rather than a module. So information like this doesn't belong at module level.
Moreover, object references can be moved around at will and they are all equal, there's no such thing as "one true reference" (you can get
the object's lexical scope but there's no guarantee that it corresponds to the public interface).
This is the structural conflict that Sergey ran into when he suddenly discovered that the functions and the flag are two completely
unrelated objects that can be in completely different places.
So any such flags, if they have the right to exist at all, should be
attached to function objects.
On 14.06.2020 20:36, Serhiy Storchaka wrote:
In Python 3.3 a number of functions in the os module got the support of new options, like dir_fd or follow_symlinks. I well remember this
because the initial reason of my contribution to CPython was related to this feature.
The support of new options was platform dependent. They were supported only on some Posix platforms, but not on Windows. Sets like
supports_dir_fd and supports_follow_symlinks was added in the os module to specify which functions support which options. If say os.stat
is contained in os.supports_dir_fd, then os.stat() supports keyword argument dir_fd.
Now I want to add the support of dir_fd to glob.glob() and some other functions. It will be platform-dependent, it requires os.open() and
os.stat() supporting dir_fd and os.scandir supporting the file descriptor argument. How can I specify that glob.glob() supports dir_fd?
1. Add glob.glob in os.supports_dir_fd? It looks strange that importing the
glob module modifies the value of the os module.
2. Introduce the glob.supports_dir_fd set and add glob.glob to it? We will need to add sets supports_dir_fd in all modules which contain
functions which can support dir_fd. But what if the function is defined in one module, by normally is imported from other module? Should
we merge sets supports_dir_fd from different modules?
This would be the way consistent with the current design.
If the public interface is to use the function from another module, the public interface module should have a parameter like this; whether
the private module also has one and whether they are different objects is implementation detail.
Also, the common problem with two former options is that when we wrap the
function, we need to add it to the corresponding set.
3. Or set the attribute glob.glob.supports_dir_fd = True or glob.glob.__supports_dir_fd__ = True (and add similar attributes to all os
functions which support)?
What are your thoughts?
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/GCPDYSPB4656Q7TAMDLBFED6NQJCNLIP/
Code of Conduct: http://python.org/psf/codeofconduct/
--
Regards,
Ivan
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/F4N5RY3VFSFEYT57RZMPA74J67XAGU45/
Code of Conduct: http://python.org/psf/codeofconduct/
