[issue13756] Python3.2.2 make fail on cygwin
New submission from Holger : Downloaded Python-3.2.2.tar cd Python-3.2.2 ./configure make Fail on: . ranlib libpython3.2m.a make: *** No rule to make target `libpython3.2m.dll.a', needed by `python.exe'. Stop. libpython3.2m.a was built successfully: $ ls -l libpython3.2m.a -rw-r--r--+ 1 hbille Domain Users 7182050 Jan 10 13:31 libpython3.2m.a I am not sure which part is incorrect. The name with or without "dll" -- components: Installation messages: 151014 nosy: holgerd00d priority: normal severity: normal status: open title: Python3.2.2 make fail on cygwin versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue13756> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32715] Make create_unix_server for SOCK_DGRAM work
New submission from holger : The current implementation verifies that the sock passed is a stream socket. This limitation appears to be arbitrary and is limiting. * An AF_UNIX SOCK_DGRAM server socket becomes readable when one can accept(2) it. Just like SOCK_STREAM. * One could provide a different factory to create a reader/writer to use a SOCK_DGRAM socket (but most likely nothing special is needed) * A connected AF_UNIX SOCK_DGRAM socket will work with normal read/write messages just like SOCK_STREAM. AF_UNIX, SOCK_DGRAM is interesting because it provides a reliable transport for messages. This avoids having to write message segmentation or packing messages in any kind of envelope. -- components: asyncio messages: 311188 nosy: asvetlov, holger+lp, yselivanov priority: normal severity: normal status: open title: Make create_unix_server for SOCK_DGRAM work type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue32715> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32715] Make create_unix_server for SOCK_DGRAM work
holger added the comment: Could you please tell me which exact posix document and paragraph says that? In Linux sending can fail but once sendmsg worked the message is enqueued on the other socket (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/unix/af_unix.c?id=110af3acb8cfd79dcb5676a01e07cb2b6afa4c04#n1626). In FreeBSD (http://fxr.watson.org/fxr/source/kern/uipc_usrreq.c?v=FREEBSD10#L911) it looks similar. If the mbuf can't be put into the recvq of the remote socket.. an error will be returned. What about SEQPACKET support? -- ___ Python tracker <https://bugs.python.org/issue32715> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32776] asyncio SIGCHLD scalability problems
New submission from holger :
I intended to use the asyncio framework for building an end-to-end test for our
software. In the test I would spawn somewhere between 5k to 10k processes and
have the same number of sockets to manage.
When I built a prototype I ran into some scaling issues. Instead of launching
our real software I tested it with calls to sleep 30. At some point started
processes would finish, a SIGCHLD would be delivered to python and then it
would fail:
Exception ignored when trying to write to the signal wakeup fd:
BlockingIOError: [Errno 11] Resource temporarily unavailable
Using strace I saw something like:
send(5, "\0", 1, 0) = -1 EAGAIN (Resource temporarily
unavailable)
waitpid(12218, 0xbf8592d8, WNOHANG) = 0
waitpid(12219, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG) = 12219
send(5, "\0", 1, 0) = -1 EAGAIN (Resource temporarily
unavailable)
waitpid(12220, 0xbf8592d8, WNOHANG) = 0
waitpid(12221, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG) = 12221
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=12293, si_uid=1001,
si_status=0, si_utime=0, si_stime=
0} ---
getpid()= 11832
write(5, "\21", 1) = -1 EAGAIN (Resource temporarily
unavailable)
sigreturn({mask=[]})= 12221
write(2, "Exception ignored when trying to"..., 64) = 64
write(2, "BlockingIOError: [Errno 11] Reso"..., 61) = 61
Looking at the code I see that si_pid of the signal will be ignored and instead
wait(2) will be called for all processes. This doesn't seem to scale well
enough for my intended use case.
I think what could be done is one of the following:
* Switch to signalfd for the event notification?
* Take si_pid and instead of just notifying that work is there.. inform about
the PID that exited?
* Use wait(-1,... if there can be only one SIGCHLD handler to collect any dead
child
--
components: asyncio
messages: 311692
nosy: asvetlov, holger+lp, yselivanov
priority: normal
severity: normal
status: open
title: asyncio SIGCHLD scalability problems
___
Python tracker
<https://bugs.python.org/issue32776>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13490] broken downloads counting on pypi.python.org
New submission from holger krekel : Seems like pypi.python.org does not properly maintain download counters anymore, at least for a few packages i looked at like pytest,execnet,tox,nose. -- components: None messages: 148447 nosy: hpk priority: normal severity: normal status: open title: broken downloads counting on pypi.python.org type: behavior ___ Python tracker <http://bugs.python.org/issue13490> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7897] Support parametrized tests in unittest
Changes by holger krekel : -- nosy: +hpk ___ Python tracker <http://bugs.python.org/issue7897> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1589266] bdist_sunpkg distutils command
Holger Joukl added the comment: > Holger, sorry your work has to be rejected. No harm done - kind of paradoxical that my employer allowed me to release the code into the wild but hasn't been willing to let me sign the contribution form, in 4 years. So it's at least out in the open and maybe useful to some (though rather outdated) - and could be moved into some solaris-py bdist_* project. -- ___ Python tracker <http://bugs.python.org/issue1589266> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10548] Error in setUp not reported as expectedFailure (unittest)
Changes by holger krekel : -- nosy: +hpk ___ Python tracker <http://bugs.python.org/issue10548> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10548] Error in setUp not reported as expectedFailure (unittest)
holger krekel added the comment: FWIW i tend to agree and would probably prefer setup/teardown to result in an error rather than be subsumed in an expected-to-fail marked test. I guess if one regards setup/teardown as a place to implement pre/post-conditions than the changes suggested by Michael make more sense. I'd like to see a more "real" use case / user than the abstract case provided here. -- ___ Python tracker <http://bugs.python.org/issue10548> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10548] Error in setUp not reported as expectedFailure (unittest)
holger krekel added the comment: Michael, if you have it i'd like to see the original post/concrete use case. thanks, holger -- ___ Python tracker <http://bugs.python.org/issue10548> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8558] StringIO().truncate causes zero-bytes in getvalue()
New submission from holger krekel : Running the attached file with python3.1.1 works fine, all assertions pass. Running it with 3.1.2 gives me this output: $ python3.1.2/bin/python3.1 stringio_fail.py Traceback (most recent call last): File "stringio_fail.py", line 12, in assert s == "world", repr(s) AssertionError: '\x00\x00\x00\x00\x00world' -- components: IO files: stringio_fail.py messages: 104423 nosy: hpk priority: normal severity: normal status: open title: StringIO().truncate causes zero-bytes in getvalue() type: behavior versions: Python 3.1 Added file: http://bugs.python.org/file17116/stringio_fail.py ___ Python tracker <http://bugs.python.org/issue8558> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8558] StringIO().truncate causes zero-bytes in getvalue()
holger krekel added the comment: Ah, thanks for the pointer. So indeed, for me truncate(0)+seek(0) works fine for all interpreters i care for (python2.4 - 3.1.X), previously truncate(0) was enough. -- ___ Python tracker <http://bugs.python.org/issue8558> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8547] unittest test discovery can fail when package under test is also installed globally
holger krekel added the comment: FWIW checking if an imported module really comes from a certain location and erroring out is also how py.test does it. -- nosy: +hpk ___ Python tracker <http://bugs.python.org/issue8547> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8564] Update documentation on doctest/unittest2 integration
Changes by holger krekel : -- nosy: +hpk ___ Python tracker <http://bugs.python.org/issue8564> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24905] Allow incremental I/O to blobs in sqlite3
Holger Waldmann added the comment: I am looking forward for this to be included. My main use case is on restricted IoT devices, where I need to handle BLOBs of 2MB size. As this is larger than my available RAM, I store need to store them in the filesystem today. This is ugly because it is not part of the atomic commit of the database. I would very much appreciate if I could get a file-like API for BLOBs in sqlite. -- nosy: +waldhol ___ Python tracker <https://bugs.python.org/issue24905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12271] Python 2.7.x on IA64 running SLES 11 SP1
Holger Mickler added the comment: I just stumbled upon the same problem with Python 2.7.3 on SLES 11 SP1 amd64. Obviously, SuSE puts the needed header file into /usr/include/ncurses/, and one can either create a symlink in /usr/include/ or apply a patch to _curses_panel.c: --- Modules/_curses_panel.c.orig2012-05-23 13:34:17.0 +0200 +++ Modules/_curses_panel.c 2012-05-23 13:34:27.0 +0200 @@ -14,7 +14,7 @@ #include "py_curses.h" -#include +#include static PyObject *PyCursesError; Maybe some logic could be put into the build process to automatically handle this? Apparently, configure already knows about the different locations... Regards, Holger -- nosy: +hm ___ Python tracker <http://bugs.python.org/issue12271> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16997] subtests
holger krekel added the comment: On Sun, Feb 10, 2013 at 12:41 PM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > > Please don't commit I think we still need a discussion as to whether > > subtests or paramaterized tests are a better approach. I certainly > > don't think we need both and there are a lot of people asking for > > parameterized tests. > > I think they don't cater to the same crowd. I see parameterized tests as > primarily used by people who like adding formal complexity to their > tests in the name of architectural elegance (decorators, non-intuitive > constructs and other additional boilerplate). Subtests are meant to not > get in the way. IMHO, this makes them more suitable for stdlib > inclusion, while the testing-in-python people can still rely on their > additional frameworks. > Parametrized testing wasn't introduced because I or others like formal complexity. I invented the "yield" syntax that both pytest and nose still support and it was enhanced for several years until it was deemed not fit for a general purpose testing approach. More specifically, if you have functional parametrized tests, they each run relatively slow. People often want to re-run a single failing test or otherwise select tests which use a certain fixture, or send tests to different CPUs to speed up execution. That's all not possible with subtests or am i missing something? That being said, I have plans to support some form of "subtests" for pytest as well, as there are indeed cases where a more lightweight approach fits well, especially for unit- or integration tests where one doesn't care if a group of tests need to be re-run when working on fixing a failure to a single subtest. And where it's usually more about reporting, getting nice debuggable output on failures. I suspect the cases which Antoine refers satisfy this pattern. best, holger -- ___ Python tracker <http://bugs.python.org/issue16997> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16997] subtests
holger krekel added the comment: On Sun, Feb 10, 2013 at 12:43 PM, Nick Coghlan wrote: > > Nick Coghlan added the comment: > > You can use subtests to build parameterized tests, you can't use > parameterized tests to build subtests. I doubt you can implement parametrized tests via subtests especially for functional testing and its fixture needs. The standard library can also > be converted to using subtests *far* more readily than it could be > converted to parameterized tests. I can see that and for this reason and the stdlib's use cases it might make sense to support it. The unittest module is also used in many other contexts so it shouldn't be the only verification criterium. best, holger -- ___ Python tracker <http://bugs.python.org/issue16997> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2943] Distutils should generate a better error message when the SDK is not installed
Holger Waldmann added the comment: On Python 3.3.3 it is even worse. I am using Python 3.3.3 (32bit) on Windows 7 (64bit). Visual Studio C++ 2008 Express Edition is properly installed. Note: I use Python 32bit because Visual Studio C++ 2008 Express Edition includes only the 32bit compiler. Using Google I did find the instructions on http://stackoverflow.com/q/2817869/284795 But they were of no help. There are two problems that are not addressed. Problem #1: distutils/msvc9compiler.py decides to look for the 32bit registry key (because it is a 32bit Python) but it should look for the 64bit registry key (because it is a 64bit Windows). Problem #2: distutils/msvc9compiler.py decides to look for VERSION=10 I did some reverse engineering on the module to find this information. Why is this not documented? After setting VS100COMNTOOLS=%VS90COMNTOOLS% everything worked fine. -- nosy: +waldhol versions: +Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue2943> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6333] logging: ValueError: I/O operation on closed file
holger krekel added the comment: I think the issue is unrelated to py.test - it just presents a use case as it wants to run 1000's of tests and capture stdout/stderr per each test function, cannot guess about a test's logging-usage yet wants to minimize memory/resource usage and close any temporary files it opens. Anyway, a standalone minimal example involving the issue is this: import logging import StringIO stream = StringIO.StringIO() logging.basicConfig(stream=stream) stream.close() # to free memory/release resources At exit logging's shutdown() will try to flush/close resulting in an exception. Is it a problem to have the logging module be a bit more defensive and only try a flush/close if the stream isn't already closed? -- nosy: +hpk ___ Python tracker <http://bugs.python.org/issue6333> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6333] logging: ValueError: I/O operation on closed file
holger krekel added the comment: To recap the use case: stdout is redirected during a test function run which might trigger arbitrary usage of logging-functionality. Not closing the temporary file would mean that there could be as many open files as there are test functions - or one needs to rely on garbage collection for closing the resource - this is generally considered bad practise. So I consider it best practise to do resource cleanup immediately and close the temp file. Note that the test tool *does not touch the logging module at all*, and it has no way to mandate the usage of the logging module like you suggest. -- ___ Python tracker <http://bugs.python.org/issue6333> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6333] logging: ValueError: I/O operation on closed file
holger krekel added the comment: Actually py.test catches stdout separately for setup and for the test code. Moreover, functional or integration test code (py.test is not only for unittests) can easily trigger some implicit logging-module usage which cannot eaysily be factored into a testcase-setup method, i am afraid. -- ___ Python tracker <http://bugs.python.org/issue6333> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8720] undo findsource regression/change
New submission from holger krekel : Somewhere between python 3.0.1 and 3.1.2 the behaviour of inspect.findsource changed: it does not find the source code anymore for a code object whose filename/source is in the linecache.cache because instead of the previous:: file = getsourcefile(object) or getfile(object) it only does now:: file = getsourcefile(object) IMO it is enough if findsource() raises if it can't eventually discover the source code - i don't see the need to do this ahead. In any case, the r312 findsource version requires an ugly work around within py.test in order for it to continue to be able to use the inspect module with dynamically compiled code. The underlying issue is that at code-compile time no sensible (PEP302 compliantly loaded) module can be constructed because this is only known at exec-time but this is not part of the test tool API and is done somewhere in user code. Proposed fix: revert to r301 behaviour and add back "or getfile(object)" to the first line of inspect.findsource() -- components: Library (Lib) messages: 105776 nosy: benjamin.peterson, hpk priority: normal severity: normal status: open title: undo findsource regression/change type: behavior versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue8720> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8720] undo findsource regression/change
holger krekel added the comment: Thanks for helping with this! Attached is a patch that adds a keyword "check=True" to getsourcefile so that findsource can defer existence-checking until after cache lookup. Eventually, findsource will still raise an IOError if it can't find the source file and cannot recover the source from cache. The patch mainly consists of adding a number of tests to specify the (refined) behaviour of findsource and getsourcefile. best, holger -- keywords: +patch Added file: http://bugs.python.org/file17350/findsource.patch ___ Python tracker <http://bugs.python.org/issue8720> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8720] undo findsource regression/change
holger krekel added the comment: David, your getsourcefile.patch looks fine (and better than mine) to me. -- ___ Python tracker <http://bugs.python.org/issue8720> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8720] undo findsource regression/change
holger krekel added the comment: Well, maybe we could introduce a "linecache.setlines" function to give the linecache module control over its internal caching and data handling. What do you think? -- ___ Python tracker <http://bugs.python.org/issue8720> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8782] inspect.getsource returns invalid source for non-newline-ending module
New submission from holger krekel : Executing the attached "inspect_failure.py" under python2.6 or python3.1 results in an assertion error: Python fails to obtain the source code of a function that is defined at the end of a module whose last line does not contain a line ending character. After brief analysis i think there are two approaches to fixing it: normalizing newlines in inspect.findsource (see attached inspect.patch file against r312) or performing normalization in linecache.updatecache which does it already for source code obtained from PEP302 loaders. Or any other ideas? -- files: inspect.patch keywords: patch messages: 106245 nosy: hpk priority: normal severity: normal status: open title: inspect.getsource returns invalid source for non-newline-ending module type: behavior versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file17431/inspect.patch ___ Python tracker <http://bugs.python.org/issue8782> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8782] inspect.getsource returns invalid source for non-newline-ending module
holger krekel added the comment: Great. Also to be backported to 2.x? holger On Fri, May 21, 2010 at 11:32 PM, Benjamin Peterson wrote: > > Benjamin Peterson added the comment: > > Fixed in r81432 by making linecache smarter. > > -- > nosy: +benjamin.peterson > resolution: -> fixed > status: open -> closed > > ___ > Python tracker > <http://bugs.python.org/issue8782> > ___ > -- ___ Python tracker <http://bugs.python.org/issue8782> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8720] undo findsource regression/change
holger krekel added the comment: Seems the inspect.getsourcefile regression now is in the RC1 of Python2.7 as well. I suggest to apply the "getsourcefile.patch" patch which was attached from David. I tested it and it works fine for Python2.7 and Python3.1. -- status: open -> pending versions: +Python 2.7, Python 3.3 ___ Python tracker <http://bugs.python.org/issue8720> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
