If I may humbly chime in this, with a hint...
On 13.02.2015 05:01, Guido van Rossum wrote:
> On Thu, Feb 12, 2015 at 7:41 PM, Ethan Furman wrote:
>> [snip]
>> 2) always use the type of self when creating new instances
>>
>>pros:
>> - subclasses automatically maintain type
>> - much
If I may humbly chime in this, with a hint...
On 13.02.2015 05:01, Guido van Rossum wrote:
> On Thu, Feb 12, 2015 at 7:41 PM, Ethan Furman wrote:
>> [snip]
>> 2) always use the type of self when creating new instances
>>
>>pros:
>> - subclasses automatically maintain type
>> - much
On 01.07.2014 23:20, Paul Moore wrote:
> [snip]
> Please, let's stick to a low-level wrapper round the OS API for the
> first iteration of this feature. Enhancements can be added later, when
> real-world usage has proved their value.
>
> Paul
+1 to the whole thing. That’s an ingeniously simple so
On 01.07.2014 17:30, Ben Hoyt wrote:
>> No need for a microsecond-timed deletion -- a directory with +r but
>> without +x will allow you to list the entries, but stat calls on the
>> files will fail with EPERM:
>
> Ah -- very good to know, thanks. This definitely points me in the
> direction of wa
On 01.07.2014 15:00, Ben Hoyt wrote:
> I'm leaning towards preferring #2 (Nick's proposal) because it solves
> or gets around the caching issue. My one concern is error handling. Is
> it an issue if scandir's __next__ can raise an OSError either from the
> readdir() call or the call to stat()? My t
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
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 27.06.2014 00:59, Ben Hoyt wrote:
> Specifics of proposal
> =
> [snip] Each ``DirEntry`` object has the following
> attributes and methods:
> [snip]
> Notes on caching
>
>
> The ``DirEntry`` objects are relatively dumb -- the ``name`` attribute
> is obviousl
On 27.06.2014 03:50, MRAB wrote:
> On 2014-06-27 02:37, Ben Hoyt wrote:
>> I don't mind iterdir() and would take it :-), but I'll just say why I
>> chose the name scandir() -- though it wasn't my suggestion originally:
>>
>> iterdir() sounds like just an iterator version of listdir(), kinda
>> like
On 27.05.2014 11:05, Chris Angelico wrote:
> On Tue, May 27, 2014 at 6:58 PM, Serhiy Storchaka wrote:
>> 26.05.14 10:59, raymond.hettinger написав(ла):
>>>
>>> +result = [(elem, i) for i, elem in zip(range(n), it)]
>>
>>
>> Perhaps it is worth to add simple comment explaining why this is n
10 matches
Mail list logo
