Function in os module for available disk space, why not?
I wrote on comp.lang.python today:
is there a simple way (or any way at all) to find out for any given hard disk how much free space is left on that device? I looked into the os module, but either not hard enough or there is no such function. Of course, the ideal solution would be platform-independant, too... :)
Is there any good reason for not having a cross-platform solution to this? I'm certainly not the first to ask for such a function and it certainly exists for all platforms, doesn't it? Unfortunately, OS problems like that make it rather impossi- ble to write truly cross-platform applications in Python, even if it is touted to be exactly that. I know that OS differ in the services they provide, but in this case it seems to me that each one *must* have such a function, so I don't understand why it's not there... Regards, Dinu -- Dinu C. Gherman ReportLab Consultant - http://www.reportlab.com ................................................................ "The only possible values [for quality] are 'excellent' and 'in- sanely excellent', depending on whether lives are at stake or not. Otherwise you don't enjoy your work, you don't work well, and the project goes down the drain." (Kent Beck, "Extreme Programming Explained")
On Mon, Mar 19, 2001 at 12:57:49PM +0100, Dinu Gherman wrote:
I wrote on comp.lang.python today:
is there a simple way (or any way at all) to find out for any given hard disk how much free space is left on that device? I looked into the os module, but either not hard enough or there is no such function. Of course, the ideal solution would be platform-independant, too... :)
Is there any good reason for not having a cross-platform solution to this? I'm certainly not the first to ask for such a function and it certainly exists for all platforms, doesn't it?
I think the main reason such a function does not exist is that no-one wrote it. If you can write a portable function, or fake one by making different implementations on different platforms, please contribute ;) Step one is making an inventory of the available functions, though, so you know how large an intersection you have to work with. The fact that you have to start that study is probably the #1 reason no-one's done it yet :) -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Thomas Wouters wrote:
I think the main reason such a function does not exist is that no-one wrote it. If you can write a portable function, or fake one by making different implementations on different platforms, please contribute ;) Step one is making an inventory of the available functions, though, so you know how large an intersection you have to work with. The fact that you have to start that study is probably the #1 reason no-one's done it yet :)
Well, this is the usual "If you need it, do it yourself!" answer, that bites the one who dares to speak up for all those hundreds who don't... isn't it? Rather than asking one non-expert in N-1 +/- 1 operating systems to implement it, why not ask N experts in imple- menting Python on 1 platform to do the job? (Notice the potential for parallelism?! :) Uhmm, seriously, does it really take 10 years for such an issue to creep up high enough on the priority ladder of Python-Labs? In any case it doesn't sound like a Python 3000 feature to me, or maybe it should? Regards, Dinu -- Dinu C. Gherman ReportLab Consultant - http://www.reportlab.com ................................................................ "The only possible values [for quality] are 'excellent' and 'in- sanely excellent', depending on whether lives are at stake or not. Otherwise you don't enjoy your work, you don't work well, and the project goes down the drain." (Kent Beck, "Extreme Programming Explained")
Dinu Gherman wrote:
Thomas Wouters wrote:
I think the main reason such a function does not exist is that no-one wrote it. If you can write a portable function, or fake one by making different implementations on different platforms, please contribute ;) Step one is making an inventory of the available functions, though, so you know how large an intersection you have to work with. The fact that you have to start that study is probably the #1 reason no-one's done it yet :)
Well, this is the usual "If you need it, do it yourself!" answer, that bites the one who dares to speak up for all those hundreds who don't... isn't it?
Rather than asking one non-expert in N-1 +/- 1 operating systems to implement it, why not ask N experts in imple- menting Python on 1 platform to do the job? (Notice the potential for parallelism?! :)
I think the problem with this one really is the differences in OS designs, e.g. on Windows you have the concept of drive letters where on Unix you have mounted file systems. Then there also is the concept of disk space quota per user which would have to be considered too. Also, calculating the available disk space may return false results (e.g. for Samba shares). Perhaps what we really need is some kind of probing function which tests whether a certain amount of disk space would be available ?! -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/
"M.-A. Lemburg" <mal@lemburg.com>:
Actually opening a file in record mode and then using file.seek() should work on many platforms.
Not on Unix! No space is actually allocated until you write something, regardless of where you seek to. And then only the blocks that you touch (files can have holes in them). Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
On Mon, Mar 19, 2001 at 01:21:44PM +0100, Dinu Gherman wrote:
Thomas Wouters wrote:
I think the main reason such a function does not exist is that no-one wrote it. If you can write a portable function, or fake one by making different implementations on different platforms, please contribute ;) Step one is making an inventory of the available functions, though, so you know how large an intersection you have to work with. The fact that you have to start that study is probably the #1 reason no-one's done it yet :)
Well, this is the usual "If you need it, do it yourself!" answer, that bites the one who dares to speak up for all those hundreds who don't... isn't it?
Rather than asking one non-expert in N-1 +/- 1 operating systems to implement it, why not ask N experts in imple- menting Python on 1 platform to do the job? (Notice the potential for parallelism?! :)
Uhmm, seriously, does it really take 10 years for such an issue to creep up high enough on the priority ladder of Python-Labs?
In any case it doesn't sound like a Python 3000 feature to me, or maybe it should?
Nope. But you seem to misunderstand the idea behind Python development (and most of open-source development.) PythonLabs has a *lot* of stuff they have to do, and you cannot expect them to do everything. Truth is, this is not likely to be done by Pythonlabs, and it will never be done unless someone does it. It might sound harsh and unfriendly, but it's just a fact. It doesn't mean *you* have to do it, but that *someone* has to do it. Feel free to find someone to do it :) As for the parallelism: that means getting even more people to volunteer for the task. And the person(s) doing it still have to figure out the common denominators in 'get me free disk space info'. And the fact that it's *been* 10 years shows that noone cares enough about the free disk space issue to actually get people to code it. 10 years filled with a fair share of C programmers starting to use Python, so plenty of those people could've done it :) -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Thomas Wouters wrote:
Nope. But you seem to misunderstand the idea behind Python development (and most of open-source development.)
Not sure what makes you think that, but anyway.
PythonLabs has a *lot* of stuff they have to do, and you cannot expect them to do everything. Truth is, this is not likely to be done by Pythonlabs, and it will never be done unless someone does it.
Apparently, I agree, I know less about what makes truth here. What is probably valid is that having much to do is true for everybody and not much of an argument, is it?
As for the parallelism: that means getting even more people to volunteer for the task. And the person(s) doing it still have to figure out the common denominators in 'get me free disk space info'.
I'm afraid this is like argueing in circles.
And the fact that it's *been* 10 years shows that noone cares enough about the free disk space issue to actually get people to code it. 10 years filled with a fair share of C programmers starting to use Python, so plenty of those people could've done it :)
I'm afraid, again, but the impression you have of nobody in ten years asking for this function is just that, an impression, unless *somebody* prooves the contrary. All I can say is that I'm writing an app that I want to be cross-platform and that Python does not allow it to be just that, while Google gives you 17400 hits if you look for "python cross-platform". Now, this is also some kind of *truth* if only one of a mismatch between reality and wish- ful thinking... Regards, Dinu
On Mon, Mar 19, 2001 at 01:58:48PM +0100, Dinu Gherman wrote:
All I can say is that I'm writing an app that I want to be cross-platform and that Python does not allow it to be just that, while Google gives you 17400 hits if you look for "python cross-platform". Now, this is also some kind of *truth* if only one of a mismatch between reality and wish- ful thinking...
I'm sure I agree, but I don't see the value in dropping everything to write a function so Python can be that much more cross-platform. (That's just me, though.) Python wouldn't *be* as cross-platform as it is now if not for a group of people who weren't satisfied with it, and improved on it. And a lot of those people were not Guido or even of the current PythonLabs team. I've never really believed in the 'true cross-platform nature' of Python, mostly because I know it can't *really* be true. Most of my scripts are not portably to non-UNIX platforms, due to the use of sockets, pipes, and hardcoded filepaths (/usr/...). Even if I did, I can hardly agree that because there is no portable way (if any at all) to find out howmany diskspace is free, it isn't cross-platform. Just *because* it lacks that function makes it more cross-platform: platforms might not have the concept of 'free space' :) -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Thomas Wouters wrote:
I've never really believed in the 'true cross-platform nature' of Python, mostly because I know it can't *really* be true. Most of my scripts are not portably to non-UNIX platforms, due to the use of sockets, pipes, and hardcoded filepaths (/usr/...). Even if I did, I can hardly agree that because there is no portable way (if any at all) to find out howmany diskspace is free, it isn't cross-platform. Just *because* it lacks that function makes it more cross-platform: platforms might not have the concept of 'free space' :)
Hmm, that means we better strip the standard library off most of its modules (why not all?), because the less content there is, the more cross-platform it will be, right? Well, if the concept is not there, simply throw a neat ConceptException! ;-) Dinu
Here's a radical suggestion: Start a x-platform project on SourceForge, devoted to producing a C library with a common interface for platform-dependent crud like "how big is this file?" and "how many bytes free on this disk?" and "how can I execute a shell command in a portable way?" (e.g., Tcl's "exec" emulates a subset of Bourne shell syntax, including redirection and pipes, even on Windows 3.1). OK, that's too useful. Nevermind ...
tim wrote:
Here's a radical suggestion: Start a x-platform project on SourceForge, devoted to producing a C library with a common interface for platform-dependent crud like "how big is this file?" and "how many bytes free on this disk?" and "how can I execute a shell command in a portable way?" (e.g., Tcl's "exec" emulates a subset of Bourne shell syntax, including redirection and pipes, even on Windows 3.1).
counter-suggestion: add partial os.statvfs emulation to the posix module for Windows (and Mac), and write helpers for shutil to do the fancy stuff you mentioned before. Cheers /F
[Fredrik Lundh]
counter-suggestion:
add partial os.statvfs emulation to the posix module for Windows (and Mac), and write helpers for shutil to do the fancy stuff you mentioned before.
One of the best things Python ever did was to introduce os.path.getsize() + friends, saving the bulk of the world from needing to wrestle with the obscure Unix stat() API. os.chmod() is another x-platform teachability pain; if there's anything worth knowing in the bowels of statvfs(), let's please spell it in a human-friendly way from the start.
Tim Peters wrote:
One of the best things Python ever did was to introduce os.path.getsize() + friends, saving the bulk of the world from needing to wrestle with the obscure Unix stat() API.
yup (I remember lobbying for those years ago), but that doesn't mean that we cannot make already existing low-level APIs work on as many platforms as possible... (just like os.popen etc) adding os.statvfs for windows is pretty much a bug fix (for 2.1?), but adding a new API is not (2.2).
os.chmod() is another x-platform teachability pain
shutil.chmod("file", "g+x"), anyone?
if there's anything worth knowing in the bowels of statvfs(), let's please spell it in a human-friendly way from the start.
how about os.path.getfreespace("path") and os.path.gettotalspace("path") ? Cheers /F
Fredrik Lundh wrote:
Tim Peters wrote:
One of the best things Python ever did was to introduce os.path.getsize() + friends, saving the bulk of the world from needing to wrestle with the obscure Unix stat() API.
yup (I remember lobbying for those years ago), but that doesn't mean that we cannot make already existing low-level APIs work on as many platforms as possible...
(just like os.popen etc)
adding os.statvfs for windows is pretty much a bug fix (for 2.1?), but adding a new API is not (2.2).
os.chmod() is another x-platform teachability pain
shutil.chmod("file", "g+x"), anyone?
Wasn't shutil declared obsolete ?
if there's anything worth knowing in the bowels of statvfs(), let's please spell it in a human-friendly way from the start.
how about os.path.getfreespace("path") and os.path.gettotalspace("path") ?
Anybody care to add the missing parts in: import sys,os try: os.statvfs except AttributeError: # Win32 implementation... # Mac implementation... pass else: import statvfs def freespace(path): """ freespace(path) -> integer Return the number of bytes available to the user on the file system pointed to by path.""" s = os.statvfs(path) return s[statvfs.F_BAVAIL] * long(s[statvfs.F_BSIZE]) if __name__=='__main__': path = sys.argv[1] print 'Free space on %s: %i kB (%i bytes)' % (path, freespace(path) / 1024, freespace(path)) totalspace() should be just as easy to add and I'm pretty sure that you can get that information on *all* platforms (not necessarily using the same APIs though). -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/
M.-A. Lemburg wrote:
Wasn't shutil declared obsolete ?
<blink> What?! -- --- Aahz (@pobox.com) Hugs and backrubs -- I break Rule 6 http://www.rahul.net/aahz Androgynous poly kinky vanilla queer het I don't really mind a person having the last whine, but I do mind someone else having the last self-righteous whine.
Aahz Maruch wrote:
M.-A. Lemburg wrote:
Wasn't shutil declared obsolete ?
<blink> What?!
Guido once pronounced on this... mostly because of the comment at the top regarding cross-platform compatibility: """Utility functions for copying files and directory trees. XXX The functions here don't copy the resource fork or other metadata on Mac. """ -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/
"M.-A. Lemburg" <mal@lemburg.com>:
XXX The functions here don't copy the resource fork or other metadata on Mac.
Wouldn't it be better to fix these functions on the Mac instead of depriving everyone else of them? Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
Greg Ewing:
"M.-A. Lemburg" <mal@lemburg.com>:
XXX The functions here don't copy the resource fork or other metadata on Mac.
Wouldn't it be better to fix these functions on the Mac instead of depriving everyone else of them?
Then they should be fixed for Windows as well where they don't copy secondary forks either. While not used much by native code, forks are commonly used on NT servers which serve files to Macintoshes. There is also the issue of other metadata. Should shutil optionally copy ownership information? Access Control Lists? Summary information? A really well designed module here could be very useful but quite some work. Neil
On 22 March 2001, Neil Hodgson said:
Then they should be fixed for Windows as well where they don't copy secondary forks either. While not used much by native code, forks are commonly used on NT servers which serve files to Macintoshes.
There is also the issue of other metadata. Should shutil optionally copy ownership information? Access Control Lists? Summary information? A really well designed module here could be very useful but quite some work.
There's a pretty good 'copy_file()' routine in the Distutils; I found shutil quite inadequate, so rolled my own. Jack Jansen patched it so it does the "right thing" on Mac OS. By now, it has probably copied many files all over the place on all of your computers, so it sounds like it works. ;-) See the distutils.file_util module for implementation and documentation. Greg -- Greg Ward - Unix bigot gward@python.net http://starship.python.net/~gward/ Sure, I'm paranoid... but am I paranoid ENOUGH?
"GE" == Greg Ewing <greg@cosc.canterbury.ac.nz> writes:
GE> Wouldn't it be better to fix these functions on the Mac GE> instead of depriving everyone else of them? Either way, shutil sure is useful!
"GE" == Greg Ewing <greg@cosc.canterbury.ac.nz> writes:
GE> Wouldn't it be better to fix these functions on the Mac GE> instead of depriving everyone else of them?
Either way, shutil sure is useful!
Yes, but deceptively so. What should we do? Anyway, it doesn't appear to be officially deprecated yet (can't see it in the docs) and I think it may be best to keep it that way. --Guido van Rossum (home page: http://www.python.org/~guido/)
Hi, Guido van Rossum schrieb:
> "GE" == Greg Ewing <greg@cosc.canterbury.ac.nz> writes:
GE> Wouldn't it be better to fix these functions on the Mac GE> instead of depriving everyone else of them?
Either way, shutil sure is useful!
Yes, but deceptively so. What should we do? Anyway, it doesn't appear to be officially deprecated yet (can't see it in the docs) and I think it may be best to keep it that way.
A very simple idea would be, to provide two callback hooks, which will be invoked by each call to copyfile or remove. Example: Someone uses the package netatalk on Linux to provide file services to Macs. netatalk stores the resource forks in hidden sub directories called .AppleDouble. The callback function could than copy the .AppleDouble/files around using shutil.copyfile itself. Regards, Peter
pf@artcom-gmbh.de (Peter Funk):
netatalk stores the resource forks in hidden sub directories called .AppleDouble.
None of that is relevant if the copying is being done from the Mac end. To the Mac it just looks like a normal Mac file, so the standard Mac file-copying techniques will work. No need for any callbacks. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
Hi,
pf@artcom-gmbh.de (Peter Funk):
netatalk stores the resource forks in hidden sub directories called .AppleDouble.
Greg Ewing:
None of that is relevant if the copying is being done from the Mac end. To the Mac it just looks like a normal Mac file, so the standard Mac file-copying techniques will work. No need for any callbacks.
You are right and I know this. But if you program an application, which should work on the Unix/Linux side (for example a filemanager or something similar), you have to pay attention to this files on your own. The same holds true for thumbnail images usually stored in a .xvpics subdirectory. All current filemanagers on Linux (KDE kfm, Gnome gmc) are flawed in this respect. Regards, Peter P.S.: I'm not going to write a GUI file manager in Python and using shutil right now. So this discussion is somewhat academic. -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)
pf@artcom-gmbh.de (Peter Funk):
All current filemanagers on Linux (KDE kfm, Gnome gmc) are flawed in this respect.
I don't think you can call that a "flaw", given that these filemanagers are only designed to deal with Unix file systems. I think it's reasonable to only expect things in the platform os module to deal with the platform's native file system. Trying to anticipate how every platform's cross-platform file servers for all other platforms are going to store their data just isn't practical. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
All current filemanagers on Linux (KDE kfm, Gnome gmc) are flawed in this respect.
I don't think you can call that a "flaw", given that these filemanagers are only designed to deal with Unix file systems.
I think it's reasonable to only expect things in the platform os module to deal with the platform's native file system. Trying to anticipate how every platform's cross-platform file servers for all other platforms are going to store their data just isn't practical.
You say that now, but as such cross-system servers become more common, we should expect the tools to deal with them well, rather than complain "the other guy doesn't play by our rules". --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum <guido@digicool.com> writes:
All current filemanagers on Linux (KDE kfm, Gnome gmc) are flawed in this respect.
I don't think you can call that a "flaw", given that these filemanagers are only designed to deal with Unix file systems.
I think it's reasonable to only expect things in the platform os module to deal with the platform's native file system. Trying to anticipate how every platform's cross-platform file servers for all other platforms are going to store their data just isn't practical.
You say that now, but as such cross-system servers become more common, we should expect the tools to deal with them well, rather than complain "the other guy doesn't play by our rules".
So, a goal for 2.2: getting moving/copying/deleting of files and directories working properly (ie. using native APIs) on all major supported platforms, with all the legwork that implies. We're not really very far from this now, are we? Perhaps (the functionality of) shutil.{rmtree,copy,copytree} should move into os and if necessary be implemented in nt or dos or mac or whatever. Any others? Cheers, M. -- 39. Re graphics: A picture is worth 10K words - but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
So, a goal for 2.2: getting moving/copying/deleting of files and directories working properly (ie. using native APIs) on all major supported platforms, with all the legwork that implies. We're not really very far from this now, are we? Perhaps (the functionality of) shutil.{rmtree,copy,copytree} should move into os and if necessary be implemented in nt or dos or mac or whatever. Any others?
Given that it's currently in shutil, please just consider improving that, unless you believe that the basic API should be completely different. This sounds like something PEP-worthy! --Guido van Rossum (home page: http://www.python.org/~guido/)
On 26 March 2001, Michael Hudson said:
So, a goal for 2.2: getting moving/copying/deleting of files and directories working properly (ie. using native APIs) on all major supported platforms, with all the legwork that implies. We're not really very far from this now, are we? Perhaps (the functionality of) shutil.{rmtree,copy,copytree} should move into os and if necessary be implemented in nt or dos or mac or whatever. Any others?
The code already exists, in distutils/file_utils.py. It's just a question of giving it a home in the main body of the standard library. (FWIW, the reasons I didn't patch shutil.py are 1) I didn't want to be constraint by backward compatibility, and 2) I didn't have a time machine to go back and change shutil.py in all existing 1.5.2 installations.) Greg -- Greg Ward - just another /P(erl|ython)/ hacker gward@python.net http://starship.python.net/~gward/ No animals were harmed in transmitting this message.
Guido van Rossum writes:
Yes, but deceptively so. What should we do? Anyway, it doesn't appear to be officially deprecated yet (can't see it in the docs) and I think it may be best to keep it that way.
I don't think it's deceived me yet! I see no reason to deprecate it, and I don't recall anyone telling me it should be. Nor do I recall a discussion here suggesting that it should be. If it has hidden corners that I just haven't run into (and it *has* been pointed out that it does have corners, at least on some platforms), why don't we just consider those bugs that can be fixed? -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations
dinu wrote:
Well, this is the usual "If you need it, do it yourself!" answer, that bites the one who dares to speak up for all those hundreds who don't... isn't it?
fwiw, Python already supports this for real Unix platforms:
os.statvfs("/") (8192, 512, 524288, 365788, 348336, 600556, 598516, 598516, 0, 255)
here, the root disk holds 524288x512 bytes, with 348336x512 bytes free for the current user, and 365788x512 bytes available for root. (the statvfs module contains indices for accessing this "struct") Implementing a small subset of statvfs for Windows wouldn't be that hard (possibly returning None for fields that don't make sense, or are too hard to figure out). (and with win32all, I'm sure it can be done without any C code). Cheers /F
Fredrik Lundh wrote:
fwiw, Python already supports this for real Unix platforms:
os.statvfs("/") (8192, 512, 524288, 365788, 348336, 600556, 598516, 598516, 0, 255)
here, the root disk holds 524288x512 bytes, with 348336x512 bytes free for the current user, and 365788x512 bytes available for root.
(the statvfs module contains indices for accessing this "struct")
Implementing a small subset of statvfs for Windows wouldn't be that hard (possibly returning None for fields that don't make sense, or are too hard to figure out).
(and with win32all, I'm sure it can be done without any C code).
Cheers /F
Everything correct! I'm just trying to make the point that from a user perspective it would be more complete to have such a function in the os module (where it belongs), that would also work on Macs e.g., as well as more conveniant, because even when that existed in modules like win32api (where it does) and in one of the (many) mac* ones (which I don't know yet if it does) it would save you the if-statement on sys.platform. It sounds silly to me if people now pushed into learning Py- thon as a first programming language had to use such state- ments to get along, but were given the 'gift' of 1/2 = 0.5 which we seem to spend an increasing amount of brain cycles on... Regards, Dinu -- Dinu C. Gherman ReportLab Consultant - http://www.reportlab.com ................................................................ "The only possible values [for quality] are 'excellent' and 'in- sanely excellent', depending on whether lives are at stake or not. Otherwise you don't enjoy your work, you don't work well, and the project goes down the drain." (Kent Beck, "Extreme Programming Explained")
Dinu Gherman wrote: [disk free space...]
I'm just trying to make the point that from a user perspective it would be more complete to have such a function in the os module (where it belongs), that would also work on Macs e.g., as well as more conveniant, because even when that existed in modules like win32api (where it does) and in one of the (many) mac* ones (which I don't know yet if it does) it would save you the if-statement on sys.platform.
Considering that: - it's not uncommon to map things into the filesystem's namespace for which "free space" is meaningless - for network mapped storage space it's quite likely you can't get a meaningful number - for compressed file systems the number will be inaccurate - even if you get an accurate answer, the space may not be there when you go to use it (so need try... except anyway) I find it perfectly sensible that Python does not dignify this mess with an official function. - Gordon
Gordon McMillan wrote:
Considering that: - it's not uncommon to map things into the filesystem's namespace for which "free space" is meaningless
Unless I'm totally stupid, I see the concept of "free space" as being tied to the *device*, not to anything being mapped to it or not.
- for network mapped storage space it's quite likely you can't get a meaningful number
Fine, then let's play the exception blues...
- for compressed file systems the number will be inaccurate
Then why is the OS function call there...? And: nobody can *seri- ously* expect an accurate figure of the remaining space for com- pressed file systems, anyway, and I think nobody does! But there will always be some number >= 0 of uncompressed available bytes left.
- even if you get an accurate answer, the space may not be there when you go to use it (so need try... except anyway)
The same holds for open(path, 'w') - and still this function is considered useful, isn't it?!
I find it perfectly sensible that Python does not dignify this mess with an official function.
Well, I have yet to see a good argument against this... Regards, Dinu
I'm just trying to make the point that from a user perspective it would be more complete to have such a function in the os module (where it belongs), that would also work on Macs e.g., as well as more conveniant, because even when that existed in modules like win32api (where it does) and in one of the (many) mac* ones (which I don't know yet if it does) it would save you the if-statement on sys.platform.
Yeah, yeah, yeah. Whine, whine, whine. As has been made abundantly clear, doing this cross-platform requires a lot of detailed platform knowledge. We at PythonLabs don't have all the wisdom, and we often rely on outsiders to help us out. Until now, finding out how much free space there is on a disk hasn't been requested much (in fact I don't recall seeing a request for it before). That's why it isn't already there -- that plus the fact that traditionally on Unix this isn't easy to find out (statvfs didn't exist when I wrote most of the posix module). I'm not against adding it, but I'm not particularly motivated to add it myself because I have too much to do already (and the same's true for all of us here at PythonLabs).
It sounds silly to me if people now pushed into learning Py- thon as a first programming language had to use such state- ments to get along, but were given the 'gift' of 1/2 = 0.5 which we seem to spend an increasing amount of brain cycles on...
I would hope that you agree with me though that the behavior of numbers is a lot more fundamental to education than finding out available disk space. The latter is just a system call of use to a small number of professionals. The former has usability implications for all Python users. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
Yeah, yeah, yeah. Whine, whine, whine. [...] I'm not against adding it, but I'm not particularly motivated to add it myself [...]
Good! After doing a quick research on Google it turns out this function is also available on MacOS, as expected, named PBHGetVInfo(). See this page for details plus a sample Pascal function using it: http://developer.apple.com/techpubs/mac/Files/Files-96.html I'm not sure what else is needed to use it, but at least it's there and maybe somebody more of a Mac expert than I am could help out here... I'm going to continue this on c.l.p. in the original thread... Hey, maybe it is already available in one of the many mac packages. Well, I'll start some digging...
I would hope that you agree with me though that the behavior of numbers is a lot more fundamental to education than finding out available disk space. The latter is just a system call of use to a small number of professionals. The former has usability implications for all Python users.
I do agree, sort of, but it appears that often there is much more work being spent on fantastic new features, where im- proving existing ones would also be very beneficial. For me at least, there is considerable value in a system's consisten- cy and completeness and not only in its number of features. Thanks everybody (now that Guido has spoken we have to finish)! It was fun! :) Regards, Dinu -- Dinu C. Gherman ReportLab Consultant - http://www.reportlab.com ................................................................ "The only possible values [for quality] are 'excellent' and 'in- sanely excellent', depending on whether lives are at stake or not. Otherwise you don't enjoy your work, you don't work well, and the project goes down the drain." (Kent Beck, "Extreme Programming Explained")
Fredrik Lundh wrote:
dinu wrote:
Well, this is the usual "If you need it, do it yourself!" answer, that bites the one who dares to speak up for all those hundreds who don't... isn't it?
fwiw, Python already supports this for real Unix platforms:
os.statvfs("/") (8192, 512, 524288, 365788, 348336, 600556, 598516, 598516, 0, 255)
here, the root disk holds 524288x512 bytes, with 348336x512 bytes free for the current user, and 365788x512 bytes available for root.
(the statvfs module contains indices for accessing this "struct")
Implementing a small subset of statvfs for Windows wouldn't be that hard (possibly returning None for fields that don't make sense, or are too hard to figure out).
(and with win32all, I'm sure it can be done without any C code).
It seems that all we need is Jack to port this to the Mac and we have a working API here :-) Let's do it... import sys,os try: os.statvfs except KeyError: # Win32 implementation... # Mac implementation... pass else: import statvfs def freespace(path): """ freespace(path) -> integer Return the number of bytes available to the user on the file system pointed to by path.""" s = os.statvfs(path) return s[statvfs.F_BAVAIL] * long(s[statvfs.F_BSIZE]) if __name__=='__main__': path = sys.argv[1] print 'Free space on %s: %i kB (%i bytes)' % (path, freespace(path) / 1024, freespace(path)) -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/
mal wrote:
return s[statvfs.F_BAVAIL] * long(s[statvfs.F_BSIZE])
F_FRAVAIL, not F_BAVAIL (and my plan is to make a statvfs subset available on all platforms, which makes your code even simpler...) Cheers /F
(and my plan is to make a statvfs subset available on all platforms, which makes your code even simpler...)
windows patch here: http://sourceforge.net/tracker/index.php?func=detail&aid=410547&group_id=5470&atid=305470 guess it has to wait for 2.2, though... Cheers /F
On Mon, 19 Mar 2001 12:57:49 +0100, Dinu Gherman <gherman@darwin.in-berlin.de> wrote:
I wrote on comp.lang.python today:
is there a simple way (or any way at all) to find out for any given hard disk how much free space is left on that device? I looked into the os module, but either not hard enough or there is no such function. Of course, the ideal solution would be platform-independant, too... :)
Is there any good reason for not having a cross-platform solution to this? I'm certainly not the first to ask for such a function and it certainly exists for all platforms, doesn't it?
No, it doesn't. Specifically, the information is always unreliable, especially when you start considering NFS mounted directories and things like that.
I know that OS differ in the services they provide, but in this case it seems to me that each one *must* have such a function
This doesn't have a *meaning* in UNIX. (In the sense that I can think of so many special cases, that having a half-working implementation is worse then nothing) -- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez@debian.org |http://www.{python,debian,gnu}.org
participants (17)
-
aahz＠rahul.net -
barry＠digicool.com -
Dinu Gherman -
Fred L. Drake, Jr. -
Fredrik Lundh -
Fredrik Lundh -
Gordon McMillan -
Greg Ewing -
Greg Ward -
Guido van Rossum -
M.-A. Lemburg -
Michael Hudson -
Moshe Zadka -
Neil Hodgson -
pf＠artcom-gmbh.de -
Thomas Wouters -
Tim Peters