[issue14153] Expose os.device_encoding() at the C level

2012-02-29 Thread Brett Cannon
Changes by Brett Cannon : -- assignee: -> brett.cannon resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed ___ Python tracker ___ _

[issue14153] Expose os.device_encoding() at the C level

2012-02-29 Thread Roundup Robot
Roundup Robot added the comment: New changeset c80d9a0bd5a0 by Brett Cannon in branch 'default': Issue #14153 Create _Py_device_encoding() to prevent _io from having to import http://hg.python.org/cpython/rev/c80d9a0bd5a0 -- nosy: +python-dev ___ Pyt

[issue14153] Expose os.device_encoding() at the C level

2012-02-29 Thread Brett Cannon
Brett Cannon added the comment: OK, so if on windows or isatty + nl_langinfo + CODESET, check fd 0 for a returned string that codecs.lookup and find something for. fd 42 (if not a tty) should return None. -- ___ Python tracker

[issue14153] Expose os.device_encoding() at the C level

2012-02-29 Thread STINNER Victor
STINNER Victor added the comment: > For fd 0, it should be a string if the fd is a tty. os.device_encoding() returns None on a non-Windows OS without langinfo support. locale.nl_langinfo(locale.CODESET) may be used in such test. (to check for nl_langinfo() support?) -- __

[issue14153] Expose os.device_encoding() at the C level

2012-02-29 Thread Antoine Pitrou
Antoine Pitrou added the comment: > As for a test, I will happily write one, but what can I test? A string > for fd 0 and None for fd -1 (or is there some os call I can make to > find the largest fd so I can test fd+1)? For fd 0, it should be a string if the fd is a tty. (it should also point t

[issue14153] Expose os.device_encoding() at the C level

2012-02-29 Thread Brett Cannon
Brett Cannon added the comment: Victor's point fixed my issue. As for a test, I will happily write one, but what can I test? A string for fd 0 and None for fd -1 (or is there some os call I can make to find the largest fd so I can test fd+1)? -- _

[issue14153] Expose os.device_encoding() at the C level

2012-02-29 Thread STINNER Victor
STINNER Victor added the comment: > your patch is buggy It should be a missing #include. Maybe this one: #ifdef HAVE_LANGINFO_H #include #endif -- ___ Python tracker ___

[issue14153] Expose os.device_encoding() at the C level

2012-02-29 Thread Antoine Pitrou
Antoine Pitrou added the comment: I don't seen any refcounting problem here, but your patch is buggy. Before patch: >>> os.device_encoding(0) 'UTF-8' After patch: >>> os.device_encoding(0) is None True Interestingly, it seems there is no test for os.device_encoding. Perhaps add one to test_

[issue14153] Expose os.device_encoding() at the C level

2012-02-29 Thread Brett Cannon
Brett Cannon added the comment: Attached is a patch which is trying to do the refactor, but I'm somehow causing a something to be gc'ed when it shouldn't. If anyone spots something obvious let me know, else I will try to debug some more on my way home. -- keywords: +patch Added file:

[issue14153] Expose os.device_encoding() at the C level

2012-02-28 Thread Benjamin Peterson
Benjamin Peterson added the comment: 2012/2/28 Brett Cannon : > > Brett Cannon added the comment: > > OK, then I will make this happen. People care whether it take an int or a > PyObject? That seems to be the only open question. Probably int if it goes in fileutils. -- _

[issue14153] Expose os.device_encoding() at the C level

2012-02-28 Thread Brett Cannon
Brett Cannon added the comment: OK, then I will make this happen. People care whether it take an int or a PyObject? That seems to be the only open question. -- ___ Python tracker _

[issue14153] Expose os.device_encoding() at the C level

2012-02-28 Thread Benjamin Peterson
Benjamin Peterson added the comment: I think fileutils.c is a good place. Then we can kill the import of "os" in io, which would be nice. -- nosy: +benjamin.peterson ___ Python tracker ___

[issue14153] Expose os.device_encoding() at the C level

2012-02-28 Thread Brett Cannon
Brett Cannon added the comment: Either that or PyObject *_Py_device_encoding(PyObject *fd) would help since both _io and posixmodule.c will have a PyObject already for the fd. -- ___ Python tracker __

[issue14153] Expose os.device_encoding() at the C level

2012-02-28 Thread STINNER Victor
STINNER Victor added the comment: If it can help to bootstrap importlib, you can add: PyObject* _Py_device_encoding(int fd); And reuse it in posixmodule.c. -- ___ Python tracker _

[issue14153] Expose os.device_encoding() at the C level

2012-02-28 Thread Antoine Pitrou
Changes by Antoine Pitrou : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue14153] Expose os.device_encoding() at the C level

2012-02-28 Thread Brett Cannon
New submission from Brett Cannon : The _io module imports the os module purely for the use of os.device_encoding(). That function, though, is defined by posix and thus is already available to C code. To avoid this import dependency it would be better to simply expose the function somehow so th