[issue12797] io.FileIO and io.open should support openat

Eryk Sun added the comment: Марк, 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 W

[issue12797] io.FileIO and io.open should support openat

Марк Коренберг added the comment: But... os.openat() is still missing... why status is closed() ?! -- nosy: +mmarkk ___ Python tracker ___ ___

[issue12797] io.FileIO and io.open should support openat

Éric Araujo added the comment: See #13424 for a doc request about this. -- ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue12797] io.FileIO and io.open should support openat

Ross Lagerwall added the comment: Thanks (and for the English lesson ;-) ) -- assignee: -> rosslagerwall resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed ___ Python tracker __

[issue12797] io.FileIO and io.open should support openat

Terry J. Reedy added the comment: > 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

[issue12797] io.FileIO and io.open should support openat

Charles-François Natali added the comment: > 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" i

[issue12797] io.FileIO and io.open should support openat

Amaury Forgeot d'Arc added the comment: Is "an open file descriptor" correct in English? I'd have written "an opened file descriptor" instead (in 5 places). -- ___ Python tracker _

[issue12797] io.FileIO and io.open should support openat

Roundup Robot added the comment: 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 -- nosy: +python-dev ___

[issue12797] io.FileIO and io.open should support openat

Antoine Pitrou added the comment: > 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 documenta

[issue12797] io.FileIO and io.open should support openat

Ross Lagerwall added the comment: 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(

[issue12797] io.FileIO and io.open should support openat

Benjamin Peterson added the comment: Also, the documentation should indicate what exactly is supposed to be returned by "opener". -- nosy: +benjamin.peterson ___ Python tracker ___

[issue12797] io.FileIO and io.open should support openat

Antoine Pitrou added the comment: 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

[issue12797] io.FileIO and io.open should support openat

Ross Lagerwall added the comment: The attached patch adds the opener keyword + tests. -- Added file: http://bugs.python.org/file23550/opener.patch ___ Python tracker ___ ___

[issue12797] io.FileIO and io.open should support openat

Antoine Pitrou added the comment: > 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. -- ___ Python tracker

[issue12797] io.FileIO and io.open should support openat

Ross Lagerwall added the comment: 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

[issue12797] io.FileIO and io.open should support openat

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue12797] io.FileIO and io.open should support openat

Antoine Pitrou added the comment: > What would you envisage the API for the custom opener to look like? The same as os.open(), I would say. -- ___ Python tracker ___ __

[issue12797] io.FileIO and io.open should support openat

Ross Lagerwall added the comment: What would you envisage the API for the custom opener to look like? -- ___ Python tracker ___ ___ P

[issue12797] io.FileIO and io.open should support openat

Charles-François Natali added the comment: > 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. -- ___ Python tracker

[issue12797] io.FileIO and io.open should support openat

Ross Lagerwall added the comment: 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 :-) -- ___ Python tracker

[issue12797] io.FileIO and io.open should support openat

Antoine Pitrou added the comment: > 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? -- ___ Python tracker

[issue12797] io.FileIO and io.open should support openat

Ross Lagerwall added the comment: Attached is a patch which adds dirfd= as a keyword argument. -- keywords: +patch Added file: http://bugs.python.org/file23272/i12797.patch ___ Python tracker _

[issue12797] io.FileIO and io.open should support openat

Terry J. Reedy added the comment: 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 mi

[issue12797] io.FileIO and io.open should support openat

Changes by Éric Araujo : -- nosy: +eric.araujo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue12797] io.FileIO and io.open should support openat

Ned Deily added the comment: > We already have os.openat Ah, right. The comment still applies, though, to future documentation of the proposed feature. +1 on it. -- ___ Python tracker __

[issue12797] io.FileIO and io.open should support openat

Antoine Pitrou added the comment: > 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

[issue12797] io.FileIO and io.open should support openat

Ned Deily added the comment: 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. -- nosy: +ned.deil

[issue12797] io.FileIO and io.open should support openat

STINNER Victor added the comment: > 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. -- ___ P

[issue12797] io.FileIO and io.open should support openat

Antoine Pitrou added the comment: > 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

[issue12797] io.FileIO and io.open should support openat

Amaury Forgeot d'Arc added the comment: 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. -- nosy: +amaury.forgeotdarc

[issue12797] io.FileIO and io.open should support openat

Changes by Nadeem Vawda : -- nosy: +nadeem.vawda ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue12797] io.FileIO and io.open should support openat

New submission from Antoine Pitrou : 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 wa