On 6/29/2014 5:28 AM, Nick Coghlan wrote:
There'd still be a slight window of discrepancy (since the filesystem
state may change between reading the directory entry and making the
lstat() call), but this could be effectively eliminated from the
perspective of the Python code by making the result
On Sat, Jun 28, 2014 at 2:51 AM, Victor Stinner
wrote:
> 2014-06-26 13:04 GMT+02:00 Antoine Pitrou :
>> For the same reason, I agree with Victor that we should ditch the
>> threading-disabled builds. It's too much of a hassle for no actual,
>> practical benefit. People who want a threadless unicod
On 29.06.2014 19:04, Ethan Furman wrote:
> On 06/29/2014 04:12 AM, Jonas Wielicki wrote:
>>
>> If the flag is set to False, all the fields in the DirEntry will be
>> None, for consistency, even on Windows.
>
> -1
>
> This consistency is unnecessary.
I’m not sure -- similar to the windows_wildcard
Chris Angelico writes:
> On Sat, Jun 28, 2014 at 11:05 PM, Akira Li <4kir4...@gmail.com> wrote:
>> Have you considered adding support for paths relative to directory
>> descriptors [1] via keyword only dir_fd=None parameter if it may lead to
>> more efficient implementations on some platforms?
>>
On 06/29/2014 04:12 AM, Jonas Wielicki wrote:
If the flag is set to False, all the fields in the DirEntry will be
None, for consistency, even on Windows.
-1
This consistency is unnecessary.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.o
On 06/29/2014 05:28 AM, Nick Coghlan wrote:
So, here's my alternative proposal: add an "ensure_lstat" flag to
scandir() itself, and don't have *any* methods on DirEntry, only
attributes.
That would make the DirEntry attributes:
is_dir: boolean, always populated
is_file: boolean, alwa
On 29.06.2014 13:08, Nick Coghlan wrote:
> On 29 June 2014 20:52, Steven D'Aprano wrote:
>> Speaking of caching, is there a way to freshen the cached values?
>
> Switch to a full Path object instead of relying on the cached DirEntry data.
>
> This is what makes me wary of including lstat, even t
On 29 June 2014 21:45, Paul Moore wrote:
> On 29 June 2014 12:08, Nick Coghlan wrote:
>> This is what makes me wary of including lstat, even though Windows
>> offers it without the extra stat call. Caching behaviour is *really*
>> hard to make intuitive, especially when it *sometimes* returns dat
On 29 June 2014 12:08, Nick Coghlan wrote:
> This is what makes me wary of including lstat, even though Windows
> offers it without the extra stat call. Caching behaviour is *really*
> hard to make intuitive, especially when it *sometimes* returns data
> that looks fresh (as it on first call on PO
On 29 June 2014 20:52, Steven D'Aprano wrote:
> Speaking of caching, is there a way to freshen the cached values?
Switch to a full Path object instead of relying on the cached DirEntry data.
This is what makes me wary of including lstat, even though Windows
offers it without the extra stat call.
On Sat, Jun 28, 2014 at 03:55:00PM -0400, Ben Hoyt wrote:
> Re is_dir etc being properties rather than methods:
[...]
> The problem with this is that properties "look free", they look just
> like attribute access, so you wouldn't normally handle exceptions when
> accessing them. But .lstat() and .i
On 28 Jun 2014, at 21:48, Ben Hoyt wrote:
[...]
Crazy idea: would it be possible to "convert" a DirEntry object to a
pathlib.Path object without losing the cache? I guess that
pathlib.Path expects a full stat_result object.
The main problem is that pathlib.Path objects explicitly don't cache
12 matches
Mail list logo
