Author larry
Recipients Arfrever, benjamin.peterson, larry, r.david.murray, serhiy.storchaka
Date 2012-04-28.10:38:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1335609521.18.0.838505540884.issue14626@psf.upfronthosting.co.za>
In-reply-to
Content
Here my first stab at a comprehensive proposal.  Each section represents a specific new function argument, and a list of functions that the argument be added to.

All new arguments are keyword-only and optional.

All functions mentioned are in the os module.
_______________________________________

This annotation:
		foo             [X bar]
means "if we add this argument to function foo, we can remove function bar".  This is because bar is a new function only in trunk and has no installed base.

This annotation:
		foo             [- bar]
means "if we add this argument to function foo, we could theoretically start deprecating function bar".  bar shipped in a previous version of Python and we can't simply remove it.

However!  I am *not* proposing doing *any* of these deprecations--I suspect the right thing to do is to leave all the existing functions in.

_______________________________________
follow_symlinks=bool (default True)

Allow functions to either follow symlinks (the default) or examine symlinks.

	access              [X faccessat]
	chflags             [- lchflags]
	chmod               [- lchmod]
	chown               [- lchown]
	getxattr            [X lgetxattr]
	link                [X linkat]
	listxattr           [X llistxattr]
	removexattr         [X lremovexattr]
	setxattr            [X lsetxattr]
	stat                [- lstat]
	utime               [X lutimes]
_______________________________________
effective_ids=bool (default False)

For functions that take the AT_EACCESS flag or otherwise operate on effective uid/gid.

	access              [X faccessat]
	    (this also lets us skip ever adding euidaccess!)
_______________________________________
dir_fd=int (default None)

For functions that take a "dir_fd" parameter instead of / in addition to a "path" parameter.

	access              [X faccessat]
	chmod               [X fchmodat]
	chown               [X fchownat]
	getxattr            [X fgetxattr]
	link                [X linkat] (note! need two parameters here.)
	mkdir               [X mkdirat]
	mkfifo              [X mkfifoat]
	mknod               [X mknodat]
	open                [X openat]
	readlink            [X readlinkat]
	rename              [X renameat]
	stat                [X fstatat]
	symlink             [X symlinkat]
	unlink              [X unlinkat]
	utime               [X futimesat utimensat]
_______________________________________
fd=int (default None)

For functions that take a "path" parameter and have an "f"-equivalent that take an "fd" instead.  The "path" parameter and "fd" parameters would be exclusive; you must specify exactly one, never both.  Both parameters would accept "None" as equivalent to being unspecified.  For the functions that only take one parameter (chdir, listdir, stat, statvfs) I propose we give that parameter a default of None.

	chdir               [- fchmod]
	chown               [- fchown]
	execve              [X fexecve]
	getxattr            [X fgetxattr]
	listdir             [X flistdir]
	listxattr           [X flistxattr]
	removexattr         [X fremovexattr]
	setxattr            [X fsetxattr]
	stat                [- fstat]
	statvfs             [- fstatvfs]
	utime               [X futimes futimens]

_______________________________________
remove_dir=bool (default False)

Allows unlink to behave like rmdir.

	unlink              [X unlinkat] [- rmdir]
_______________________________________


One question:

If we do as I propose, and dir_fd is always a parameter to a pre-existing function, can we drop support for AT_FDCWD?  It seems to me that
    funlink("../foo", dir_fd=AT_FDCWD)
is equivalent to
    unlink("../foo")
but I fear I'm missing something important.
History
Date User Action Args
2012-04-28 10:38:41larrysetrecipients: + larry, benjamin.peterson, Arfrever, r.david.murray, serhiy.storchaka
2012-04-28 10:38:41larrysetmessageid: <1335609521.18.0.838505540884.issue14626@psf.upfronthosting.co.za>
2012-04-28 10:38:40larrylinkissue14626 messages
2012-04-28 10:38:39larrycreate