Missing POSIX functions: the list
After poking around in the O'Reilly POSIX book, here's a list of POSIX functions that don't seem to be available in Python. Not all of them seem worth supporting. Ironically, Greg Ward's daemonize() Perl subroutine, which started me on this, doesn't actually seem to need anything that Python doesn't have. I'm looking for corrections to the list; are there other POSIX functions I've missed, or are some of them actually in Python? I think implementing most of these functions is straightforward, with the exception of opendir/readdir/closedir. Worth adding? ============= opendir(), readdir(), closedir() -- most of their functionality is available through os.listdir(), but it might be useful to have a direct interface. Downside is that this would require a new extension type for the C DIR struct. My (lazy) inclination is to not bother. Worth adding: ============= abort() -- used in Py_FatalError(), but not accessible to Python code ctermid(), ctermid_r() -- returns the terminal pathname -- probably just add ctermid(), but use ctermid_r() for thread-safety fpathconf(fd, name) -- Get configuration limit for a file -- would need constants from unistd.h getlogin() -- returns user's login name -- could do something similar with pwd.getpwuid( os.getuid() )[0], but getlogin() apparently looks in utmp getgroups(gidsetsize, grouplist) -- Gets supplementary group IDs pathconf(path, name) -- Gets config variables for a path -- would need constants from unistd.h sysconf(int name) -- Gets system configuration information -- would need constants from unistd.h Not worth adding: ================= clearerr() -- looks like fileobjects call clearerr() before raising errors cuserid() -- returns user's login name -- ORA book says "Do not use this function" -- removed in 1990 POSIX difftime -- seems only required in C "because no addition properties are defined for time_t" (Solaris man page) tmpfile(), tmpnam() -- Create temp file, generate temp filename -- Similar functionality available in tempfile.py mblen(), mbstowcs(), mbtowc(), wcstombs(), wctomb() -- Multi-byte character functions: -- Don't bother; wait for the Unicode type. -- A.M. Kuchling http://starship.python.net/crew/amk/ I'm sorry I became abusive just now ... calling you worms... I was just speaking relatively, you understand. -- Dekko, in ZOT! #3
On 09 December 1999, Andrew M. Kuchling said:
After poking around in the O'Reilly POSIX book, here's a list of POSIX functions that don't seem to be available in Python. Not all of them seem worth supporting. Ironically, Greg Ward's daemonize() Perl subroutine, which started me on this, doesn't actually seem to need anything that Python doesn't have.
I think I already pointed this your way, but don't forget the man page for Perl's POSIX module: "perldoc POSIX". I suspect POSIX functions that don't make sense in Perl also don't make sense in Python. I agree with all your assessments about what's worth adding and what's not, and that {close,read,open}dir() are questionable and probably not worth the bother. Random thoughts:
abort() -- used in Py_FatalError(), but not accessible to Python code
Would this do the same as in C, ie. terminate the process and dump core?
getlogin() -- returns user's login name -- could do something similar with pwd.getpwuid( os.getuid() )[0], but getlogin() apparently looks in utmp
With a documentation proviso that utmp is very old-fashioned, and you really should do the getuid() thing unless you definitely want to get the login ID from utmp. Perhaps an alternate "getlogin" (different name?) that does the getuid() thing could be provided. Greg
getlogin() -- returns user's login name -- could do something similar with pwd.getpwuid( os.getuid() )[0], but getlogin() apparently looks in utmp
With a documentation proviso that utmp is very old-fashioned, and you really should do the getuid() thing unless you definitely want to get the login ID from utmp. Perhaps an alternate "getlogin" (different name?) that does the getuid() thing could be provided.
There's the getpass module which has a getuser() function that looks in various env vars and if all else fails uses getuid() and pwd. If the goal is to get the user ID without being fooled, using os.getuid() or os.geteuid() directly seems to be the right thing to do; I don't see the need for a shorthand for pwd.getpwuid(os.getuid())[0] (which is what getuser() uses). --Guido van Rossum (home page: http://www.python.org/~guido/)
Greg Ward writes:
I think I already pointed this your way, but don't forget the man page for Perl's POSIX module: "perldoc POSIX". I suspect POSIX functions that don't make sense in Perl also don't make sense in Python.
I agree with all your assessments about what's worth adding and what's not, and that {close,read,open}dir() are questionable and probably not worth the bother. Random thoughts:
I disagree. I think that the POSIX module should strive to be as complete as possible--even if certain functions are closely related other functionality in the library (tmpfile for instance). I suspect that this sort of thing is probably the cause of the missing functionality in the current library (as in, "why would anyone want to do that?" when in fact there may be a perfectly good reason in certain situations).
abort() -- used in Py_FatalError(), but not accessible to Python code
Would this do the same as in C, ie. terminate the process and dump core?
Sure, why not? This might be a useful thing to do every so often---when trying to figure out what's wrong with a C extension module for instance. Cheers, Dave
Andrew M. Kuchling writes:
After poking around in the O'Reilly POSIX book, here's a list of POSIX functions that don't seem to be available in Python. Not all of them seem worth supporting. Ironically, Greg Ward's daemonize() Perl
I think your assessment is reasonable. I looked at posixmodule.c
and note also that the functions use PyArg_Parse() and PyArg_NoArgs()
instead of using PyArg_ParseTuple(). The advantage of
PyArg_ParseTuple() is that the name of the function can be specified
for inclusion in TypeError messages when the arguments are not of the
right type.
I'm doing some work to correct this now. I've also added ctermid(),
and will try to add at least a few more before I check in the changes.
-Fred
--
Fred L. Drake, Jr.
Andrew M. Kuchling writes:
After poking around in the O'Reilly POSIX book, here's a list of POSIX
Ok, here's my comments on the remainder of these.
Worth adding? ============= opendir(), readdir(), closedir() -- most of their functionality is available through os.listdir(), but it might be useful to have a direct interface. Downside is that this would require a new extension type for the C DIR struct. My (lazy) inclination is to not bother.
[rewinddir() and seekdir() should be considered as well, where supported.] There's more tedium than anything in implementing a new C type. I'm a little concerned that there might not be any real value here, but it's hard to be sure about that. Is there any real reason not to use os.listdir().
Worth adding: ============= ... fpathconf(fd, name) -- Get configuration limit for a file -- would need constants from unistd.h
This is mostly a matter of setting up the constants; not hard, just more distracting than I want to deal with right now.
getlogin() -- returns user's login name -- could do something similar with pwd.getpwuid( os.getuid() )[0], but getlogin() apparently looks in utmp
Per Guido's comments, I'm not sure how valuable it is. It may make sense strictly for completeness, but I've never heard of utmp being considered reliable in any way. Maybe I'm too new at all this.
getgroups(gidsetsize, grouplist) -- Gets supplementary group IDs
This should be easy enough.
pathconf(path, name) -- Gets config variables for a path -- would need constants from unistd.h
(Same as for fpathconf().)
sysconf(int name) -- Gets system configuration information -- would need constants from unistd.h
Not worth adding: =================
Aside from the ones I've already added, I agree. ;)
-Fred
--
Fred L. Drake, Jr.
On Thu, 9 Dec 1999, Fred L. Drake, Jr. wrote:
Andrew M. Kuchling writes: ...
opendir(), readdir(), closedir() -- most of their functionality is available through os.listdir(), but it might be useful to have a direct interface. Downside is that this would require a new extension type for the C DIR struct. My (lazy) inclination is to not bother.
[rewinddir() and seekdir() should be considered as well, where supported.]
There's more tedium than anything in implementing a new C type. I'm a little concerned that there might not be any real value here, but it's hard to be sure about that. Is there any real reason not to use os.listdir().
No need to do a new type. Just wrap the DIR* into a PyCObject. Add a magic number if you're worried about mixing CObjects. Cheers, -g -- Greg Stein, http://www.lyra.org/
Greg Stein writes:
No need to do a new type. Just wrap the DIR* into a PyCObject. Add a magic number if you're worried about mixing CObjects.
That's certainly one option, but I would have made readdir(),
seekdir(), rewinddir() and closedir() into the methods read(), seek(),
rewind() and close(). So it's a question of what interface you
prefer; functions with magically interpreted token parameters (kind of
like file descriptors, hey!), or something that is more recognizably
object-oriented.
I know my preference. ;-)
-Fred
--
Fred L. Drake, Jr.
On Fri, 10 Dec 1999, Fred L. Drake, Jr. wrote:
Greg Stein writes:
No need to do a new type. Just wrap the DIR* into a PyCObject. Add a magic number if you're worried about mixing CObjects.
That's certainly one option, but I would have made readdir(), seekdir(), rewinddir() and closedir() into the methods read(), seek(), rewind() and close(). So it's a question of what interface you prefer; functions with magically interpreted token parameters (kind of like file descriptors, hey!), or something that is more recognizably object-oriented. I know my preference. ;-)
Well, I know my preference of those two alternatives, too :-), but if we're going with the Pythonic minimalism, then I'd think you would expose the functions "as close as possible." Would I argue if you went with a method-based approach? No :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
Andrew M. Kuchling writes:
fpathconf(fd, name) -- Get configuration limit for a file ... pathconf(path, name) -- Gets config variables for a path ... sysconf(int name) -- Gets system configuration information -- would need constants from unistd.h
I'm almost done with these, and also confstr (from POSIX.2). I
don't have time to finish them today; I'll check them in next week.
-Fred
--
Fred L. Drake, Jr.
participants (6)
-
Andrew M. Kuchling -
David Beazley -
Fred L. Drake, Jr. -
Greg Stein -
Greg Ward -
Guido van Rossum