On 10 July 2014 01:23, Victor Stinner victor.stin...@gmail.com wrote:
As a Windows user with only a superficial understanding of how
symlinks should behave, (...)
FYI Windows also supports symbolic links since Windows Vista. The
feature is unknown because it is restricted to the administrator
On 10 July 2014 17:04, Paul Moore p.f.mo...@gmail.com wrote:
On 10 July 2014 01:23, Victor Stinner victor.stin...@gmail.com wrote:
As a Windows user with only a superficial understanding of how
symlinks should behave, (...)
FYI Windows also supports symbolic links since Windows Vista.
Am 08.07.14 16:48, schrieb Guido van Rossum:
May the true owner of buildbot.python.org http://buildbot.python.org
stand up!
Well, I think that's me (atleast by my definition of true owner).
I requested that the machine be set up, and I deployed the software
that is running the service (it was
2014-07-10 9:04 GMT+02:00 Paul Moore p.f.mo...@gmail.com:
As someone (Tim?) pointed out later in the thread,
FindFirstFile/FindNextFile doesn't follow symlinks by default (and nor
do the dirent entries on Unix). So whether or not it's natural, the
free functionality provided by the OS is that
On 10 Jul 2014 03:39, Victor Stinner victor.stin...@gmail.com wrote:
2014-07-10 9:04 GMT+02:00 Paul Moore p.f.mo...@gmail.com:
As someone (Tim?) pointed out later in the thread,
FindFirstFile/FindNextFile doesn't follow symlinks by default (and nor
do the dirent entries on Unix). So
DirEntry methods will remain free (no syscall) for directories and
regular files. One extra syscall will be needed only for symlinks,
which are more rare than other file types (for example, you wrote
Windows typically makes little use of symlinks).
The info we want for scandir is that of
On 07/10/2014 06:58 AM, Nick Coghlan wrote:
The info we want for scandir is that of the *link itself*. That makes it
easy to implement things like the followlinks flag of os.walk. The
*far end* of the link isn't relevant at this level.
This also mirrors listdir, correct? scandir is simply*
I'm just curious as to why there are 54 open issues after both of these
PEPs have been accepted and 384 is listed as finished. Did we hit some
unforeseen technical problem which stalled development?
For these and any other open issues if you need some Windows testing
doing please feel free
[for those that don't know, 3121 is extension module inti/finalization and
384 is the stable ABI]
On Thu Jul 10 2014 at 3:47:03 PM, Mark Lawrence breamore...@yahoo.co.uk
wrote:
I'm just curious as to why there are 54 open issues after both of these
PEPs have been accepted and 384 is listed as
I don't know the details, but I suspect that was the result of my general
guideline don't start projects cleaning up lots of stdlib code just to
satisfy some new style rule or just to use a new API -- which came from
hard-won experience where such a cleanup project introduced some new bugs
that
On Thu, Jul 10, 2014 at 2:59 PM, Mark Lawrence breamore...@yahoo.co.uk
wrote:
I'm just curious as to why there are 54 open issues after both of these
PEPs have been accepted and 384 is listed as finished. Did we hit some
unforeseen technical problem which stalled development?
I tried to
On 07/10/2014 04:57 PM, Alexander Belopolsky wrote:
On Thu, Jul 10, 2014 at 2:59 PM, Mark Lawrence wrote:
I'm just curious as to why there are 54 open issues after both of
these PEPs have been accepted and 384 is listed as finished. Did
we hit some unforeseen technical problem which stalled
On 07/09/2014 09:02 PM, Nick Coghlan wrote:
On 9 Jul 2014 17:14, Ethan Furman wrote:
I like the 'onerror' API better primarily because it gives a single
point to deal with the errors. [...]
The onerror approach can also deal with readdir failing, which the
PEP currently glosses over.
Do
13 matches
Mail list logo
