[Python-Dev] os.tmpfile() problem
I've got slight problem with os.tmpfile(). What I would like to do is to get the filedesc of tmpfile. First approach: os.tmpfile().fileno() of course does not work out, because fileno() does not keep object alive. The solution is to keep os.tmpfile() result somewhere for an arbitrary amount of time, which is quite obscure. This is problem with all file operations, but fortunately if I want a filedesc, I can do just os.open() which will not close the file for me. I've got several obscure solutions, noone satisfies me really: * If I use .fileno() than I'm on my own and I need to close file myself * .fileno() returns a int-like object which keeps alive file (well, this will explode when keeping this as an index in a list, which does not keep the object alive and so on) * have os._tmpfile() or whatever which returns filedesc What do you think? Cheers, fijal ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.tmpfile() problem
This seems a question for comp.lang.python or [EMAIL PROTECTED] (does that still exist?). Also, you might consider the APIs available in the tempfile module rather than os.tempfile(). On 8/7/07, Maciej Fijalkowski <[EMAIL PROTECTED]> wrote: > I've got slight problem with os.tmpfile(). What I would like to do is to get > the filedesc of tmpfile. > > First approach: > > os.tmpfile().fileno() of course does not work out, because fileno() does not > keep object alive. The solution is to keep os.tmpfile() result somewhere for > an arbitrary amount of time, which is quite obscure. This is problem with > all file operations, but fortunately if I want a filedesc, I can do just > os.open() which will not close the file for me. > > I've got several obscure solutions, noone satisfies me really: > > * If I use .fileno() than I'm on my own and I need to close file myself > > * .fileno() returns a int-like object which keeps alive file (well, this > will explode when keeping this as an index in a list, which does not keep > the object alive and so on) > > * have os._tmpfile() or whatever which returns filedesc > > What do you think? > > Cheers, > fijal > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pleaswe help with the countdown to zero failing tests in the struni branch!
Here's a followup. We need help from someone with a 64-bit Linux box; these tests are failing on 64-bit only: test_io, test_largefile, test_ossaudiodev, test_poll, test_shelve, test_socket_ssl. I suspect that the _fileio.c module probably is one of the culprits. Other news: On 8/6/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > We're down to 11 failing test in the struni branch. I'd like to get > this down to zero ASAP so that we can retire the old p3yk (yes, with > typo!) branch and rename py3k-struni to py3k. > > Please help! Here's the list of failing tests: > > test_ctypes > Recently one test started failing again, after Martin changed > PyUnicode_FromStringAndSize() to use UTF8 instead of Latin1. > > test_email > test_email_codecs > test_email_renamed > Can someone contact the email-sig and ask for help with these? > > test_minidom > Recently started failing again; probably shallow. > > test_sqlite > Virgin territory, probably best done by whoever wrote the code or at > least someone with time to spare. > > test_tarfile > Virgin territory again (but different owner :-). Lars Gustaebel fixed this except for a few bz2-related tests. > test_urllib2_localnet > test_urllib2net > I think Jeremy Hylton may be close to fixing these, he's done a lot of > work on urllib and httplib. > > test_xml_etree_c > Virgin territory again. > > There are also a few tests that only fail on CYGWIN or OSX; I won't > bother listing these. The two OSX tests listed at the time were fixed, thanks to those volunteers! We now only have an OSX-specific failure in test_csv. > If you want to help, please refer to this wiki page: > http://wiki.python.org/moin/Py3kStrUniTests > > There are also other tasks; see http://wiki.python.org/moin/Py3kToDo -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
