[issue21191] os.fdopen() may eat file descriptor and still raise exception

2014-04-15 Thread Benjamin Peterson
Benjamin Peterson added the comment: On Tue, Apr 15, 2014, at 2:34, Dima Tisnek wrote: > > Dima Tisnek added the comment: > > Banjamin, Your patch looks good to me! > > I have a small concern regarding "We now know we will succeed..." -- > should there be a test case to make sure fstat test he

[issue21191] os.fdopen() may eat file descriptor and still raise exception

2014-04-15 Thread Dima Tisnek
Dima Tisnek added the comment: Banjamin, Your patch looks good to me! I have a small concern regarding "We now know we will succeed..." -- should there be a test case to make sure fstat test here matches whatever test is/was done on a lower level? Or is your code now such that it will explici

[issue21191] os.fdopen() may eat file descriptor and still raise exception

2014-04-14 Thread Roundup Robot
Roundup Robot added the comment: New changeset 339c79791b65 by Benjamin Peterson in branch '2.7': when an exception is raised in fdopen, never close the fd (changing on my mind on #21191) http://hg.python.org/cpython/rev/339c79791b65 -- ___ Python tr

[issue21191] os.fdopen() may eat file descriptor and still raise exception

2014-04-13 Thread Benjamin Peterson
Benjamin Peterson added the comment: Feel free to submit a patch. On Fri, Apr 11, 2014, at 2:40, Dima Tisnek wrote: > > Dima Tisnek added the comment: > > I think consistency between Python versions is just as important as > consistency between fd types. > > Here's my hack quickfix outline: >

[issue21191] os.fdopen() may eat file descriptor and still raise exception

2014-04-11 Thread Dima Tisnek
Dima Tisnek added the comment: I think consistency between Python versions is just as important as consistency between fd types. Here's my hack quickfix outline: fd = os.open(...) try: if not stat.S_ISREG(os.fstat(fd).st_mode): raise OSError(None, "Not a regular file", ...) f =

[issue21191] os.fdopen() may eat file descriptor and still raise exception

2014-04-10 Thread Benjamin Peterson
Benjamin Peterson added the comment: On Thu, Apr 10, 2014, at 10:46, Dima Tisnek wrote: > > Dima Tisnek added the comment: > > I'm not sure if you are referring to Python's C-level fdopen or GNU libc > fdopen. > > GNU libc fdopen does not consume file descriptor on error: > > #include > #inc

[issue21191] os.fdopen() may eat file descriptor and still raise exception

2014-04-10 Thread Dima Tisnek
Dima Tisnek added the comment: I'm not sure if you are referring to Python's C-level fdopen or GNU libc fdopen. GNU libc fdopen does not consume file descriptor on error: #include #include #include #include #include #include #include int main(int argc, char** argv) { int fd = -1;

[issue21191] os.fdopen() may eat file descriptor and still raise exception

2014-04-09 Thread Benjamin Peterson
Benjamin Peterson added the comment: I should note the C level fdopen has the the 2.x semantics. -- ___ Python tracker ___ ___ Python-

[issue21191] os.fdopen() may eat file descriptor and still raise exception

2014-04-09 Thread Benjamin Peterson
Benjamin Peterson added the comment: On Wed, Apr 9, 2014, at 13:18, Dima Tisnek wrote: > > Dima Tisnek added the comment: > > Good point. > > Personally I think it's more pythonic to consume fd only on success. I > accept that's just an opinion. > > In any case, let's keep error semantics in

[issue21191] os.fdopen() may eat file descriptor and still raise exception

2014-04-09 Thread Dima Tisnek
Dima Tisnek added the comment: Good point. Personally I think it's more pythonic to consume fd only on success. I accept that's just an opinion. In any case, let's keep error semantics in py2.7 and py3.3 same. -- ___ Python tracker

[issue21191] os.fdopen() may eat file descriptor and still raise exception

2014-04-09 Thread Benjamin Peterson
Benjamin Peterson added the comment: On Wed, Apr 9, 2014, at 12:48, Dima Tisnek wrote: > > Dima Tisnek added the comment: > > I don't like proposed patch -- it changes semantics of more (?) common > failure modes. I don't know if opening the file with the wrong mode is any more wrong than open

[issue21191] os.fdopen() may eat file descriptor and still raise exception

2014-04-09 Thread Dima Tisnek
Dima Tisnek added the comment: I don't like proposed patch -- it changes semantics of more (?) common failure modes. I think it's best to keep semantics in line with Python 3.3 -- if fdopen fails, it leaves file descriptor alone. -- ___ Python trac

[issue21191] os.fdopen() may eat file descriptor and still raise exception

2014-04-09 Thread Roundup Robot
Roundup Robot added the comment: New changeset 4a3b455abf76 by Benjamin Peterson in branch '2.7': make sure fdopen always closes the fd in error cases (closes #21191) http://hg.python.org/cpython/rev/4a3b455abf76 -- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected st

[issue21191] os.fdopen() may eat file descriptor and still raise exception

2014-04-09 Thread Benjamin Peterson
Benjamin Peterson added the comment: Ah, you're right. I misread the code. -- resolution: wont fix -> status: closed -> open ___ Python tracker ___ _

[issue21191] os.fdopen() may eat file descriptor and still raise exception

2014-04-09 Thread Dima Tisnek
Dima Tisnek added the comment: Benjamin, I think you missed the key point: file + matching mode -> fd eaten, object created file + mode mismatch -> fd remains, exception raised dir + matching mode -> fd eaten, exception raised The issue is about resouce (fd) management Thus, how can user code

[issue21191] os.fdopen() may eat file descriptor and still raise exception

2014-04-09 Thread Benjamin Peterson
Benjamin Peterson added the comment: I think this is just won't fix. I agree the behavior in 3.x is better, but at least fdopen() is consistent about closing in 2.x, so you could work around it by dupping the fd. -- nosy: +benjamin.peterson resolution: -> wont fix status: open -> clos

[issue21191] os.fdopen() may eat file descriptor and still raise exception

2014-04-09 Thread Dima Tisnek
New submission from Dima Tisnek: os.fdopen() should either: * consume file descriptor and return file/io object, or * leave file descriptor alone and raise an exception this invariant is broken in the following test case: fd = os.open("/", os.O_RDONLY) try: obj = os.fdopen(fd, "r") except En