[Python-Dev] pathlib and issue 11406 (a directory iterator returning stat-like info) (original) (raw)
Ben Hoyt benhoyt at gmail.com
Mon Nov 25 00:34:01 CET 2013
- Previous message: [Python-Dev] pathlib and issue 11406 (a directory iterator returning stat-like info)
- Next message: [Python-Dev] [Python-checkins] cpython (2.7): Fix test_fcntl to run properly on systems that do not support the flags
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I think we should think hard and deep about all the consequences. I was initially in favor of stat caching, but during offline review of PEP 428 Nick pointed out that there are too many different ways to do stat caching, and convinced me that it would be wrong to rush it. Now that beta 1 is out I really don't want to reconsider this -- we really need to stick to the plan.
Fair call, and thanks for the response.
The ship has likewise sailed for adding scandir() (whether to os or pathlib). By all means experiment and get it ready for consideration for 3.5, but I don't want to add it to 3.4.
Yes, I was definitely thinking about 3.5 at this stage. :-) What would be the next step for getting something like os.scandir() added for 3.5 -- a PEP referencing the various issues?
In general I think there are some tough choices regarding stat caching. You already brought up stat vs. lstat -- there's also the issue of what to do if [l]stat fails -- do we cache the exception?
IMO, the current incarnation is for convenience, correctness and cross-platform semantics -- three C's. The next incarnation can add a fourth C, caching.
Three/four C's, I like it!
-Ben
- Previous message: [Python-Dev] pathlib and issue 11406 (a directory iterator returning stat-like info)
- Next message: [Python-Dev] [Python-checkins] cpython (2.7): Fix test_fcntl to run properly on systems that do not support the flags
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]