Right now it is painful to integrate openat() with the normal IO classes. You have to figure out the low-level flags yourself (i.e. replicate the logic and error handling from the FileIO constructor), then replicate the open() logic yourself (because you want to set the name attribute on the FileIO object before wrapping it).

Therefore it would be nice if the FileIO constructor and the open() function supported openat natively. I see two possibilities:
- allow a (dirfd, name) tuple for the first "file" argument
- allow an optional dirfd argument at the end of the arglist

A third idea is to find a way to override the low-level open() function (the one that returns a fd).

openat() seems to exist only on Linux, so I'm -1 on adding new parameters to support this function only.

> A third idea is to find a way to override the low-level open()
> function (the one that returns a fd).

Why not. It would e.g. allow to use CreateFile under Windows (the hg
guys do this in order to change the "sharing" mode to something more
laxist).

> openat() seems to exist only on Linux, so I'm -1 on adding new
> parameters to support this function only.

openat() is POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html

> allow an optional dirfd argument at the end of the arglist

I prefer this suggestion.

I didn't know openat(). Antoine told me that it can be used, for example, to fix security vulnerabilities like #4489.

I believe openat is new to POSIX (mandatory as of POSIX 2008).  For example, it's not currently in OS X and apparently was first added to FreeBSD in 8.0.  So it would have to be checked by configure and documented as platform-dependent.

> I believe openat is new to POSIX (mandatory as of POSIX 2008).  For
> example, it's not currently in OS X and apparently was first added to
> FreeBSD in 8.0.  So it would have to be checked by configure and
> documented as platform-dependent.

We already have os.openat:
http://docs.python.org/dev/library/os.html#os.openat

This request is to make it easier to use with the high-level IO classes.

> We already have os.openat
Ah, right.  The comment still applies, though, to future documentation of the proposed feature.  +1 on it.

I prefer a new parameter either at the end of the arglist or possibly keyword only. The idea for both variations is to let typical users ignore the option, which would be hard to do if it is part of the prime parameter. The idea for keyword only is that we might want to add other rarely used but useful options. They have no natural order, and having say, 8 positional params is pretty wretched. (I have worked with such APIs.)

Attached is a patch which adds dirfd= as a keyword argument.

> Attached is a patch which adds dirfd= as a keyword argument.

Thanks. Although, on second thought, I'm not sure whether Amaury's idea (allowing a custom opener) is not better... Thoughts?

I guess that would make it more general...

I'll play around with it for a bit. It mustn't become too hard to use though since the original point was to simplify the opening of files :-)

> Thanks. Although, on second thought, I'm not sure whether Amaury's 
> idea (allowing a custom opener) is not better... Thoughts?

+1.
This would also address issues #12760 and #12105.

What would you envisage the API for the custom opener to look like?

> What would you envisage the API for the custom opener to look like?

The same as os.open(), I would say.

Before I implement it properly, is this the kind of api that's desired?

"""
import os
import io

class MyOpener:
    def __init__(self, dirname):
        self.dirfd = os.open(dirname, os.O_RDONLY)

    def open(self, path, flags, mode):
        return os.openat(self.dirfd, path, flags, mode)

myop = MyOpener("/tmp")
f = open("testfile", "w", opener=myop.open)
f.write("hello")
"""

> Before I implement it properly, is this the kind of api that's desired?

Yes, although I think most people would use a closure instead of a dedicated class.

The attached patch adds the opener keyword + tests.

Here is my quick review:
- shouldn't the opener also get the third open() argument (although it currently seems to always be 0o666)?
- when fdobj is NULL, you shouldn't override the original error
- PyLong_AsLong can fail (if the opener returns too large an int), you should check for that

Thank you!

Also, the documentation should indicate what exactly is supposed to be returned by "opener".

Updated patch:
* checks for long overflow
* raises original exception if opener returns null
* makes it explicit that "opener" must return an open file descriptor.

I don't think that mode should be passed in since it is not specified in the parameters to open() (and always defaults to 0o666 anyway). Specifying the file mode should be left to the opener if needed.

> Updated patch:
> * checks for long overflow
> * raises original exception if opener returns null
> * makes it explicit that "opener" must return an open file descriptor.

This looks good to me. You just need to add a "versionchanged" attribute
in the documentation.

New changeset 0d64d9ac2b78 by Ross Lagerwall in branch 'default':
Issue #12797: Added custom opener parameter to builtin open() and FileIO.open().
http://hg.python.org/cpython/rev/0d64d9ac2b78

Is "an open file descriptor" correct in English? I'd have written "an opened file descriptor" instead (in 5 places).

> Is "an open file descriptor" correct in English? I'd have written "an
> opened file descriptor" instead (in 5 places).

"open" is correct.
For example, you say "the store is open", not "the store is opened": "open" is an adjective, whereas "opened" is the past participe.
See http://www.usingenglish.com/forum/ask-teacher/15771-open-opened-welcome-welcomed.html

> I'd have written "an opened file descriptor" instead (in 5 places).

Yes, 'open' is an adjective as well as a verb, and the correct one in 
this context. Something that has been opened, such as a sealed jar or 
envelope, might have been re-closed, but it is no longer the same as 
never-opened.

Thanks (and for the English lesson ;-) )

See #13424 for a doc request about this.

But... os.openat() is still missing... why status is closed() ?!

Марк, os.open added dir_fd support in 3.3, which is implemented on POSIX systems by calling openat. The dir_fd parameter is available for many os functions. This is discussed in section 1.5, Files and Directories [1].

It would be nice if we could support dir_fd on Windows as well, but we'd have to bypass the CRT and Windows API to use the native NT API instead, such as NtCreateFile [2]. The kernel has supported opening a file relative to a directory handle since it was release in 1993 (NT 3.1). All named kernel objects are referenced using an OBJECT_ATTRIBUTES [3] data structure. ObjectName -- a path with up to 32768 UTF-16 characters -- is relative to the RootDirectory handle if non-NULL. This is how paths relative to the process working directory are implemented, but changing the working directory isn't thread safe. 

[1]: https://docs.python.org/3/library/os.html#files-and-directories
[2]: https://msdn.microsoft.com/en-us/library/ff566424
[3]: https://msdn.microsoft.com/en-us/library/ff557749