[issue2717] tempfile.mkstempf
André Malo <[EMAIL PROTECTED]> added the comment: It should catch OSError on fdopen, close fd and reraise, I think. -- nosy: +ndparker __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2717> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14226] Expose dict_proxy type from descrobject.c
New submission from André Malo : As discussed in the dev-thread about frozendicts, it would be helpful for providing advisory read-only-dicts, to just expose the dict_proxy type. I suppose, the collections module would be a good place (it just needs to provide the interface to the type, not the whole implementation). -- components: Extension Modules, Interpreter Core messages: 155131 nosy: ndparker priority: normal severity: normal status: open title: Expose dict_proxy type from descrobject.c type: enhancement ___ Python tracker <http://bugs.python.org/issue14226> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14993] GCC error when using unicodeobject.h
New submission from André Malo : GCC error when using unicodeobject.h This ist my first attempt to test an extension with python 3.3. I've been using the 3.3.0a4 tarball. I'm using very strict compiler settings when compiling my extension modules, especially -Wall -Werror (along with a lot more flags, like -pedantic, -std=c89). Including Python.h includes unicodeobject.h which emits: /usr/include/python3.3/unicodeobject.h:905: error: type of bit-field 'overallocate' is a GCC extension /usr/include/python3.3/unicodeobject.h:908: error: type of bit-field 'readonly' is a GCC extension Maybe these should just be (unsigned) ints or something? -- components: Extension Modules, Interpreter Core messages: 162229 nosy: ndparker priority: normal severity: normal status: open title: GCC error when using unicodeobject.h type: compile error versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue14993> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14994] GCC error when using pyerrors.h
New submission from André Malo : GCC error when using pyerrors.h This ist my first attempt to test an extension with python 3.3. I've been using the 3.3.0a4 tarball. I'm using very strict compiler settings when compiling my extension modules, especially -Wall -Werror (along with a lot more flags, like -pedantic, -std=c89). Including Python.h includes pyerrors.h which emits: /usr/include/python3.3/pyerrors.h:91:8: error: "__GNUC_MAJOR__" is not defined /usr/include/python3.3/pyerrors.h:92:8: error: "__GNUC_MAJOR__" is not defined I'm not sure, which of the compiler flags is responsible for dropping those macros. Simple defined() checks should fix that problem though. -- components: Extension Modules, Interpreter Core messages: 162230 nosy: ndparker priority: normal severity: normal status: open title: GCC error when using pyerrors.h type: compile error versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue14994> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14993] GCC error when using unicodeobject.h
André Malo added the comment: I'm not talking about compiling python but my extension module. I *do* try supporting c89. Also relying on implementation extensions is bad style. I think, there's a huge difference between public header files (standards are good) and linked C code (do whatever you like, although standards are good here as well). OTOH, is there a real difference between char:1 and int:1? That's what we're actually discussing here. If not, I suggest simply using int:1 and be done with it. -- ___ Python tracker <http://bugs.python.org/issue14993> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
