(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.
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
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.
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?
Add glob.glob in os.supports_dir_fd? It looks strange that importing the glob module modifies the value of the os module.
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.
What are your thoughts?
Python-Dev mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://email@example.com/message/GCPDYSPB...