[issue11717] conflicting definition of ssize_t in pyconfig.h
Wolfgang Rohdewald wolfg...@rohdewald.de added the comment: types.h is from kdewin/include/msvc/sys git clone git://anongit.kde.org/kdewin types.h uses SSIZE_T but that is nowhere defined in KDE, so it must be the original one from msvc -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11717 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11393] Integrate faulthandler module into Python 3.3
STINNER Victor victor.stin...@haypocalc.com added the comment:
- speed up the test: because dump_backtraces_later() has now a
subsecond resolution, we can use sleep of 50 ms instead of 1 sec
This is too short, there may be random failures on some slow buildbots.
IMO, 0.5s is the minimum you can use.
Ok, changed.
The docstring is outdated.
fixed
It also seems the cancel option isn't
useful anymore, you could remove it and simplify the test.
cancel is used by test_dump_tracebacks_later_repeat_cancel() to check
that faulthandler.cancel_dump_tracebacks_later() did cancel the last
dump_backtraces_later() request.
+process = script_helper.spawn_python('-c', code)
+stdout, stderr = process.communicate()
Shouldn't you check the return code as well?
Yes, except for fatal errors, because the C library exits with a
non-zero exit code (e.g. 139 for a SIGSEGV on Linux). I added a check on
the exit code.
+code = \n.join(code)
Again, I think it would make the code simpler and more maintainable if
you used triple-quoted strings instead of lists/tuples.
Ok ok, done
When you launch a waiting thread in a subprocess, I think it's better to
set it in daemon mode so as to avoid blocking if the main thread raises
an exception.
I doesn't know that. fixed
You have a #ifdef MS_WINDOWS in check_signum() but that function is
not compiled under Windows (it is inside #ifdef FAULTHANDLER_USER).
Ah yes, the code became useless: removed
--
Other changes:
- faulthandler_fatal_error() calls the previous signal handler using
raise(signum). Before, the signal was raised again because the same
instruction was executed again, and it raised the same fault. But if the
user sends manually a fatal signal to the process, the signal was
ignored because of the fault handler (but the traceback was displayed).
- use SA_NODEFER and SA_RESTART flags in enable() and register()
- faulthandler_get_fileno() accepts fileno()==0
- cleanup the doc
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11393
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11393] Integrate faulthandler module into Python 3.3
Changes by STINNER Victor victor.stin...@haypocalc.com: Added file: http://bugs.python.org/file21470/a979bb83a94b.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11393] Integrate faulthandler module into Python 3.3
Changes by STINNER Victor victor.stin...@haypocalc.com: Removed file: http://bugs.python.org/file21467/c684b1e59aaa.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8052] subprocess close_fds behavior should only close open fds
Charles-Francois Natali neolo...@free.fr added the comment: I wonder whether the Java people are simply unaware of the potential problem? Or perhaps they have checked the Linux and Solaris implementations of readdir() and confirmed that it is in fact safe on those platforms. Even if this is the case, I would be wary of doing things the same way - there's no guarantee that the implementation won't change out from underneath us. The problem is not so much readdir: if you look at the source code (http://fxr.googlebit.com/source/lib/libc/gen/readdir.c), it doesn't do much apart from locking a mutex private to the related DIR *, so as long as you pass it a DIR * not referenced elsewhere (which would be the case since it would call opendir between the fork and exec), it should be ok. The man page (http://pubs.opengroup.org/onlinepubs/007908799/xsh/readdir.html) also makes it clear: After a call to fork(), either the parent or child (but not both) may continue processing the directory stream using readdir(), rewinddir() or seekdir(). If both the parent and child processes use these functions, the result is undefined. The problem is more with opendir, which needs to allocate memory for the struct dirent before calling getdents syscall. I agree with you, we should definitely favor correctness over efficiency. As for the other approach, I'm not aware of any portable way to determine if a program is multi-threaded. Also, as noted by Victor, there might be room for some subtle races (Python-registered signal handlers are called synchronously from the main eval loop with the GIL held, so I don't think there should be a problem there, but you might have a problem with C-extension registered signal handlers). Finally, looking at this thread http://lists.freebsd.org/pipermail/freebsd-hackers/2007-July/021132.html, it seems that some closefrom implementations are definitely not async-safe, which is a pity... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8052 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11717] conflicting definition of ssize_t in pyconfig.h
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Should Python.h systematically avoid defining symbols without a Py prefix? See attached patch, which defines Py_ssize_t in pyconfig.h. The same can be said for other symbols defined there: pid_t, copysign, hypot. -- keywords: +patch nosy: +amaury.forgeotdarc Added file: http://bugs.python.org/file21472/no-ssize_t.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11717 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11155] multiprocessing.Queue's put() signature differs from docs
Ezio Melotti ezio.melo...@gmail.com added the comment: Technically this is a backward-incompatible change, because it breaks code that uses obj=foo explicitly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9285] A decorator for cProfile and profile modules
Tennessee Leeuwenburg tleeuwenb...@gmail.com added the comment: I have been working on a similar idea. I just wanted to raise an issue I ran into which might affect this code also. The decorated function ended up with a different function signature to the original inner function. This can be important sometimes. I had to use the decorator.decorator module to give the outer function the same signature as the inner function. -- nosy: +tleeuwenb...@gmail.com ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9285 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11720] PyErr_WriteUnraisable while running cProfile
New submission from Tennessee Leeuwenburg tleeuwenb...@gmail.com: I am happy to come up with a minimal test for this if that would help, but repeating the problem is not hard. Take a Python2.7 interpreter, install the decorator module from PyPi, and also the code at https://bitbucket.org/tleeuwenburg/benchmarker.py/. Running test_benchmarker.py will cause the problem. Exception TypeError: 'str' object is not callable in '/tmp/benchlog/2011/30/2011_03_30_09_41.pstats' ignored I've tracked this message down and it's likely being writted to stdout by errors.c, where unraisable exceptions are handled. Using hotshot, and otherwise the same code, the error does not occur. Diagnosing the true cause of this issue is probably beyond me, but I'm more than happy to try to come up with a more minimal example or help any way I can. -- components: Interpreter Core messages: 132577 nosy: tleeuwenb...@gmail.com priority: normal severity: normal stage: test needed status: open title: PyErr_WriteUnraisable while running cProfile type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11720] PyErr_WriteUnraisable while running cProfile
Tennessee Leeuwenburg tleeuwenb...@gmail.com added the comment: Never mind, I was doing something stupid. The error message doesn't really make it terribly obvious, but the cause is in my code. -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11393] Integrate faulthandler module into Python 3.3
STINNER Victor victor.stin...@haypocalc.com added the comment: faulthandler_fatal_error() calls the previous signal handler using raise(signum) It doesn't work as expected on Windows: Windows doesn't call its own signal handler anymore. Use the previous code (only on Windows). I also added a test for stack overflow: it fails on FreeBSD because I called sigaltstack() with the wrong arguments. It is now fixed. test_faulthandler pass on Linux, Windows and FreeBSD. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9067] Use macros from pyctype.h
Changes by Andrej Krpic akrpi...@gmail.com: -- nosy: +akrpic77 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9067 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10966] eliminate use of ImportError implicitly representing SkipTest
Changes by Andrej Krpic akrpi...@gmail.com: -- nosy: +akrpic77 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10966 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9067] Use macros from pyctype.h
Stefan Krah stefan-use...@bytereef.org added the comment: Sandro Tosi rep...@bugs.python.org wrote: Hi Stefan, can you please expand a bit this issue and details the places you think can benefit from pyctype macros? you know, a patch would be the best :) Indeed. While working on #9036 I thought that there were several places that could use the macros. I opened this as a reminder for myself but then got sidetracked, so now I'll have to search for the precise locations again. -- priority: normal - low ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9067 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11715] Building Python on multiarch Debian and Ubuntu
Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11721] socket.accept() with a timout socket creates bogus socket
New submission from Kristján Valur Jónsson krist...@ccpgames.com: I found this defect at PyCon 2011 after spending a lot of type fidgeting with ssl. The test_ssl.py unittest was using timeout on accept sockets and it was working fine there, but not with the code I was working out. Turns out that _ssl.py resets the timeout state of sockets, but not regular sockets. In short: If you have a socket with settimeout(1), then accept a connection on it, the new socket will have gettimeout()==None, but its state will still (internally) be non-blocking. The attached script demonstrates the issue. This is an issue with all versions of python from 2.5 upwards. There are basically two things we can do to fis this: 1) retain gettimeout()=None but internally make sure we set the resulting socket to blocking mode 2) have the accepted socket inherit the timeout properties of the parent socket properly, and so inherit its timeout value too. Number 2 is more in line with expected BSD socket behaviour that sockets at least inherit the non-blocking attribute of their parent socket. -- components: IO files: bug.py messages: 132581 nosy: krisvale priority: normal severity: normal status: open title: socket.accept() with a timout socket creates bogus socket versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file21473/bug.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11721 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11721] socket.accept() with a timout socket creates bogus socket
Changes by Kristján Valur Jónsson krist...@ccpgames.com: -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11721 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11721] socket.accept() with a timout socket creates bogus socket
Antoine Pitrou pit...@free.fr added the comment: In short: If you have a socket with settimeout(1), then accept a connection on it, the new socket will have gettimeout()==None, but its state will still (internally) be non-blocking. The attached script demonstrates the issue. This should have been fixed in ed0259230611. Can you confirm? -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11721 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11717] conflicting definition of ssize_t in pyconfig.h
Changes by Wolfgang Rohdewald wolfg...@rohdewald.de: -- nosy: +mhammond ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11717 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11721] socket.accept() with a timout socket creates bogus socket
Kristján Valur Jónsson krist...@ccpgames.com added the comment: I cannot see from the link to which branch that was committed, or what revision. But I assume it is the default branch. I can confirm that this appears to be fixed. The corresponding defect has a long (and bothersome) discussion. I am, however, surprised that this was not considered a bug and backported. The bug is pretty clear: socket.gettimeout() returns None, and yet socket.recv() returns in EWOULDBLOCK. This is clearly against spec, since the gettimeout() == None means that the socket is supposed to be blocking. I can agree with the fix (my number 1 suggestion) but I would have liked to see it done in socketmodule.c where the timeout semantics are all defined, rather than as a cludgy special case in socket.py -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11721 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11721] socket.accept() with a timout socket creates bogus socket
Antoine Pitrou pit...@free.fr added the comment: The corresponding defect has a long (and bothersome) discussion. I am, however, surprised that this was not considered a bug and backported. I think Martin's argument was that it could break compatibility. I can agree with the fix (my number 1 suggestion) but I would have liked to see it done in socketmodule.c where the timeout semantics are all defined, rather than as a cludgy special case in socket.py There's definitely a reason for doing it in socket.py rather than socketmodule.c, although I don't remember which one. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11721 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11393] Integrate faulthandler module into Python 3.3
Changes by STINNER Victor victor.stin...@haypocalc.com: Added file: http://bugs.python.org/file21474/4adbea7c832e.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11647] function decorated with a context manager can only be invoked once
ysj.ray ysj@gmail.com added the comment: Got it. Here is my updated patch. Not sure if the doc is proper. -- Added file: http://bugs.python.org/file21475/issue_11647_2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11647 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11393] Integrate faulthandler module into Python 3.3
Changes by STINNER Victor victor.stin...@haypocalc.com: Removed file: http://bugs.python.org/file21470/a979bb83a94b.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11393] Integrate faulthandler module into Python 3.3
Changes by STINNER Victor victor.stin...@haypocalc.com: Added file: http://bugs.python.org/file21476/f5a11df83d98.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11393] Integrate faulthandler module into Python 3.3
Changes by STINNER Victor victor.stin...@haypocalc.com: Removed file: http://bugs.python.org/file21474/4adbea7c832e.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11393] Integrate faulthandler module into Python 3.3
STINNER Victor victor.stin...@haypocalc.com added the comment: My TODO list is empty (the last item was fix register() to be signal safe) so I think that the patch is ready to be commited. As I wrote, I did some tests on FreeBSD, found bugs and fixed them. I also fixed the weird behaviour if the user sends manually a fatal signal (like SIGSEGV): it is no more ignored. And I patched test_faulthandler to not create core files. On Windows, there is still a popup warning the user a fatal error occured. I don't know how to disable (temporary) this popup. Here is the updated patch and I hope the final patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11654] errors in atexit hooks don't change process exit code
ysj.ray ysj@gmail.com added the comment: see #1257 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11654 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11393] Integrate faulthandler module into Python 3.3
Antoine Pitrou pit...@free.fr added the comment:
- speed up the test: because dump_backtraces_later() has now a
subsecond resolution, we can use sleep of 50 ms instead of 1 sec
This is too short, there may be random failures on some slow buildbots.
IMO, 0.5s is the minimum you can use.
+def _check_dump_tracebacks_later(self, repeat, cancel, filename):
+
+Call dump_tracebacks_later() two times, or three times if
repeat is True.
+Check the output: the traceback may be written 1, 2 or 3 times
+depending on repeat and cancel options.
+
+Raise an error if the output doesn't match the expect format.
+
The docstring is outdated. It also seems the cancel option isn't
useful anymore, you could remove it and simplify the test.
+process = script_helper.spawn_python('-c', code)
+stdout, stderr = process.communicate()
Shouldn't you check the return code as well?
+code = \n.join(code)
Again, I think it would make the code simpler and more maintainable if
you used triple-quoted strings instead of lists/tuples.
When you launch a waiting thread in a subprocess, I think it's better to
set it in daemon mode so as to avoid blocking if the main thread raises
an exception.
You have a #ifdef MS_WINDOWS in check_signum() but that function is
not compiled under Windows (it is inside #ifdef FAULTHANDLER_USER).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11393
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7443] test.support.unlink issue on Windows platform
Antoine Pitrou pit...@free.fr added the comment: * Patch Py_DeleteFileW in posixmodule.c so that it renames before deleting: should solve the problem overall but obviously has a possible wider impact, in general and on performance in particular. This rename might be a simple rename-to-guid or something more sophisticated such as the rename-to-recycler which cygwin uses. * Patch support.unlink in the test package to do the rename dance on the basis that it'll fix at least some of the problems with less impact overall. Opinions? I'm willing to do either. Well, since I'm not a Windows expert, I can only give an intuitive opinion. I think that we should start with patching support.unlink(); tweaking Py_DeleteFile() so as to do something more sophisticated than a simple removal sounds like it could hide some behaviour change that could hit some legitimate uses. (as an aside, for higher-level variants of OS functions, the shutil may be an appropriate recipient) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7443 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1257] atexit errors should result in nonzero exit code
ysj.ray ysj@gmail.com added the comment: I think there is no need to implement this in python2.x since it's a behavior change which could introduce some compatibility issues to someone's code, besides in 2.x both sys.exitfunc and atexit module should be considered, that makes the code looks complex. The sys.exitfunc is removed in 3.x. +1 on only implementing it in 3.3. -- nosy: +ysj.ray versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1257 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags
Kristján Valur Jónsson krist...@ccpgames.com added the comment: Please see issue 11721 where I was commenting on the same. I don't think the documentation makes it clear that socket.gettimeout() can be incorrect (i.e. return None when the socket is non-blocking). I also don't think there is a portable way to detect the NBIO attribute of a socket, so we still have a case of socket.gettimeout() not accurately reflecting the blocking state of the socket. If people don't think it is a bug, then this fact should be documented. I personally think that this logic should go into socketmodule.c where the rest of the timeout logic sits, rather than be exctracted like this out into the python world. Finally, IMHO this is a bug that should be backported as far back as possible. Cheers! -- nosy: +krisvale ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7995 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11721] socket.accept() with a timout socket creates bogus socket
Changes by Kristján Valur Jónsson krist...@ccpgames.com: -- resolution: - duplicate status: open - closed superseder: - On Mac / BSD sockets returned by accept inherit the parent's FD flags ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11721 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags
Antoine Pitrou pit...@free.fr added the comment: I also don't think there is a portable way to detect the NBIO attribute of a socket, so we still have a case of socket.gettimeout() not accurately reflecting the blocking state of the socket Which case? I personally think that this logic should go into socketmodule.c where the rest of the timeout logic sits, rather than be exctracted like this out into the python world. I think practicality beats purity. If putting it in socket.py ends up producing bugs, we'll have to consider moving it to the C extension. Until then, the Python code has the advantage of being clear and concise. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7995 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags
Kristján Valur Jónsson krist...@ccpgames.com added the comment: socket.defaulttimeout(None) s = socket.socket() s.settimeout(0) #nonblocking s.bind() s2, a = s.accept() print s2.gettimeout() #prints ´none´, meaning blocking s2.receive(10) #raises EWOULDBLOCK error, since internally it is non-blocking I don't agree with practicality vs. purity, particularly when trying to understand the timeout logic. Most of the timeout logic is implemented in c and never touched by python, in init_sockobject(). But then you tack on extra logic in socket.py, in what is even a socket object wrapper. This means that any module that uses the pure _socket.socket object, such as C extensions, will not get the correct behaviour. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7995 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags
Antoine Pitrou pit...@free.fr added the comment: socket.defaulttimeout(None) s = socket.socket() s.settimeout(0) #nonblocking s.bind() s2, a = s.accept() print s2.gettimeout() #prints ´none´, meaning blocking s2.receive(10) #raises EWOULDBLOCK error, since internally it is non-blocking Could you post working Python 3 code which demonstrates the issue on 3.3? This means that any module that uses the pure _socket.socket object, such as C extensions, will not get the correct behaviour. Using undocumented implementation details (such as the _socket module) is, AFAIK, unsupported. Anyway, if you want the code to be changed, please propose a patch so that it can be judged on its own merits (together with tests that demonstrate the improvement, if any). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7995 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11722] mingw64 does not link when building extensions
New submission from Jason Morgan jas...@picochip.com: Bulding a simple extension (the spam example) fails with mingw64. in modsupport.h, the following is used to detect 64bit, it does not work with mingw64. #if SIZEOF_SIZE_T != SIZEOF_INT /* On a 64-bit system, rename the Py_InitModule4 so that 2.4 modules cannot get loaded into a 2.5 interpreter */ #define Py_InitModule4 Py_InitModule4_64 #endif This code never compiles, you can test this by placing similar code and filling it with rubbish. This means it thinks the extension is being built on a 32bit compiler and creates the wrong call for Py_InitModule. Workaround: Explicitly calling Py_InitModule4_64() in extension and declaring Py_InitModule4_64(...) in code. Note this does not complain about re-declaration and builds OK because declaration is wrong. e.g. //m=Py_InitModule(spam, SpamMethods); m = Py_InitModule4_64(spam, SpamMethods,(char *)NULL, (PyObject *)NULL, PYTHON_API_VERSION); Or, a better more portable permanent fix, define WIN64 in code and modify modsupport.h: #if SIZEOF_SIZE_T != SIZEOF_INT || defined(WIN64) /* On a 64-bit system, rename the Py_InitModule4 so that 2.4 modules cannot get loaded into a 2.5 interpreter */ #define Py_InitModule4 Py_InitModule4_64 #endif I am sure there are other, more standard ways. -- components: Extension Modules messages: 132595 nosy: moog priority: normal severity: normal status: open title: mingw64 does not link when building extensions type: compile error versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11722 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11393] Integrate faulthandler module into Python 3.3
STINNER Victor victor.stin...@haypocalc.com added the comment: I merged the faulthandler branch into the default branch. I removed __version__ field: the Python version should be enough. I also fixed an infinite loop raised by test_capi. test_faulthandler pass on Solaris and OpenIndiana, but it fails on PPC: == FAIL: test_enable_file (test.test_faulthandler.FaultHandlerTests) -- Traceback (most recent call last): File /Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/test/test_faulthandler.py, line 166, in test_enable_file filename=filename) File /Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/test/test_faulthandler.py, line 84, in check_fatal_error self.assertEqual(lines, expected) AssertionError: Lists differ: ['Fatal Python error: Bus erro... != ['Fatal Python error: Segmenta... First differing element 0: Fatal Python error: Bus error Fatal Python error: Segmentation fault - ['Fatal Python error: Bus error', + ['Fatal Python error: Segmentation fault', '', 'Traceback (most recent call first):', ' File string, line 4 in module'] == FAIL: test_enable_threads (test.test_faulthandler.FaultHandlerTests) -- Traceback (most recent call last): File /Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/test/test_faulthandler.py, line 176, in test_enable_threads all_threads=True) File /Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/test/test_faulthandler.py, line 84, in check_fatal_error self.assertEqual(lines, expected) AssertionError: Lists differ: ['Fatal Python error: Bus erro... != ['Fatal Python error: Segmenta... First differing element 0: Fatal Python error: Bus error Fatal Python error: Segmentation fault - ['Fatal Python error: Bus error', + ['Fatal Python error: Segmentation fault', '', 'Current thread XXX:', ' File string, line 3 in module'] == FAIL: test_gil_released (test.test_faulthandler.FaultHandlerTests) -- Traceback (most recent call last): File /Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/test/test_faulthandler.py, line 154, in test_gil_released 'Segmentation fault') File /Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/test/test_faulthandler.py, line 84, in check_fatal_error self.assertEqual(lines, expected) AssertionError: Lists differ: ['Fatal Python error: Bus erro... != ['Fatal Python error: Segmenta... First differing element 0: Fatal Python error: Bus error Fatal Python error: Segmentation fault - ['Fatal Python error: Bus error', + ['Fatal Python error: Segmentation fault', '', 'Traceback (most recent call first):', ' File string, line 3 in module'] == FAIL: test_sigfpe (test.test_faulthandler.FaultHandlerTests) -- Traceback (most recent call last): File /Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/test/test_faulthandler.py, line 104, in test_sigfpe 'Floating point exception') File /Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/test/test_faulthandler.py, line 84, in check_fatal_error self.assertEqual(lines, expected) AssertionError: Lists differ: [] != ['Fatal Python error: Floating... Second list contains 4 additional elements. First extra element 0: Fatal Python error: Floating point exception - [] + ['Fatal Python error: Floating point exception', + '', + 'Traceback (most recent call first):', + ' File string, line 3 in module'] == FAIL: test_sigsegv (test.test_faulthandler.FaultHandlerTests) -- Traceback (most recent call last): File /Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/test/test_faulthandler.py, line 93, in test_sigsegv 'Segmentation fault') File /Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/test/test_faulthandler.py, line 84, in check_fatal_error self.assertEqual(lines, expected) AssertionError: Lists differ: ['Fatal Python error: Bus erro... != ['Fatal Python error: Segmenta... First differing element 0: Fatal Python error: Bus error Fatal Python error: Segmentation fault - ['Fatal Python error: Bus error', + ['Fatal Python error: Segmentation fault', '', 'Traceback (most recent call first):', ' File string, line 3 in module'] -- -- ___
[issue11723] No proper support for mingw64 - patch to add
New submission from Jason Morgan jas...@picochip.com: Python2.7 has no proper support for mings64. You can use environment path to trick compiler into using mings64, but this will cause conflict with other builds. Adding a mings64 compiler options is much more sensible as both mingw32 and mings64 can co-exist. (mingw64 has a prefix for all it's exe's) Suggest following patch, tested with mingw-w64-1.0-bin_i686-mingw_20110328 and Python-2.7.1(x64) on Windows7. Diff attached. See related issue 11722 -- components: Extension Modules files: mingw64.diff keywords: patch messages: 132597 nosy: moog priority: normal severity: normal status: open title: No proper support for mingw64 - patch to add type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file21477/mingw64.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11723 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags
Daniel Stutzbach stutzb...@google.com added the comment: I'm confused by the patch (ed0259230611). The patch comment and the NEWS item state the returned socket is now always non-blocking but the code change adds sock.setblocking(True). -- nosy: +stutzbach ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7995 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11722] mingw64 does not link when building extensions
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: What are the values of SIZEOF_SIZE_T and SIZEOF_INT with this compiler? I'd expect them to be respectively 8 and 4. -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11722 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10219] BufferedReader.read1 does not check for closed file
Sandro Tosi sandro.t...@gmail.com added the comment:
Hi,
on a freshly built python 3.3 I got:
$ ./python
Python 3.3a0 (default:22ae2b002865, Mar 30 2011, 20:18:39)
[GCC 4.4.5] on linux2
Type help, copyright, credits or license for more information.
f = open('foo', 'rb')
print(f.read1(1)) # OK
b''
f.close()
print(f.read1(5)) # expected ValueError(I/O operation on closed file)
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: I/O operation on closed file
print(f.peek()) # expected ValueError(I/O operation on closed file)
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: I/O operation on closed file
so it seems it's been fixed in the meantime. Do you have an example for
BufferedReader?
--
nosy: +sandro.tosi
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10219
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags
Kristján Valur Jónsson krist...@ccpgames.com added the comment: Antoine, absolument. Please see attached file bug.py As for a different patch, we should agree what behaviour should be expected. I don't think it is possible to rely on some platform specific behaviour. This is because it is in general not possible to query the blokcking state of a socket. Instead we should simply define it for python, and in accordance to established tradition, namely that defaulttimeout prevails. Btw, defaulttimeout(None) doesn't mean that that there is no default, it means that the default is blocking. -- Added file: http://bugs.python.org/file21478/bug.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7995 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags
Antoine Pitrou pit...@free.fr added the comment: Antoine, absolument. Please see attached file bug.py Ah, thanks, I see. But this is not caused by this issue. It seems to come from 12442ac3f7dd. Instead we should simply define it for python, and in accordance to established tradition, namely that defaulttimeout prevails. That would be the second behaviour change in two versions. I think we could/should simply fix the advertised behaviour, as in http://docs.python.org/dev/library/socket.html#timeouts-and-the-accept-method Btw, defaulttimeout(None) doesn't mean that that there is no default, it means that the default is blocking. Sure, but generally it means that the user didn't *set* a default at all. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7995 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11714] threading.Semaphore does not use try...finally
Antoine Pitrou pit...@free.fr added the comment: What version of Python did you make your patch against? It failed applying against the default branch. You might want to make sure you are using an up-to-date source tree, see: http://docs.python.org/devguide/setup.html#getting-the-source-code -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11714 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11688] SQLite trace callback
Antoine Pitrou pit...@free.fr added the comment: The patch looks good to me, thank you! Gerhard, would you like to tackle this? Otherwise I'll commit in a couple of days. -- stage: patch review - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11688 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10234] ResourceWarnings in test_subprocess
Sandro Tosi sandro.t...@gmail.com added the comment: On a freshly built 3.3 I don't get those RW anymore: $ ./python -bb -E -Wd -m test -r -w -uall test_subprocess Using random seed 7436992 [1/1] test_subprocess . this bit of output is from a test of stdout in a different process ... . this bit of output is from a test of stdout in a different process ... . this bit of output is from a test of stdout in a different process ... . this bit of output is from a test of stdout in a different process ... 1 test OK. As briefly discussed on IRC, I'm closing this as out-of-date. -- nosy: +sandro.tosi resolution: - out of date status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10234 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5863] bz2.BZ2File should accept other file-like objects. (issue4274045)
Antoine Pitrou pit...@free.fr added the comment: Nadeem, Can I ask that you not commit this patch until the CA has been submitted? I will need to clear it with my employer, and it might complicate things if the code in question has already been committed. Apparently the PSF has received your contributor agreement. Does it mean the situation is cleared? I plan to do a review of your latest patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5863 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11723] No proper support for mingw64 - patch to add
Martin v. Löwis mar...@v.loewis.de added the comment: What is mings64? -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11723 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11688] SQLite trace callback
Torsten Landschoff t.landsch...@gmx.net added the comment: The patch looks good to me, thank you! Gerhard, would you like to tackle this? Otherwise I'll commit in a couple of days. What I am still wondering about is if it would make sense to use the text factory here. It might make sense to pass through the bytes directly without translation into unicode (especially for big amounts). OTOH, this is mostly a debugging aid and nothing that would be enabled in production. And premature optimization is the root of all evil... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11688 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5863] bz2.BZ2File should accept other file-like objects. (issue4274045)
Nadeem Vawda nadeem.va...@gmail.com added the comment: Apparently the PSF has received your contributor agreement. Great; I was just about to send them an email to check. Does it mean the situation is cleared? I plan to do a review of your latest patch. Yes, everything's sorted out. Go ahead :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5863 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11688] SQLite trace callback
Antoine Pitrou pit...@free.fr added the comment: OTOH, this is mostly a debugging aid and nothing that would be enabled in production. And premature optimization is the root of all evil... Agreed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11688 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Changes by Renaud Blanch rndbl...@gmail.com: -- nosy: +rndblnch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11393] Integrate faulthandler module into Python 3.3
STINNER Victor victor.stin...@haypocalc.com added the comment: http://hg.python.org/features/faulthandler/rev/0943ef33495a should fix test_faulthandler to support SIGBUS on reading from NULL. But it doesn't fix the failure on SIGFPE yet. I'm running the buildbot to check if it's better or not. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module should allow DDL statements in transactions
Torsten Landschoff t.landsch...@gmx.net added the comment: The attached patch is an updated version which adds a bit of documentation. -- Added file: http://bugs.python.org/file21479/sqlite_transaction_config_v2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10740 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5114] 2.7: test_threading hangs on Solaris
Changes by Terry J. Reedy tjre...@udel.edu: -- title: 2.5.4.3 and 2.6.2 / test_threading hangs on Solaris - 2.7: test_threading hangs on Solaris ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5114 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11703] Bug in python = 2.7 with urllib2 fragment
Ivan Ivanenko ivan.ivane...@gmail.com added the comment:
Santa4nt, I think you also need to check case with Redirect Response URL:
print urllib2.urlopen(http://16.foobnix-cms.appspot.com/test_base;).geturl()
python 2.6 returns OK
http://16.foobnix-cms.appspot.com/test_redirect#json={value:'OK'}
python 2.7 returns KO
http://16.foobnix-cms.appspot.com/test_redirect
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11703
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11724] concurrent.futures: executor.submit() runs until completion even when future times out or is canceled
New submission from jenisys jens_en...@web.de: A long running task that is submitted to an ThreadPoolExecutor runs to completion even when the future times out or is canceled. Even executor.shutdown(wait=False) will not help. HOW TO REPEAT: Provide a function which sleeps for 10 seconds. Submit it to a ThreadPoolExecutor. Wait on the future for the result for 2 seconds. OBSERVED BEHAVIOUR: 1. future times out after approx. 2 seconds 2. Process shutdown is delayed by an additional 8 seconds, meaning it waits until submitted task/function has completed. -- components: Library (Lib) messages: 132614 nosy: jenisys priority: normal severity: normal status: open title: concurrent.futures: executor.submit() runs until completion even when future times out or is canceled type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11724 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1777398] IDLE Freezes After Running Scripts
Terry J. Reedy tjre...@udel.edu added the comment: Closing until there is a confirmed problem with current Python. -- resolution: - out of date status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1777398 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11724] concurrent.futures: executor.submit() runs until completion even when future times out or is canceled
Changes by jenisys jens_en...@web.de: Added file: http://bugs.python.org/file21480/test_futures_more3.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11724 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2657] Curses sometimes fails to initialize terminal
Changes by Terry J. Reedy tjre...@udel.edu: -- resolution: - out of date status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2657 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11724] concurrent.futures: executor.submit() runs until completion even when future times out or is canceled
Changes by jenisys jens_en...@web.de: Added file: http://bugs.python.org/file21481/test_futures_more3.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11724 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11724] concurrent.futures: executor.submit() runs until completion even when future times out or is canceled
Changes by jenisys jens_en...@web.de: Removed file: http://bugs.python.org/file21480/test_futures_more3.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11724 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3154] Quick search box renders too wide if font size is large
Changes by Terry J. Reedy tjre...@udel.edu: -- versions: +Python 3.2 -Python 2.6, Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11724] concurrent.futures: executor.submit() runs until completion even when future times out or is canceled
Changes by jenisys jens_en...@web.de: Added file: http://bugs.python.org/file21482/test_futures_more3.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11724 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11724] concurrent.futures: executor.submit() runs until completion even when future times out or is canceled
Changes by jenisys jens_en...@web.de: Removed file: http://bugs.python.org/file21481/test_futures_more3.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11724 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10219] BufferedReader.read1 does not check for closed file
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Indeed, I can't reproduce the issue anymore -- resolution: - out of date status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10219 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10050] urllib.request still has old 2.x urllib primitives
Jeff McNeil j...@jmcneil.net added the comment: I'd be happy to pick some of that stuff up. I'd like to address separately as it keeps fewer concerns in this one patch. I'll grab them once they're created. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10050 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11618] Locks broken wrt timeouts on Windows
Roundup Robot devnull@devnull added the comment: New changeset 9b12af6e9ea9 by Antoine Pitrou in branch '3.2': Issue #11618: Fix the timeout logic in threading.Lock.acquire() under http://hg.python.org/cpython/rev/9b12af6e9ea9 New changeset 9d658f000419 by Antoine Pitrou in branch 'default': Issue #11618: Fix the timeout logic in threading.Lock.acquire() under http://hg.python.org/cpython/rev/9d658f000419 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11618 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11393] Integrate faulthandler module into Python 3.3
Changes by STINNER Victor victor.stin...@haypocalc.com: Added file: http://bugs.python.org/file21483/d4902114f720.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11618] Locks broken wrt timeouts on Windows
Antoine Pitrou pit...@free.fr added the comment: I have now committed the semaphore implementation, so as to fix the issue. Potential performance optimizations can still be discussed, of course (either here or in a new issue, I'm not sure). -- resolution: - fixed stage: - committed/rejected status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11618 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11393] Integrate faulthandler module into Python 3.3
Roundup Robot devnull@devnull added the comment: New changeset b0680b5a5215 by Victor Stinner in branch 'default': Issue #11393: Add the new faulthandler module http://hg.python.org/cpython/rev/b0680b5a5215 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11393] Integrate faulthandler module into Python 3.3
Roundup Robot devnull@devnull added the comment: New changeset df240014e72f by Victor Stinner in branch 'default': Issue #11393: reenable all tests in regrtest.py (wooops, sorry Antoine) http://hg.python.org/cpython/rev/df240014e72f -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11155] multiprocessing.Queue's put() signature differs from docs
Westley Martínez aniko...@gmail.com added the comment: In that case, I've made a patch that changes the documentation so that item is now obj. for Queue.put and Queue.put_nowait. -- Added file: http://bugs.python.org/file21484/doc-11155.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11393] Integrate faulthandler module into Python 3.3
STINNER Victor victor.stin...@haypocalc.com added the comment: First failure: AMD64 Gentoo Wide 3.x. http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%203.x/builds/1363/ [1/1] test_faulthandler test test_faulthandler failed -- Traceback (most recent call last): File /home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/test/test_faulthandler.py, line 165, in test_stack_overflow '(?:Segmentation fault|Bus error)') File /home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/test/test_faulthandler.py, line 95, in check_fatal_error self.assertRegex(output, regex) AssertionError: Regex didn't match: '^Fatal Python error: (?:Segmentation fault|Bus error)\n\nTraceback\\ \\(most\\ recent\\ call\\ first\\):\n File string, line 3 in module$' not found in '' -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11393] Integrate faulthandler module into Python 3.3
STINNER Victor victor.stin...@haypocalc.com added the comment: test_faulthandler failed also on AMD64 OpenIndiana 3.x: regrtest.py (only executing test_faulthandler) was killed after 11 min 20 sec. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11393] Integrate faulthandler module into Python 3.3
Roundup Robot devnull@devnull added the comment: New changeset 25a2aeecb34b by Victor Stinner in branch 'default': Issue #11393: Disable test_stack_overflow of test_faulthandler http://hg.python.org/cpython/rev/25a2aeecb34b -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11393] Integrate faulthandler module into Python 3.3
STINNER Victor victor.stin...@haypocalc.com added the comment: I disabled test_stack_overflow because the test fails on AMD64 Gentoo Wide 3.x, and maybe other buildbots (AMD64 OpenIndiana 3.x?). I fear that the test uses a lot of CPU, memory and/or swap. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11724] concurrent.futures: executor.submit() runs until completion even when future times out or is canceled
Changes by Ned Deily n...@acm.org: -- nosy: +bquinlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11724 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11393] Integrate faulthandler module into Python 3.3
STINNER Victor victor.stin...@haypocalc.com added the comment: stack_overflow.patch should fix AMD64 Gentoo Wide 3.x and AMD64 OpenIndiana 3.x failures. I schedule a test on their custom slaves, but these buildbots are still running test_faulthandler on their 3.x slaves. I interrupted the test, but it doesn't work (click on Cancel doesn't stop the tests). Schedule tests: http://www.python.org/dev/buildbot/all/builders/AMD64%20OpenIndiana%20custom http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%20custom I'm impatient to test regrtest_timeout.patch on x86 XP-4 3.x to try to learn more on test_multiprocessing timeout (1200 seconds)! -- Added file: http://bugs.python.org/file21485/stack_overflow.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11557] Increase coverage in logging module
Roundup Robot devnull@devnull added the comment: New changeset 024967cdc2f0 by Victor Stinner in branch 'default': Issue #11557: disable test_logging.test_no_kwargs (fail on most buildbots) http://hg.python.org/cpython/rev/024967cdc2f0 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11557 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11557] Increase coverage in logging module
STINNER Victor victor.stin...@haypocalc.com added the comment: test_logging.test_no_kwargs fails on AMD64 Snow Leopard 2 3.x, x86 Ubuntu Shared 3.x, sparc solaris10 gcc 3.x, AMD64 Leopard 3.x, x86 XP-4 3.x, x86 Windows7 3.x, x86 Tiger 3.x, PPC Tiger 3.x, ... I disabled the test because it became difficult to see new regressions because of this issue. I'm trying to figure out if my new faulthandler works on not on 3.x buildbots. --- Re-running test 'test_logging' in verbose mode test_flat (test.test_logging.BuiltinLevelsTest) ... ok (...) test_compute_rollover_H (test.test_logging.TimedRotatingFileHandlerTest) ... ok test_compute_rollover_M (test.test_logging.TimedRotatingFileHandlerTest) ... ok test_compute_rollover_MIDNIGHT (test.test_logging.TimedRotatingFileHandlerTest) ... ok test_compute_rollover_S (test.test_logging.TimedRotatingFileHandlerTest) ... ok test_compute_rollover_W0 (test.test_logging.TimedRotatingFileHandlerTest) ... Warning -- logging._handlerList was modified by test_logging test test_logging failed -- Traceback (most recent call last): File /Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/test/test_logging.py, line 2427, in test_no_kwargs self.assertEqual(logging.root.level, logging.WARNING) AssertionError: 20 != 30 -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11557 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8158] Docstring of optparse.OptionParser incomplete
Jeff Ramnani j...@jefframnani.com added the comment: You are correct. I have added 'description' to the docstring of the OptionParser class for 2.7 and default (python3 tip). Here is the patch for python3 tip. -- keywords: +patch Added file: http://bugs.python.org/file21486/issue8151-default.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8158 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8158] Docstring of optparse.OptionParser incomplete
Jeff Ramnani j...@jefframnani.com added the comment: Attaching the same patch for 2.7. -- Added file: http://bugs.python.org/file21487/issue8151-2.7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8158 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10645] Remove egg-info files in stdlib
Senthil Kumaran orsent...@gmail.com added the comment: +1 to removing of the spurious egg-info files. For the folks who are not aware of the multitude 'packaging terms', egg-info files are the first step towards the path leading to more confusion. So cleaning up would be definitely better in the standard distribution. -- nosy: +orsenthil ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10645 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [issue10966] eliminate use of ImportError implicitly representing SkipTest
+1 to the counter argument that Unexpected Skips should not be marked as failures. Also, I like the following proposal of giving better messages on skips useful. On Sat, Mar 26, 2011 at 07:53:34AM +, Ezio Melotti wrote: It's also possible to provide better skip messages, e.g.: -test_winreg skipped -- No module named 'winreg' -test_tk skipped -- No module named '_tkinter' -test_urllibnet skipped -- Use of the `network' resource not enabled +test_winreg skipped -- No module named 'winreg' (winreg is available on windows only) +test_tk skipped -- No module named '_tkinter' (tcl/tk not installed) +test_urllibnet skipped -- Use of the `network' resource not enabled (run the tests with -unetwork or -uall to enable it) ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10632] multiprocessing generates a fatal error
Senthil Kumaran orsent...@gmail.com added the comment: I wonder if this is CentOS and RHEL specific. Unable to reproduce this on Ubuntu. -- nosy: +dmalcolm, orsenthil ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10632 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11724] concurrent.futures: executor.submit() runs until completion even when future times out or is canceled
Brian Quinlan br...@sweetapp.com added the comment: This is the expected behavior. Future.cancel() returns a bool indicating if the future was cancelled or not. If it returns False then there is no way to stop it. The behavior that you are seeing for shutdown is documented as: shutdown(wait=True) ... If wait is True then this method will not return until all the pending futures are done executing and the resources associated with the executor have been freed. If wait is False then this method will return immediately and the resources associated with the executor will be freed when all pending futures are done executing. Regardless of the value of wait, the entire Python program will not exit until all pending futures are done executing. -- resolution: - invalid ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11724 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11725] httplib and urllib2 failed ssl connection httplib.BadStatusLine
New submission from Isaac Salsberg isalsb...@users.sourceforge.net:
https connections fails under intel MAC OS X 10.6.6 and 10.6.7 using httplib
and/or urllib2 connecting to an IIS web server requesting basic authentication
and a client certificate.
This is an issue with MAC OS X 10.6.x, because I tried these very same scripts
under RHES 5 x64 with python 2.6.5 and python 2.7.1 and they both run just fine.
Sample code with urllib2:
import urllib2
response = urllib2.urlopen('https://www.finratrace.org/')
--
Sample code with httplib
import httplib,base64
key,cert=('/tmp/cert_nopwd.pem',)*2
HOSTNAME = 'www.finratrace.org'
username,password='myuser','mypass'
base64string = base64.encodestring('%s:%s' % (username, password))[:-1]
conn = httplib.HTTPSConnection(HOSTNAME,key_file = key,cert_file = cert)
conn.putrequest('GET', '/')
conn.putheader(Authorization, Basic %s % base64string)
conn.endheaders()
response = conn.getresponse()
---
Both samples send the following error:
With python 2.6.1
Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type help, copyright, credits or license for more information.
import urllib2
response = urllib2.urlopen('https://www.finratrace.org/')
Traceback (most recent call last):
File stdin, line 1, in module
File
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib2.py,
line 124, in urlopen
return _opener.open(url, data, timeout)
File
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib2.py,
line 383, in open
response = self._open(req, data)
File
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib2.py,
line 401, in _open
'_open', req)
File
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib2.py,
line 361, in _call_chain
result = func(*args)
File
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib2.py,
line 1138, in https_open
return self.do_open(httplib.HTTPSConnection, req)
File
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/urllib2.py,
line 1103, in do_open
r = h.getresponse()
File
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/httplib.py,
line 950, in getresponse
response.begin()
File
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/httplib.py,
line 390, in begin
version, status, reason = self._read_status()
File
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/httplib.py,
line 354, in _read_status
raise BadStatusLine(line)
httplib.BadStatusLine
==
Same thing happens Using python 2.7.1
Python 2.7.1 (r271:86882M, Nov 30 2010, 10:35:34)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type help, copyright, credits or license for more information.
import httplib,base64
key,cert=('/tmp/cert_nopwd.pem',)*2
HOSTNAME = 'www.finratrace.org'
username,password='myuser','mypass'
base64string = base64.encodestring('%s:%s' % (username, password))[:-1]
conn = httplib.HTTPSConnection(HOSTNAME,key_file = key,cert_file = cert)
conn.putrequest('GET', '/')
conn.putheader(Authorization, Basic %s % base64string)
conn.endheaders()
response = conn.getresponse()
Traceback (most recent call last):
File stdin, line 1, in module
File
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py,
line 1021, in getresponse
return response
File
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py,
line 401, in begin
while True:
File
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py,
line 365, in _read_status
# sending a valid response.
httplib.BadStatusLine: ''
=
I also compiled py 2.7 getting the same error message.
I tried patches from Issue7291, but did not work.
--
assignee: ronaldoussoren
components: Library (Lib), Macintosh
messages: 132636
nosy: isalsberg, ronaldoussoren
priority: normal
severity: normal
status: open
title: httplib and urllib2 failed ssl connection httplib.BadStatusLine
type: resource usage
versions: Python 2.6, Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11725
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11725] httplib and urllib2 failed ssl connection httplib.BadStatusLine
Ronald Oussoren ronaldousso...@mac.com added the comment: The site you mention requires client certificates to log on. On my machine (OSX 10.6) urllib2 example just hangs. I haven't checked yet why this happens, or if this also happens on other OS-es or releases. Other HTTPS sites work fine for me though. Are you sure that the RHES machine doesn't have a special configuration that provides the client certificates? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11725 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
