[issue12939] Add new io.FileIO using the native Windows API

R. David Murray added the comment: Given that background, closing it seems reasonable to me :) -- ___ Python tracker ___

[issue12939] Add new io.FileIO using the native Windows API

STINNER Victor added the comment: R. David Murray: "If it's a good idea, why close the issue?" Yesterday I tried to cleanup the list of issues that I opened. I reduced my list from 140 to around 100 issues. I'm happier :-) I don't like having a too long "TODO list". Sometimes, closing an

[issue12939] Add new io.FileIO using the native Windows API

R. David Murray added the comment: If it's a good idea, why close the issue? Maybe post it to core-mentorship instead? It's not an easy issue, but it also has the beginnings of a patch. So if there is anyone on core-mentorship with some windows knowledge (and I'm guessing their are), maybe

[issue12939] Add new io.FileIO using the native Windows API

STINNER Victor added the comment: While it might be a good idea, we failed to find anyone to implement it in 6 years, and so I close the issue. Sorry! -- resolution: -> out of date stage: needs patch -> resolved status: open -> closed ___ Python

[issue12939] Add new io.FileIO using the native Windows API

Changes by Steve Dower : -- nosy: +steve.dower ___ Python tracker ___ ___

[issue12939] Add new io.FileIO using the native Windows API

STINNER Victor added the comment: I reopen the issue. The patch is outdated. Richard Oudkerk doens't seem to be active last weeks :-/ -- resolution: out of date -> status: closed -> open ___ Python tracker

[issue12939] Add new io.FileIO using the native Windows API

Марк Коренберг added the comment: Please reopen. I still have interest for that. Fact that we survive 8 years is not enough for closing bugs as "Won't fix". This fact point only on that ther are no good specialists that can fix that bug, since it is Windows-only, actually. --

[issue12939] Add new io.FileIO using the native Windows API

Марк Коренберг added the comment: Sorry, for the "there are no good specialist". I mean "There are no well motivated good specialist" :) -- ___ Python tracker

[issue12939] Add new io.FileIO using the native Windows API

R. David Murray added the comment: Since Guido voted in favor and there's a patch proposal, I think we should keep this open in the hopes that someone will come along who can move it forward. I don't know enough to know what moving it forward would look like, though. (I know you opened the

[issue12939] Add new io.FileIO using the native Windows API

Mark Lawrence added the comment: If Марк Коренберг (mmarkk) is interested, they should move it forward. If they're not interested, move it too "languishing", where it can sit happily for ever and a day. Pay your money, take your choice? -- ___

[issue12939] Add new io.FileIO using the native Windows API

STINNER Victor added the comment: Lack of interest, I'm not convinced that it's *really* needed. We survived 8 years with the current io module in Python 3, it's probably enough. I close the issue. -- resolution: -> out of date status: open -> closed

[issue12939] Add new io.FileIO using the native Windows API

Changes by Roumen Petrov bugtr...@roumenpetrov.info: -- nosy: +rpetrov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12939 ___ ___

[issue12939] Add new io.FileIO using the native Windows API

Mark Lawrence added the comment: It strikes me as far more sense to use the native API so how do we take this forward, formal patch review, put it on pypi, or what? -- nosy: +BreamoreBoy versions: +Python 3.5 -Python 3.4 ___ Python tracker

[issue12939] Add new io.FileIO using the native Windows API

STINNER Victor added the comment: Serhiy implemented the FileIO class in pure Python: see the issue #21859 (patch under review). Using thre Python class, it becomes easier to reimplement FileIO using the Windows API, at least to play with a prototype in pure Python. -- nosy:

[issue12939] Add new io.FileIO using the native Windows API

Piotr Dobrogost added the comment: I guess extracting Richard's patch to a package and placing it on PyPI would be a good move. I recalled reading this bug after I saw Does Python IO allow opened file to be deleted/renamed on Windows? question on Stackoverflow

[issue12939] Add new io.FileIO using the native Windows API

Changes by Piotr Dobrogost p...@bugs.python.dobrogost.net: -- nosy: +piotr.dobrogost ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12939 ___ ___

[issue12939] Add new io.FileIO using the native Windows API

Guido van Rossum added the comment: Just a note of support for Richard -- having I/O use the native APIs directly rather than via emulation or other wrappers is a good idea, because the emulations / wrappers usually add restrictions that are not present in the native API. This is also the

[issue12939] Add new io.FileIO using the native Windows API

Richard Oudkerk added the comment: New patch reflecting Amaury's comments. -- Added file: http://bugs.python.org/file28737/winfileio.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12939

[issue12939] Add new io.FileIO using the native Windows API

Changes by Richard Oudkerk shibt...@gmail.com: Removed file: http://bugs.python.org/file28707/winfileio.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12939 ___

[issue12939] Add new io.FileIO using the native Windows API

Antoine Pitrou added the comment: The current patch does not support overlapped IO, but that could be added easily enough. (Overlapped IO for normal files might be more complicated.) That could be cool. Wouldn't it belong in the fabled winapi module? --

[issue12939] Add new io.FileIO using the native Windows API

Amaury Forgeot d'Arc added the comment: Added some comments on Rietveld. The .fileno() method is missing. Can this cause a problem when the file is passed to stdlib functions? subprocess for example? -- ___ Python tracker rep...@bugs.python.org

[issue12939] Add new io.FileIO using the native Windows API

Antoine Pitrou added the comment: What does this proposal bring exactly? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12939 ___ ___

[issue12939] Add new io.FileIO using the native Windows API

Richard Oudkerk added the comment: Added some comments on Rietveld. The .fileno() method is missing. Can this cause a problem when the file is passed to stdlib functions? subprocess for example? Thanks. An older version of the patch had a fileno() method which returned the handle -- but

[issue12939] Add new io.FileIO using the native Windows API

Richard Oudkerk added the comment: What does this proposal bring exactly? Unless we are willing to completely replace fds with handles on Windows, perhaps not too much. (At one point I had assumed that that was the plan for py3k.) Although not advertised, openhandle() does have a

[issue12939] Add new io.FileIO using the native Windows API

Richard Oudkerk added the comment: Attached is a new patch which is implemented completely in C. It adds a WinFileIO class to the io module, which has the same API as FileIO except that: * It has a handle attribute instead of a fileno() method. * It has staticmethods openhandle() and

[issue12939] Add new io.FileIO using the native Windows API

Changes by Richard Oudkerk shibt...@gmail.com: Removed file: http://bugs.python.org/file28544/winfileio.c ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12939 ___

[issue12939] Add new io.FileIO using the native Windows API

Changes by Richard Oudkerk shibt...@gmail.com: Removed file: http://bugs.python.org/file28545/test_winfileio.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12939 ___

[issue12939] Add new io.FileIO using the native Windows API

Changes by Richard Oudkerk shibt...@gmail.com: Removed file: http://bugs.python.org/file28590/winfileio.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12939 ___

[issue12939] Add new io.FileIO using the native Windows API

Richard Oudkerk added the comment: Forgot to mention, the handles are non-inheritable. You can use _winapi.DuplicateHandle() to create an inheritable duplicate handle if you really need to. -- ___ Python tracker rep...@bugs.python.org

[issue12939] Add new io.FileIO using the native Windows API

STINNER Victor added the comment: Hum, _get_osfhandle() was not mentionned in this issue. This function may be used to retrieve the internel file handle from a file descriptor. http://msdn.microsoft.com/en-us/library/ks2530z6%28v=vs.100%29.aspx There is also the opposite: _open_osfhandle().

[issue12939] Add new io.FileIO using the native Windows API

Richard Oudkerk added the comment: Attached is a patch which adds a winio module which is a replacement for io, but uses windows handles instead of fds. It reimplements FileIO and open(), and provides openhandle() and closehandle() as replacements for os.open() and os.close(). test_io has

[issue12939] Add new io.FileIO using the native Windows API

STINNER Victor added the comment: I don't like the idea of a specific I/O module for an OS. Is the public API different? Can't you reuse the io module? Le 6 janv. 2013 14:59, Richard Oudkerk rep...@bugs.python.org a écrit : Richard Oudkerk added the comment: Attached is a patch which adds a

[issue12939] Add new io.FileIO using the native Windows API

Richard Oudkerk added the comment: I don't like the idea of a specific I/O module for an OS. Is the public API different? It was partly to make integration with the existing tests easier: _io, _pyio and winio are tested in parallel. Can't you reuse the io module? In what sense? I don't

[issue12939] Add new io.FileIO using the native Windows API

Марк Коренберг added the comment: Yes, re-writing windows IO to direct API, without intemediate layer is still needed. Please don't close bug. Maybe someone will implement this. -- ___ Python tracker rep...@bugs.python.org

[issue12939] Add new io.FileIO using the native Windows API

Changes by Serhiy Storchaka storch...@gmail.com: -- components: +Windows nosy: +ezio.melotti stage: - needs patch type: - enhancement versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12939

[issue12939] Add new io.FileIO using the native Windows API

Richard Oudkerk added the comment: A while ago I did write a PipeIO class which subclasses io.RawIOBase and works for overlapped pipe handles. (It was intended for multiprocessing and doing asynchronous IO with subprocess.) As it is it would not work with normal files because when you do

[issue12939] Add new io.FileIO using the native Windows API

Richard Oudkerk added the comment: Attached is a module for Python 3.3+ which subclasses io.RawIOBase. The constructor signature is WinFileIO(handle, mode=r, closehandle=True) where mode is r, w, r+ or w+. Handles can be created using _winapi.CreateFile(). Issues: - No support for

[issue12939] Add new io.FileIO using the native Windows API

Changes by Richard Oudkerk shibt...@gmail.com: Added file: http://bugs.python.org/file28545/test_winfileio.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12939 ___

[issue12939] Add new io.FileIO using the native Windows API

STINNER Victor added the comment: I'm not really motivated to work on a Windows-specific issue. The issue has no patch, even no proof-of-concept implemented in Python. Can I close the issue, or is someone interested to work on this topic? Python 3.3 adds a opener argument to open(). It may be

[issue12939] Add new io.FileIO using the native Windows API

Changes by Antoine Pitrou pit...@free.fr: -- nosy: +sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12939 ___ ___ Python-bugs-list mailing list

[issue12939] Add new io.FileIO using the native Windows API

STINNER Victor victor.stin...@haypocalc.com added the comment: Instead of rewriting your own RawIO implementation, why not use _open_osfhandle? I don't know yet what is the best approach. One important point is to keep the HANDLE, to be able to manipulate the open file using the Windows API

[issue12939] Add new io.FileIO using the native Windows API

Antoine Pitrou pit...@free.fr added the comment: Instead of rewriting your own RawIO implementation, why not use _open_osfhandle? This should be simple now with the opener argument. http://msdn.microsoft.com/en-us/library/bdts1c9x.aspx -- nosy: +pitrou

[issue12939] Add new io.FileIO using the native Windows API

Марк Коренберг socketp...@gmail.com added the comment: why not use _open_osfhandle? Because it is wrapper for other CRT functions for Windows, like close(). In other words it is an emulation. I think Python should not create wrapper around wrapper around wrapper... For example, in Python3,

[issue12939] Add new io.FileIO using the native Windows API

Antoine Pitrou pit...@free.fr added the comment: why not use _open_osfhandle? Because it is wrapper for other CRT functions for Windows, like close(). In other words it is an emulation. I think Python should not create wrapper around wrapper around wrapper... Why do you think it makes a

[issue12939] Add new io.FileIO using the native Windows API

Amaury Forgeot d'Arc amaur...@gmail.com added the comment: An implementation of RawIO with the win32 API can be useful (and I'd be interested to compare the performance) But maybe not for all usages: some Python interfaces are defined in terms of file descriptors, imp.load_module(), and

[issue12939] Add new io.FileIO using the native Windows API

Марк Коренберг socketp...@gmail.com added the comment: Why do you think it makes a difference? Because adding one more dependency on unneeded libraries add the pain. Also it limit us on very restricted API of that wrapper. Windows native API is stable. So it's OK to rely on it's documented

[issue12939] Add new io.FileIO using the native Windows API

Марк Коренберг socketp...@gmail.com added the comment: The good example of implemetation is QT. I think we can get some things from this library. (Like using \\?\ for long paths (or always, as in QT)). -- ___ Python tracker rep...@bugs.python.org

[issue12939] Add new io.FileIO using the native Windows API

Antoine Pitrou pit...@free.fr added the comment: Why do you think it makes a difference? Because adding one more dependency on unneeded libraries add the pain. MSVCRT is unneeded?? What are you talking about? Also it limit us on very restricted API of that wrapper. Windows native API is

[issue12939] Add new io.FileIO using the native Windows API

Changes by Santoso Wijaya santoso.wij...@gmail.com: -- nosy: +santa4nt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12939 ___ ___

[issue12939] Add new io.FileIO using the native Windows API

New submission from STINNER Victor victor.stin...@haypocalc.com: On Windows, Python uses the POSIX API (file descriptors), instead of the native API (file handles). Some features cannot be used using the POSIX API, like setting security attributes. It would be nice to have a io.FileIO using

[issue12939] Add new io.FileIO using the native Windows API

STINNER Victor victor.stin...@haypocalc.com added the comment: See also issue #1602: a prototype of a console object has been proposed to use the native Windows console API, instead of the POSIX API (read from fd 0, write to fd 1 or 2). The prototype is implemented in Python using ctypes.