On Mon, 16 Nov 2015, Paul Moore wrote:
On 16 November 2015 at 13:12, Wayne Werner <waynejwer...@gmail.com> wrote:
Windows file locking is the worst. But it *is* possible to get around - see
the program called BareTail.
Windows file locking is just complex, and the defaults are "safe"
(i.e. people can't change a file you have open). As you say, you can
use different locking options with the Win32 API, but because core
Python's file API is basically derived from Unix, it doesn't expose
these options.
It wouldn't help here anyway, as it's Windows that locks a DLL when
you load it. Personally, I don't see why people think that's a bad
thing - who wants someone to modify the code they are using behind
their back? (I don't know what Unix does, I suspect it retains an old
copy of the shared library for the process until the process exists,
in which case you'd see a different issue, that you do an upgrade, but
your process still uses the old code till you restart).
This is the case for all files. To check, simply open two terminals and in
one:
echo "Going away" >> ~/test.txt
tail ~/test.txt
And in the other:
echo "You will not see this" > ~/test.txt
But tail has an option `-f` that will follow the file by name, instead of
I presume it't the inode. Of course if you >> append to the file instead,
tail *will* actually pick that up.
Long story short, modifying code that a process is using is a bad
thing to do. Therefore, the fact that pip can't easily do it is
probably a good thing in reality...
I suspect it makes life simple (which is better than complex). My personal
assumption about DLL loading would be that it would follow the same
pattern as Python importing modules - it's loaded once from disk at the
first time it's imported, and it never goes back "to disk" for the orignal
DLL.
Though I can also understand the idea behind locking ones files, I kind of
put that in the same basket as a language enforcing "private" variables.
It just increases the burden of making that particular choice, regardless
of how appropriate it may (or may not) be.
I suppose that's mostly academic anyway - I'm not sure that invoking pip
from within the repl is *really* the best solution to getting packages
installed into the correct Python anyway.
-W
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
