Re: [Python-Dev] Issue #8863 adds a new?PYTHONNOFAULTHANDLER?environment variable
On Wed, Dec 22, 2010 at 9:26 PM, Victor Stinner vstin...@edenwall.com wrote: If the kernel doesn't do that for us, I suppose that the compiler or something else does it for us. GCC does this for you if you declare your function with __attribute__(signal). In general, the compiler doesn't know that a function will be used as a signal and no portable way to indicate this. Anyway, it would just be horrible if a signal handler was responsible to save/restore integer registers. Horrible or not, the existence of __attribute__(signal) seems to indicate that this is the case on some platform, or at least was historically. I don't know whether it's the case now on any platform that Python supports. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Breaking undocumented API
On Mon, Nov 8, 2010 at 2:07 PM, Raymond Hettinger raymond.hettin...@gmail.com wrote: On Nov 8, 2010, at 11:58 AM, Brett Cannon wrote: I think we need to, as a group, decide how to handle undocumented APIs that don't have a leading underscore: they get treated just the same as the documented APIs, or are they private regardless and thus we can change them at our whim? To start with, it doesn't hurt for a maintainer to add an __all__ entry and to only document the parts of the API we think need to be exposed. That way, we can at least declare the parts that are intended to be public on a go-forward basis. This does hurt because anyone who was relying on import * to get a name which is now omitted from __all__ is going to upgrade and find their program failing with NameErrors. This is a backwards compatible change and shouldn't happen without a deprecation warning first. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] bugs.python.org not responding (Was: rlcompleter -- auto-complete dictionary keys (+ tests))
On Sun, Nov 7, 2010 at 9:07 AM, Valery Khamenya khame...@gmail.com wrote: Can you post your patch on bugs.python.org? the site is not working currently. Yes, it is down for me too, trying from multiple hosts. It was up approximately an hour ago, but has now been unresponsive for the past twenty or thirty minutes. I cannot even ping bugs.python.org. The main python.org site seems to be fine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] test_grp regression test fails with NIS entries present
The regression tests for py3k (or, I think, any branch) fail on one of my machines because test_grp chokes if /etc/group contains a + line, which is a directive to pull information from NIS. The test enumerates all entries in /etc/group using grp.getgrall() and verifies that it can look up each entry by name using grp.getgrnam(). The current behavior of grp.getgrall() is to return entries whose names start with plus or minus signs (NIS-related lines) as if they were regular entries. The result is that the test tries to look up the name + and fails because no entry is found. It turns out that a bug on this issue has existed since 2003: http://bugs.python.org/issue775964 The bug originally indicated that the problem is specific to Red Hat, but that is not the case because I ran into it on Debian Squeeze. According to a comment on the bug, this syntax in the group file has been deprecated for a long time, which is why the issue rarely comes up. I believe the right thing to do at this point is to keep the behavior of grp.getgrall(), but document that it will return NIS-related lines along with regular entries and to modify the test to not try to look up those entries with grp.getgrnam(). I've attached a patch to the bug that makes these changes and results in the test passing. Is it possible that someone can review/ checkin the patch? Thanks. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] closing files and sockets in a timely manner in the stdlib
On Sat, Oct 30, 2010 at 12:06 PM, Glyph Lefkowitz gl...@twistedmatrix.com wrote: That path (and anything below /proc, really) is a list of open file descriptors specifically on Linux, not *nix. Also on linux, you can avoid your pid here by just doing /proc/self. A more portable (albeit not standard) path for what file descriptors do I have open is /dev/fd/. This is supported via a symlink to /proc/self on all the Linuxes I've tested on. There's no portable standard equivalent for not-yourself processes that I'm aware of, though. See more discussion here: http://twistedmatrix.com/trac/ticket/4522. lsof(8) is available for Linux, FreeBSD, Mac any many other *nixes: http://en.wikipedia.org/wiki/Lsof ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
