Portable and OS-dependent module idea/proposal/brain fart

I posted a note to the main list yesterday in response to Dan Connolly's complaint that the os module isn't very portable. I saw no followups (it's amazing how fast a thread can die out :-), but I think it's a reasonable idea, perhaps for Python 2.0, so I'll repeat it here to get some feedback from people more interesting in long-term Python developments. The basic premise is that for each platform on which Python runs there are portable and nonportable interfaces to the underlying operating system. The term POSIX has some portability connotations, so let's assume that the posix module exposes the portable subset of the OS interface. To keep things simple, let's also assume there are only three supported general OS platforms: unix, nt and mac. The proposal then is that importing the platform's module by name will import both the portable and non-portable interface elements. Importing the posix module will import just that portion of the interface that is truly portable across all platforms. To add new functionality to the posix interface it would have to be added to all three platforms. The posix module will be able to ferret out the platform it is running on and import the correct OS-independent posix implementation: import sys _plat = sys.platform del sys if _plat == "mac": from posixmac import * elif _plat == "nt": from posixnt import * else: from posixunix import * # some unix variant The platform-dependent module would simply import everything it could, e.g.: from posixunix import * from nonposixunix import * The os module would vanish or be deprecated with its current behavior intact. The documentation would be modified so that the posix module documents the portable interface and the OS-dependent module's documentation documents the rest and just refers users to the posix module docs for the portable stuff. In theory, this could be done for 1.6, however as I've proposed it, the semantics of importing the posix module would change. Dan Connolly probably isn't going to have a problem with that, though I suppose Guido might... If this idea is good enough for 1.6, perhaps we leave os and posix module semantics alone and add a module named "portable", "portableos" or "portableposix" or something equally arcane. Skip Montanaro | http://www.mojam.com/ skip@mojam.com | http://www.musi-cal.com/~skip/ 847-971-7098

And the advantage of this would be...? Basically, it seems you're just renaming the functionality of os to posix. --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido> And the advantage of this would be...? Guido> Basically, it seems you're just renaming the functionality of os Guido> to posix. I see a few advantages. 1. We will get the meaning of the noun "posix" more or less right. Programmers coming from other languages are used to thinking of programming to a POSIX API or the "POSIX subset of the OS API". Witness all the "#ifdef _POSIX" in the header files on my Linux box In Python, the exact opposite is true. Importing the posix module is documented to be the non-portable way to interface to Unix platforms. 2. You would make it clear on all platforms when you expect to be programming in a non-portable fashion, by importing the platform-specific os (unix, nt, mac). "import unix" would mean I expect this code to only run on Unix machines. You could argue that you are declaring your non-portability by importing the posix module today, but to the casual user or to a new Python programmer with a C or C++ background, that won't be obvious. 3. If Dan Connolly's contention is correct, importing the os module today is not all that portable. I can't really say one way or the other, because I'm lucky enough to be able to confine my serious programming to Unix. I'm sure there's someone out there that can try the following on a few platforms: import os dir(os) and compare the output. Skip

Skip Montanaro writes:
To my mind, POSIX == Unix; other platforms may have bits of POSIX-ish functionality, but most POSIX functions will only be found on Unix systems. One of my projects for 1.6 is to go through the O'Reilly POSIX book and add all the missing calls to the posix modules. Practically none of those functions would exist on Windows or Mac. Perhaps it's really a documentation fix: the os module should document only those features common to all of the big 3 platforms (Unix, Windows, Mac), and have pointers to a section for each of the platform-specific modules, listing the platform-specific functions. -- A.M. Kuchling http://starship.python.net/crew/amk/ Setting loose on the battlefield weapons that are able to learn may be one of the biggest mistakes mankind has ever made. It could also be one of the last. -- Richard Forsyth, "Machine Learning for Expert Systems"

Andrew> Perhaps it's really a documentation fix: the os module should Andrew> document only those features common to all of the big 3 Andrew> platforms (Unix, Windows, Mac), and have pointers to a section Andrew> for each of the platform-specific modules, listing the Andrew> platform-specific functions. Perhaps. Should that read ... the os module should *expose* only those features common to all of the big 3 platforms ... ? Skip

... the os module should *expose* only those features common to all of the big 3 platforms ...
Why? My experience has been that functionality that was thought to be Unix specific has gradually become available on other platforms, which makes it hard to decide in which module a function should be placed. The proper test for portability of a program is not whether it imports certain module names, but whether it uses certain functions from those modules (and whether it uses them in a portable fashion). As platforms evolve, a program that was previously thought to be non-portable might become more portable. --Guido van Rossum (home page: http://www.python.org/~guido/)

[Skip Montanaro]
There's no need to, Skip. Just read the os module docs; where a function says, e.g., "Availability: Unix.", it doesn't show up on a Windows or Mac box. In that sense using (some) os functions is certainly unportable. But I have no sympathy for the phrasing of Dan's complaint: if he calls os.getegid(), *he* knows perfectly well that's a Unix-specific function, and expressing outrage over it not working on NT is disingenuous. OTOH, I don't think you're going to find anything in the OS module documented as available only on Windows or only on Macs, and some semi-portable functions (notoriosly chmod) are documented in ways that make sense only to Unixheads. This certainly gives a strong impression of Unix-centricity to non-Unix weenies, and has got to baffle true newbies completely. So 'twould be nice to have a basic os module all of whose functions "run everywhere", whose interfaces aren't copies of cryptic old Unixisms, and whose docs are platform neutral. If Guido is right that the os functions tend to get more portable over time, fine, that module can grow over time too. In the meantime, life would be easier for everyone except Python's implementers.

Tim Peters writes:
OTOH, I don't think you're going to find anything in the OS module documented as available only on Windows or only on Macs, and some
Tim, Actually, the spawn*() functions are included in os and are documented as Windows-only, along with the related P_* constants. These are provided by the nt module.
everywhere", whose interfaces aren't copies of cryptic old Unixisms, and whose docs are platform neutral.
I'm alwasy glad to see documentation patches, or even pointers to specific problems. Being a Unix-weenie myself, making the documentation more readable to Windows-weenies can be difficult at times. But given useful pointers, I can usually pull it off, or at least drive someone who canto do so. ;-) -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives

[Fred L. Drake, Jr.]
I stand corrected, Fred -- so how do the Unix dweebs like this Windows crap cluttering "their" docs <wink>? [Tim, pitching a portable sane interface to a portable sane subset of os functionality]
No, it's deeper than that. Some of the inherited Unix interfaces are flatly incomprehensible to anyone other than a Unix-head, but the functionality is supplied only in that form (docs may ease the pain, but the interfaces still suck); for example, mkdir (path[, mode]) Create a directory named path with numeric mode mode. The default mode is 0777 (octal). On some systems, mode is ignored. Where it is used, the current umask value is first masked out. Availability: Macintosh, Unix, Windows. If you have a sister or parent or 3-year-old child (they're all equivalent for this purpose <wink>), just imagine them reading that. If you can't, I'll have my sister call you <wink>. Raw numeric permission modes, octal mode notation, and the "umask" business are Unix-specific -- and even Unices supply symbolic ways to specify permissions. chmod is likely the one I hear the most gripes about. Windows heads are looking to change "file attributes", the name "chmod" is gibberish to them, most of the Unix mode bits make no sense under Windows (& contra Guido's optimism, never will) even if you know the secret octal code, and Windows has several attributes (hidden bit, system bit, archive bit) chmod can't get at. The only portable functionality here is the write bit, but no non-Unix person could possibly guess either that chmod is the function they need, or what to type after someone tells them it's chmod. So this is less a doc issue than that more of os needs to become more like os.path (i.e., intelligently named functions with intelligently abstracted interfaces). never-grasped-what-ken-thompson-had-against-trailing-"e"s-ly y'rs - tim

Tim> chmod is likely the one I hear the most gripes about. Windows Tim> heads are looking to change "file attributes", the name "chmod" is Tim> gibberish to them Well, we could confuse everyone and rename "chmod" to "chfat" (is that like file system liposuction?). Windows probably has an equivalent function whose name is 17 characters long which we'd all love to type, I'm sure. ;-) Tim> most of the Unix mode bits make no sense under Windows (& contra Tim> Guido's optimism, never will) even if you know the secret octal Tim> code ... It beats a secret handshake. Imagine all the extra peripherals we'd have to make available for everyone's computer. ;-) Tim> So this is less a doc issue than that more of os needs to become Tim> more like os.path (i.e., intelligently named functions with Tim> intelligently abstracted interfaces). Hasn't Guido's position been that the interface modules like os, posix, etc are just a thin layer over the underlying API (Guido: note how I cleverly attributed this position to you but also placed the responsibility for correctness on your head!)? If that's the case, perhaps we should provide a slightly higher level module that abstracts the file system as objects, and adopts a more user-friendly approach to the secret octal codes. Those of us worried about job security could continue to use the lower level module and leave the higher level interface for former Visual Basic programmers. Tim> never-grasped-what-ken-thompson-had-against-trailing-"e"s-ly y'rs - maybe-the-"e"-key-stuck-on-his-TTY-ly y'rs... Skip Montanaro | http://www.mojam.com/ skip@mojam.com | http://www.musi-cal.com/~skip/ 847-971-7098 | Python: Programming the way Guido indented...

Skip Montanaro writes:
whose name is 17 characters long which we'd all love to type, I'm sure. ;-)
Just 17? ;-)
Sounds like some doc improvements can really help improve things, at least in the short term.
I'm all for an object interface to a logical filesystem; having had to write just such a thing in Java not long ago, and we have a similar construct in Python (not by me, though), that we use in our Knowbot work. -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives

"TP" == Tim Peters <tim_one@email.msn.com> writes:
TP> Well, don't read anything unintended into this, but Guido *is* TP> out of town, and you *do* have the power to check in code TP> outside the doc subtree ... TP> barry-will-help-he's-been-itching-to-revolt-too<wink>-ly y'rs I'll bring the pitchforks if you bring the torches! -Barry

> I'm all for an object interface to a logical filesystem; having had to > write just such a thing in Java not long ago, and we have a similar > construct in Python (not by me, though), that we use in our Knowbot > work. Fred, Since this is the dev group, how about showing us the Knowbot's logical filesystem API, and let's do some dev-ing... Skip Montanaro | http://www.mojam.com/ skip@mojam.com | http://www.musi-cal.com/~skip/ 847-971-7098 | Python: Programming the way Guido indented...

Skip Montanaro writes:
Since this is the dev group, how about showing us the Knowbot's logical filesystem API, and let's do some dev-ing...
Well, I took a look at it, and I must confess it's just not really different from the set of interfaces in the os module; the important point is that they are methods instead of functions (other than a few data items: sep, pardir, curdir). The path attribute provided the same interface as os.path. Its only user-visible state is the current-directory setting, which may or may not be that useful. We left off chmod(), which would make Tim happy, but that was only because it wasn't meaningful in context. We'd have to add it (or something equivalent) for a general purpose filesystem object. So Tim's only happy if he can come up with a general interface that is actually portable (consider my earlier comments on setreadonly()). On the other hand, you don't need chmod() or anything like it for most situations where a filesystem object would be useful. An FTPFilesystem class would not be hard to write! -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives

[Fred L. Drake, Jr.]
I'd be appalled to see chmod go away; for many people it's comfortable and useful. I want *another* way, to do what little bit is portable in a way that doesn't require first mastering a badly designed interface from a dying OS <wink>.
I don't care about general here; making up a general new way to spell everything that everyone may want to do under every OS would create an interface even worse than chmod's. My sister doesn't want to create files that are read-only to the world but writable to her group -- she just wants to mark certain precious files as read-only to minimize the chance of accidental destruction. What she wants is easy to do under Windows or Unix, and I expect she's the norm rather than the exception.
An OO filesystem object with a .makereadonly method suits me fine <wink>.

[Skip Montanaro]
Well, we could confuse everyone and rename "chmod" to "chfat" ...
I don't want to rename anything, nor do I want to use MS-specific names. chmod is both the wrong spelling & the wrong functionality for all non-Unix systems. os.path did a Good Thing by, e.g., introducing getmtime(), despite that everyone knows <wink> it's just os.stat()[8]. New isreadonly(path) and setreadonly(path) are more what I'm after; nothing beyond that is portable, & never will be.
Windows probably has an equivalent function whose name is 17 characters long
Indeed, SetFileAttributes is exactly 17 characters long (you moonlighting on NT, Skip?!). But while Windows geeks would like to use that, it's both the wrong spelling & the wrong functionality for all non-Windows systems.
Like that, yes.
You're just *begging* Guido to make the Python2 os module take all of its names from the Win32 API <wink>. it's-no-lamer-to-be-ignorant-of-unix-names-than-it-is- to-be-ignorant-of-chinese-ly y'rs - tim

Tim Peters writes:
Tim, I think we can simply declare that isreadonly() checks that the file doesn't allow the user to read it, but setreadonly() sounds to me like it wouldn't be portable to Unix. There's more than one (reasonable) way to make a file unreadable to a user just by manipulating permission bits, and which is best will vary according to both the user and the file's existing permissions. -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives

[Fred L. Drake, Jr.]
I think we can simply declare that isreadonly() checks that the file doesn't allow the user to read it,
Had more in mind that the file doesn't allow the user to write it <wink>.
"Portable" implies least common denominator, and the plain meaning of read-only is that nobody (whether owner, group or world in Unix) has write permission. People wanting something beyond that are going beyond what's portable, and that's fine -- I'm not suggesting getting rid of chmod for Unix dweebs. But by the same token, Windows dweebs should get some other (as non-portable as chmod) way to fiddle the bits important on *their* OS (only one of which chmod can affect). Billions of newbies will delightedly stick to the portable interface with the name that makes sense. the-percentage-of-programmers-doing-systems-programming-shrinks-by- the-millisecond-ly y'rs - tim

And the advantage of this would be...? Basically, it seems you're just renaming the functionality of os to posix. --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido> And the advantage of this would be...? Guido> Basically, it seems you're just renaming the functionality of os Guido> to posix. I see a few advantages. 1. We will get the meaning of the noun "posix" more or less right. Programmers coming from other languages are used to thinking of programming to a POSIX API or the "POSIX subset of the OS API". Witness all the "#ifdef _POSIX" in the header files on my Linux box In Python, the exact opposite is true. Importing the posix module is documented to be the non-portable way to interface to Unix platforms. 2. You would make it clear on all platforms when you expect to be programming in a non-portable fashion, by importing the platform-specific os (unix, nt, mac). "import unix" would mean I expect this code to only run on Unix machines. You could argue that you are declaring your non-portability by importing the posix module today, but to the casual user or to a new Python programmer with a C or C++ background, that won't be obvious. 3. If Dan Connolly's contention is correct, importing the os module today is not all that portable. I can't really say one way or the other, because I'm lucky enough to be able to confine my serious programming to Unix. I'm sure there's someone out there that can try the following on a few platforms: import os dir(os) and compare the output. Skip

Skip Montanaro writes:
To my mind, POSIX == Unix; other platforms may have bits of POSIX-ish functionality, but most POSIX functions will only be found on Unix systems. One of my projects for 1.6 is to go through the O'Reilly POSIX book and add all the missing calls to the posix modules. Practically none of those functions would exist on Windows or Mac. Perhaps it's really a documentation fix: the os module should document only those features common to all of the big 3 platforms (Unix, Windows, Mac), and have pointers to a section for each of the platform-specific modules, listing the platform-specific functions. -- A.M. Kuchling http://starship.python.net/crew/amk/ Setting loose on the battlefield weapons that are able to learn may be one of the biggest mistakes mankind has ever made. It could also be one of the last. -- Richard Forsyth, "Machine Learning for Expert Systems"

Andrew> Perhaps it's really a documentation fix: the os module should Andrew> document only those features common to all of the big 3 Andrew> platforms (Unix, Windows, Mac), and have pointers to a section Andrew> for each of the platform-specific modules, listing the Andrew> platform-specific functions. Perhaps. Should that read ... the os module should *expose* only those features common to all of the big 3 platforms ... ? Skip

... the os module should *expose* only those features common to all of the big 3 platforms ...
Why? My experience has been that functionality that was thought to be Unix specific has gradually become available on other platforms, which makes it hard to decide in which module a function should be placed. The proper test for portability of a program is not whether it imports certain module names, but whether it uses certain functions from those modules (and whether it uses them in a portable fashion). As platforms evolve, a program that was previously thought to be non-portable might become more portable. --Guido van Rossum (home page: http://www.python.org/~guido/)

[Skip Montanaro]
There's no need to, Skip. Just read the os module docs; where a function says, e.g., "Availability: Unix.", it doesn't show up on a Windows or Mac box. In that sense using (some) os functions is certainly unportable. But I have no sympathy for the phrasing of Dan's complaint: if he calls os.getegid(), *he* knows perfectly well that's a Unix-specific function, and expressing outrage over it not working on NT is disingenuous. OTOH, I don't think you're going to find anything in the OS module documented as available only on Windows or only on Macs, and some semi-portable functions (notoriosly chmod) are documented in ways that make sense only to Unixheads. This certainly gives a strong impression of Unix-centricity to non-Unix weenies, and has got to baffle true newbies completely. So 'twould be nice to have a basic os module all of whose functions "run everywhere", whose interfaces aren't copies of cryptic old Unixisms, and whose docs are platform neutral. If Guido is right that the os functions tend to get more portable over time, fine, that module can grow over time too. In the meantime, life would be easier for everyone except Python's implementers.

Tim Peters writes:
OTOH, I don't think you're going to find anything in the OS module documented as available only on Windows or only on Macs, and some
Tim, Actually, the spawn*() functions are included in os and are documented as Windows-only, along with the related P_* constants. These are provided by the nt module.
everywhere", whose interfaces aren't copies of cryptic old Unixisms, and whose docs are platform neutral.
I'm alwasy glad to see documentation patches, or even pointers to specific problems. Being a Unix-weenie myself, making the documentation more readable to Windows-weenies can be difficult at times. But given useful pointers, I can usually pull it off, or at least drive someone who canto do so. ;-) -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives

[Fred L. Drake, Jr.]
I stand corrected, Fred -- so how do the Unix dweebs like this Windows crap cluttering "their" docs <wink>? [Tim, pitching a portable sane interface to a portable sane subset of os functionality]
No, it's deeper than that. Some of the inherited Unix interfaces are flatly incomprehensible to anyone other than a Unix-head, but the functionality is supplied only in that form (docs may ease the pain, but the interfaces still suck); for example, mkdir (path[, mode]) Create a directory named path with numeric mode mode. The default mode is 0777 (octal). On some systems, mode is ignored. Where it is used, the current umask value is first masked out. Availability: Macintosh, Unix, Windows. If you have a sister or parent or 3-year-old child (they're all equivalent for this purpose <wink>), just imagine them reading that. If you can't, I'll have my sister call you <wink>. Raw numeric permission modes, octal mode notation, and the "umask" business are Unix-specific -- and even Unices supply symbolic ways to specify permissions. chmod is likely the one I hear the most gripes about. Windows heads are looking to change "file attributes", the name "chmod" is gibberish to them, most of the Unix mode bits make no sense under Windows (& contra Guido's optimism, never will) even if you know the secret octal code, and Windows has several attributes (hidden bit, system bit, archive bit) chmod can't get at. The only portable functionality here is the write bit, but no non-Unix person could possibly guess either that chmod is the function they need, or what to type after someone tells them it's chmod. So this is less a doc issue than that more of os needs to become more like os.path (i.e., intelligently named functions with intelligently abstracted interfaces). never-grasped-what-ken-thompson-had-against-trailing-"e"s-ly y'rs - tim

Tim> chmod is likely the one I hear the most gripes about. Windows Tim> heads are looking to change "file attributes", the name "chmod" is Tim> gibberish to them Well, we could confuse everyone and rename "chmod" to "chfat" (is that like file system liposuction?). Windows probably has an equivalent function whose name is 17 characters long which we'd all love to type, I'm sure. ;-) Tim> most of the Unix mode bits make no sense under Windows (& contra Tim> Guido's optimism, never will) even if you know the secret octal Tim> code ... It beats a secret handshake. Imagine all the extra peripherals we'd have to make available for everyone's computer. ;-) Tim> So this is less a doc issue than that more of os needs to become Tim> more like os.path (i.e., intelligently named functions with Tim> intelligently abstracted interfaces). Hasn't Guido's position been that the interface modules like os, posix, etc are just a thin layer over the underlying API (Guido: note how I cleverly attributed this position to you but also placed the responsibility for correctness on your head!)? If that's the case, perhaps we should provide a slightly higher level module that abstracts the file system as objects, and adopts a more user-friendly approach to the secret octal codes. Those of us worried about job security could continue to use the lower level module and leave the higher level interface for former Visual Basic programmers. Tim> never-grasped-what-ken-thompson-had-against-trailing-"e"s-ly y'rs - maybe-the-"e"-key-stuck-on-his-TTY-ly y'rs... Skip Montanaro | http://www.mojam.com/ skip@mojam.com | http://www.musi-cal.com/~skip/ 847-971-7098 | Python: Programming the way Guido indented...

Skip Montanaro writes:
whose name is 17 characters long which we'd all love to type, I'm sure. ;-)
Just 17? ;-)
Sounds like some doc improvements can really help improve things, at least in the short term.
I'm all for an object interface to a logical filesystem; having had to write just such a thing in Java not long ago, and we have a similar construct in Python (not by me, though), that we use in our Knowbot work. -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives

"TP" == Tim Peters <tim_one@email.msn.com> writes:
TP> Well, don't read anything unintended into this, but Guido *is* TP> out of town, and you *do* have the power to check in code TP> outside the doc subtree ... TP> barry-will-help-he's-been-itching-to-revolt-too<wink>-ly y'rs I'll bring the pitchforks if you bring the torches! -Barry

> I'm all for an object interface to a logical filesystem; having had to > write just such a thing in Java not long ago, and we have a similar > construct in Python (not by me, though), that we use in our Knowbot > work. Fred, Since this is the dev group, how about showing us the Knowbot's logical filesystem API, and let's do some dev-ing... Skip Montanaro | http://www.mojam.com/ skip@mojam.com | http://www.musi-cal.com/~skip/ 847-971-7098 | Python: Programming the way Guido indented...

Skip Montanaro writes:
Since this is the dev group, how about showing us the Knowbot's logical filesystem API, and let's do some dev-ing...
Well, I took a look at it, and I must confess it's just not really different from the set of interfaces in the os module; the important point is that they are methods instead of functions (other than a few data items: sep, pardir, curdir). The path attribute provided the same interface as os.path. Its only user-visible state is the current-directory setting, which may or may not be that useful. We left off chmod(), which would make Tim happy, but that was only because it wasn't meaningful in context. We'd have to add it (or something equivalent) for a general purpose filesystem object. So Tim's only happy if he can come up with a general interface that is actually portable (consider my earlier comments on setreadonly()). On the other hand, you don't need chmod() or anything like it for most situations where a filesystem object would be useful. An FTPFilesystem class would not be hard to write! -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives

[Fred L. Drake, Jr.]
I'd be appalled to see chmod go away; for many people it's comfortable and useful. I want *another* way, to do what little bit is portable in a way that doesn't require first mastering a badly designed interface from a dying OS <wink>.
I don't care about general here; making up a general new way to spell everything that everyone may want to do under every OS would create an interface even worse than chmod's. My sister doesn't want to create files that are read-only to the world but writable to her group -- she just wants to mark certain precious files as read-only to minimize the chance of accidental destruction. What she wants is easy to do under Windows or Unix, and I expect she's the norm rather than the exception.
An OO filesystem object with a .makereadonly method suits me fine <wink>.

[Skip Montanaro]
Well, we could confuse everyone and rename "chmod" to "chfat" ...
I don't want to rename anything, nor do I want to use MS-specific names. chmod is both the wrong spelling & the wrong functionality for all non-Unix systems. os.path did a Good Thing by, e.g., introducing getmtime(), despite that everyone knows <wink> it's just os.stat()[8]. New isreadonly(path) and setreadonly(path) are more what I'm after; nothing beyond that is portable, & never will be.
Windows probably has an equivalent function whose name is 17 characters long
Indeed, SetFileAttributes is exactly 17 characters long (you moonlighting on NT, Skip?!). But while Windows geeks would like to use that, it's both the wrong spelling & the wrong functionality for all non-Windows systems.
Like that, yes.
You're just *begging* Guido to make the Python2 os module take all of its names from the Win32 API <wink>. it's-no-lamer-to-be-ignorant-of-unix-names-than-it-is- to-be-ignorant-of-chinese-ly y'rs - tim

Tim Peters writes:
Tim, I think we can simply declare that isreadonly() checks that the file doesn't allow the user to read it, but setreadonly() sounds to me like it wouldn't be portable to Unix. There's more than one (reasonable) way to make a file unreadable to a user just by manipulating permission bits, and which is best will vary according to both the user and the file's existing permissions. -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives

[Fred L. Drake, Jr.]
I think we can simply declare that isreadonly() checks that the file doesn't allow the user to read it,
Had more in mind that the file doesn't allow the user to write it <wink>.
"Portable" implies least common denominator, and the plain meaning of read-only is that nobody (whether owner, group or world in Unix) has write permission. People wanting something beyond that are going beyond what's portable, and that's fine -- I'm not suggesting getting rid of chmod for Unix dweebs. But by the same token, Windows dweebs should get some other (as non-portable as chmod) way to fiddle the bits important on *their* OS (only one of which chmod can affect). Billions of newbies will delightedly stick to the portable interface with the name that makes sense. the-percentage-of-programmers-doing-systems-programming-shrinks-by- the-millisecond-ly y'rs - tim
participants (6)
-
Andrew M. Kuchling
-
Barry A. Warsaw
-
Fred L. Drake, Jr.
-
Guido van Rossum
-
Skip Montanaro
-
Tim Peters