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

[R. David Murray]

R. David Murray added the comment:

Given that background, closing it seems reasonable to me :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

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 issue helps to shake up people and it can even unblock an 
old issue :-)

In this case, I already closed and then reopened the issue, and nothing 
happened.

The benefit doesn't seem worth it, compared to the risk of backward 
compatibility issue and the cost of maintaining this new code.


"Maybe post it to core-mentorship instead?  It's not an easy issue, but it also 
has the beginnings of a patch."

Sorry, but it's very far from an easy issue. It seems like even our existing 
Windows experts failed to implement the feature in 6 years. I don't expect that 
any newcomer will success to fix the technical issues, especially if nobody is 
available to answer to the newcomer questions...

It's not because an issue is closed that the data that it contains is 
definitevely lost. If someone wants to work on that issue, it will be easy to 
find this issue using a Google search.

I see open issues as "bugs that must be fixed" or "important missing features", 
not as an unlimited wishlist. I know that each developer uses a bug tracker 
differently ;-)

At least, I don't want to the author of such wishlist issue anymore, and I 
don't want how to change the author of an issue. So I will continue to close it 
regulary to reduce my list of open issues (that I opened). Again, it's 
important for me to keep this list as short as possible.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[R. David Murray]

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 they'd be interested in the challenge.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

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 tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Davin Potts]

Changes by Davin Potts :


--
nosy: +davin

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Steve Dower]

Changes by Steve Dower :


--
nosy: +steve.dower

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Lawrence]

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?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[R. David Murray]

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 issue originally, Victor, and you aren't interested in 
it any more, but obviously others are.)

--
nosy: +r.david.murray
versions: +Python 3.6 -Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Roumen Petrov]

Changes by Roumen Petrov :


--
nosy: +rpetrov

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

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: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Lawrence]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Piotr Dobrogost]

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 
(http://stackoverflow.com/q/19280836/95735)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Piotr Dobrogost]

Changes by Piotr Dobrogost :


--
nosy: +piotr.dobrogost

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Guido van Rossum]

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 reason why we dropped going through stdio -- it 
did not give enough control over buffering and made integration with (UNIX 
native) file descriptors complex.  Integration with native I/O primitives on 
Windows seems sense in the light of e.g. PEP 3156.

--
nosy: +gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

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?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Richard Oudkerk]

Changes by Richard Oudkerk :


Removed file: http://bugs.python.org/file28707/winfileio.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Richard Oudkerk]

Richard Oudkerk added the comment:

New patch reflecting Amaury's comments.

--
Added file: http://bugs.python.org/file28737/winfileio.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Richard Oudkerk]

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 share_flags parameter to 
control the share mode of the file.  This makes it possible to delete files for 
which there are open handles.  Mercurial needs a C extension to support this.  
regrtest could certainly benefit from such a feature.

But one thing that I would at least like to do is create a FileIO replacement 
for overlapped pipe/socket handles.  Then multiprocessing.Connection could be a 
simple wrapper round a file object, and most of the platform specific code in 
multiprocessing.connection can go away.

The current patch does not support overlapped IO, but that could be added 
easily enough.  (Overlapped IO for normal files might be more complicated.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Richard Oudkerk]

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 that would have confused anything that expects fileno() to return 
a true fd.

It would be possible to make fileno() lazily create an fd using 
open_osfhandle().

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

Antoine Pitrou added the comment:

What does this proposal bring exactly?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Amaury Forgeot d'Arc]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Richard Oudkerk]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Richard Oudkerk]

Changes by Richard Oudkerk :


Removed file: http://bugs.python.org/file28590/winfileio.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Richard Oudkerk]

Changes by Richard Oudkerk :


Removed file: http://bugs.python.org/file28545/test_winfileio.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Richard Oudkerk]

Changes by Richard Oudkerk :


Removed file: http://bugs.python.org/file28544/winfileio.c

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Richard Oudkerk]

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 closehandle() which are
  analogues of os.open() and os.close().

The patch also adds a keyword-only "rawfiletype" argument to
io.open() so that you can write

f = open("somefile", "w", rawfiletype=WinFileIO)

--
Added file: http://bugs.python.org/file28707/winfileio.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

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(). This function may be used for 
fileno() method of the Windows implementation of FileIO.
http://msdn.microsoft.com/en-us/library/bdts1c9x%28v=vs.100%29.aspx

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Richard Oudkerk]

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 really know how the API should be exposed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

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"  a écrit :

>
> 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 been modified to exercise winio (in addition to _io and _pyio)
> and all the tests pass.
>
> Note that some of the implementation (openhandle(), open(),
> FileIO.__init__()) is still done in Python rather than C.
>
> --
> keywords: +patch
> Added file: http://bugs.python.org/file28590/winfileio.patch
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Richard Oudkerk]

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 been modified to exercise winio (in addition to _io and _pyio) and 
all the tests pass.

Note that some of the implementation (openhandle(), open(), FileIO.__init__()) 
is still done in Python rather than C.

--
keywords: +patch
Added file: http://bugs.python.org/file28590/winfileio.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Richard Oudkerk]

Changes by Richard Oudkerk :


Added file: http://bugs.python.org/file28545/test_winfileio.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Richard Oudkerk]

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 append mode.
- Truncate is not atomic.  (Is atomicity supposed to be guaranteed?)
- Not properly tested.

--
Added file: http://bugs.python.org/file28544/winfileio.c

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Richard Oudkerk]

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 overlapped IO 
on files you must manually track the file position.

> Yes, re-writing windows IO to direct API, without intemediate layer is still 
> needed.

What are the expected benefits?

> It would help feature #12105 to implement "O_CLOEXEC" flag using the 
> lpSecurityAttributes argument.

Isn't O_NOINHERIT the Windows equivalent of O_CLOEXEC?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
components: +Windows
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.4 -Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +sbt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

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 enough to workaround 
this issue?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

STINNER Victor  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 (e.g. call 
WriteFile instead of write).

I propose a RawIO to call directly the Windows API: file.write() would call 
directly WriteFile() instead of the POSIX wrapper (write()).

We may use it to implement new features like async I/O on Windows (e.g. 
WriteFileEx).

Modules/_multiprocessing/win32_functions.c exposes already some low-level 
Windows functions like WriteFile(). We may reuse the RawIO to offer an object 
oriented API for the Windows multiprocessing pipes. Such RawIO would have 
extra methods, maybe a file.WriteFile() method to give access to extra options 
like "overlapped".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

Antoine Pitrou  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 stable. So it's OK to rely on it's documented
> imlementation.

Please provide a patch to demonstrate the claimed improvement.

> Like using  "\\?\" for long paths

That's completely unrelated to this issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Марк Коренберг]

Марк Коренберг  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Марк Коренберг]

Марк Коренберг  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 imlementation.

Suppose, we receive file-descriptor from _open_osfhandle For example it is 
a socket. It still unusable for stdin. Many standard functions does not work 
with such handle. The list of available functions : 
http://msdn.microsoft.com/en-us/library/kdfaxaay.aspx . As we see it is very 
narrow and function names are not POSIX-compatible (_chsize vs ftruncate). 
Documentation is very poor. For example, _close() is documented only here: 
http://msdn.microsoft.com/en-US/library/40bbyw78(v=VS.80).aspx .

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  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 PyTokenizer_FindEncoding for example.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

Antoine Pitrou  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 difference?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Марк Коренберг]

Марк Коренберг  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, open() implemented using open() and not using fopen(). 
Why we should use another wrapper on Windows platform?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

Antoine Pitrou  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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Santoso Wijaya]

Changes by Santoso Wijaya :


--
nosy: +santa4nt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

STINNER Victor  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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

New submission from STINNER Victor :

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 Windows 
file handlers to get access to all Windows features. It would help feature 
#12105 to implement "O_CLOEXEC" flag using the lpSecurityAttributes argument.

We can maybe try with a prototype written in Python. Using _pyio.RawIOBase, 
only readinto(), write(), seek() and truncate() have to be implemented. But it 
is better to implement also close() :-)

--
components: IO, Unicode
messages: 143741
nosy: amaury.forgeotdarc, haypo, mmarkk
priority: normal
severity: normal
status: open
title: Add new io.FileIO using the native Windows API
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com