On 7/8/2014 9:52 AM, Ben Hoyt wrote: > DirEntry fields being "static" attribute-only objects > ----------------------------------------------------- > > In `this July 2014 python-dev message > <https://mail.python.org/pipermail/python-dev/2014-July/135303.html>`_, > Paul Moore suggested a solution that was a "thin wrapper round the OS > feature", where the ``DirEntry`` object had only static attributes: > ``name``, ``full_name``, and ``is_X``, with the ``st_X`` attributes > only present on Windows. The idea was to use this simpler, lower-level > function as a building block for higher-level functions. > > At first there was general agreement that simplifying in this way was > a good thing. However, there were two problems with this approach. > First, the assumption is the ``is_dir`` and similar attributes are > always present on POSIX, which isn't the case (if ``d_type`` is not > present or is ``DT_UNKNOWN``). Second, it's a much harder-to-use API > in practice, as even the ``is_dir`` attributes aren't always present > on POSIX, and would need to be tested with ``hasattr()`` and then > ``os.stat()`` called if they weren't present. > Only exposing what the OS provides for free will make the API too difficult to use in the common case. But is there a nice way to expand the API that will allow the user who is trying to avoid extra expense know what information is already available? Even if the initial version doesn't have a way to check what information is there for free, ensuring there is a clean way to add this in the future would be really nice. Janzert
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4