shutil rant
Gerson Kurz
is in shutil
"""copyfile(src, dst)
Copy the contents of the file named src to a file named dst. If dst
exists, it will be replaced, otherwise it will be created...."""
I use that function, only to find out what the documentation will not
tell you, that neither the file attributes nor the file date is
copied. :(
So, I'm reading the whole doc page on "shutil". It has the two
ingeniously named functions
"""copy(src, dst)
Copy the file src to the file or directory dst...Permission bits are
copied..."""
and
"""copy2(src, dst)
Similar to copy(), but last access time and last modification time are
copied as well."""
I try copy2, gruntling about the great name choice, but find that the
hidden attribute is not copied (on Windows 2000 using ActivePython
2.2.1 Build 222). The "Read Only" bit is copied. I look into the
source of lib\shutil.py and find that copy2 is a wrapper for copystat,
which means it won't work neither; basically it uses the stuff from
the "stat" module which doesn't have support for anything other than
the unix file-permission bits.
Now I know about general unix superiority and all that, but ... do I
really have to resort to "import win32api" in order to make an exact
file copy on windows?
Aahz
Gerson Kurz <moc.q-...@p-nand-q.com> wrote:
>
>Now I know about general unix superiority and all that, but ... do I
>really have to resort to "import win32api" in order to make an exact
>file copy on windows?
Well, yes. The problem is that win32all is not part of the core Python
distribution, so none of the core library features can rely on it. :-(
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"In the end, outside of spy agencies, people are far too trusting and
willing to help." --Ira Winkler
Bjorn Pettersen
> In article <3ce4eebb...@News.CIS.DFN.DE>,
> Gerson Kurz <moc.q-...@p-nand-q.com> wrote:
> >
> >Now I know about general unix superiority and all that, but ... do I
> >really have to resort to "import win32api" in order to make an exact
> >file copy on windows?
>
> Well, yes. The problem is that win32all is not part of the
> core Python distribution, so none of the core library
> features can rely on it. :-(
The Macintosh port seem to have full support for the Mac interfaces, so
isn't it about time the windows port got up to par? <wink>
Seriously though, you can't do "any serious" work on windows without the
win32 extensions. Since the ActiveState distribution comes bundled with
these, we've standardized on it here. (there are of course other
advantages to the ActiveState distribution also <wink>)
-- bjorn
Aahz
Bjorn Pettersen <BPett...@NAREX.com> wrote:
> From: Aahz [mailto:aa...@pythoncraft.com]
>>
>> Well, yes. The problem is that win32all is not part of the
>> core Python distribution, so none of the core library
>> features can rely on it. :-(
>
>The Macintosh port seem to have full support for the Mac interfaces, so
>isn't it about time the windows port got up to par? <wink>
Sure! You willing to commit the time to making win32all part of the core?
Bjorn Pettersen
> In article <mailman.102171303...@python.org>,
> Bjorn Pettersen <BPett...@NAREX.com> wrote:
> > From: Aahz [mailto:aa...@pythoncraft.com]
> >>
> >> Well, yes. The problem is that win32all is not part of the core
> >> Python distribution, so none of the core library features
> can rely on
> >> it. :-(
> >
> >The Macintosh port seem to have full support for the Mac
> interfaces, so
> >isn't it about time the windows port got up to par? <wink>
>
> Sure! You willing to commit the time to making win32all part
> of the core?
Don't I wish <sigh>. Currently figuring out why SIP is choking on our
900KLoc C++ library is higher priority. If I figure that out before I go
insane, I'll consider it :-)
-- bjorn