[issue35813] shared memory construct to avoid need for serialization between processes
Pam McA'Nulty added the comment: Reviewing docs and am writing a queue implementation for usability testing. I think ShareableList needs to support `close()` and `unlink()` directly. The `.shm` attribute should be considered an _implementation_ detail, and not be exposed. -- nosy: +Pam.McANulty ___ Python tracker <https://bugs.python.org/issue35813> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36815] Test Failure MacOS : test_socket test_host_resolution_bad_address
Change by Pam McA'Nulty : -- title: test_socket test_host_resolution_bad_address test failure -> Test Failure MacOS : test_socket test_host_resolution_bad_address ___ Python tracker <https://bugs.python.org/issue36815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36815] test_socket test_host_resolution_bad_address test failure
New submission from Pam McA'Nulty : - Cloned a new cpython onto my new MacOS system (Mojave 10.14.4) - built as per https://devguide.python.org/ - test failure: ``` ./python.exe -m test -j3 test_socket Run tests in parallel using 3 child processes 0:00:24 load avg: 0.88 [1/1/1] test_socket failed /Users/pamelamcanulty/cpython/Lib/test/test_socket.py:2424: RuntimeWarning: received malformed or improperly-truncated ancillary data result = sock.recvmsg(bufsize, *args) /Users/pamelamcanulty/cpython/Lib/test/test_socket.py:2515: RuntimeWarning: received malformed or improperly-truncated ancillary data result = sock.recvmsg_into([buf], *args) test test_socket failed -- Traceback (most recent call last): File "/Users/pamelamcanulty/cpython/Lib/test/test_socket.py", line 936, in test_host_resolution_bad_address socket.gethostbyname(addr) AssertionError: OSError not raised : ::1q == Tests result: FAILURE == 1 test failed: test_socket Total duration: 24 sec 153 ms Tests result: FAILURE ``` -- components: macOS messages: 341542 nosy: Pam.McANulty, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: test_socket test_host_resolution_bad_address test failure type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5710] ctypes should return composite types from callbacks
Pam McA'Nulty <pam...@mcanulty.org> added the comment: oops - "In the example code, the 'result' variable is declared on the stack in the callback() function. So it will be effectively when callback() returns." should be "In the example code, the 'result' variable is declared on the stack in the callback() function. So it will be effectively DESTROYED when callback() returns." I hate waking up at 4:15a. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue5710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5710] ctypes should return composite types from callbacks
Pam McA'Nulty <pam...@mcanulty.org> added the comment:
In the example code, the 'result' variable is declared on the stack in the
callback() function. So it will be effectively when callback() returns.
Also the "result" variable in main() is never referenced. A pointer main()'s
"result" variable should be passed to callback() as an argument ("") and
`callback(struct helloStruct *result)` should populate it (via `result->i =
10;` etc)
```struct helloStruct callback () {
struct helloStruct result;
result.i = 10;
result.f = 3.14159;
return result;
}```
--
nosy: +Pam.McANulty
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue5710>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29057] Compiler failure on Mac OS X - sys/random.h
Pam McA'Nulty added the comment: I can conform that Chi Hsuan Yen's patch works for me. I'm concerned that the build includes sys/random.h despite it not actually being needed to build python on mac os x (my worry is possible "shenanigans" by Apple in future versions of their headers) But if this patch makes sense to those who actually speak "./configure", I'm agnostic enough. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29057> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29057] Compiler failure on Mac OS X - sys/random.h
Pam McA'Nulty added the comment: I've dug into things some more. In my mac environment, sys/random.h is pretty empty and doesn't actually seem to provide anything that Python/random.c uses. The compile error is a type error is because 'u_int' never gets typedef'd in the rest of the compile includes. I think the bottom line is that sys/random.h on mac os is neither useful, nor required. Below is the error again and I've attached my sys/random.h ``` In file included from Python/random.c:16: /usr/include/sys/random.h:37:32: error: unknown type name 'u_int' void read_random(void* buffer, u_int numBytes); ^ /usr/include/sys/random.h:38:33: error: unknown type name 'u_int' void read_frandom(void* buffer, u_int numBytes); ^ /usr/include/sys/random.h:39:33: error: unknown type name 'u_int' int write_random(void* buffer, u_int numBytes); ``` -- Added file: http://bugs.python.org/file46108/random.h ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29057> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29057] Compiler failure on Mac OS X - sys/random.h
Pam McA'Nulty added the comment: New patch to make consistent wrt use of "defined()" -- Added file: http://bugs.python.org/file46024/Issue29057_random_include-v2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29057> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29057] Compiler failure on Mac OS X - sys/random.h
Pam McA'Nulty added the comment: Good question. It looks like there are 3 defines getting checked: HAVE_SYS_RANDOM_H and either HAVE_GETRANDOM or HAVE_GETENTROPY The previous issue seemed to be that you could have HAVE_GETRANDOM and/or HAVE_GETENTROPY be set, but still not have a sys/random.h, so a check was added for HAVE_SYS_RANDOM_H. However, on macs, you can HAVE_SYS_RANDOM_H, but still not have either HAVE_GETRANDOM or HAVE_GETENTROPY. This _probably_ implies that the sys/random.h that's present isn't conformant enough for the compiler settings and my mac's os and/or xcode. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29057> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29057] Compiler failure on Mac OS X - sys/random.h
Pam McA'Nulty added the comment: I will say that, though my fix seems to work, it feels that the "right" place to put the fix is in ./configure. Sadly, I don't speak './configure', though I apparently remember enough C from 17 years ago to get this working. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29057> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14483] inspect.getsource fails to read a file of only comments
Pam McA'Nulty added the comment: Yeah, I looked at the code and saw what you described, David. I think I'll see if there's a good place to mention this constraint in the docs and then I'll find another one (besides the macOS build issue I ran into when trying to build the latest master) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14483] inspect.getsource fails to read a file of only comments
Pam McA'Nulty added the comment: I just clicked "Random Issue" and it seemed to be an "easy" (ish) one - which is just what I'd like to tackle over xmas break :) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29057] Compiler failure on Mac OS X - sys/random.h
Pam McA'Nulty added the comment: OSX: 10.11.6 (15G1212) Xcode 8.2.1 Build version 8C1002 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29057> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29057] Compiler failure on Mac OS X - sys/random.h
Pam McA'Nulty added the comment: Patch for fix -- keywords: +patch Added file: http://bugs.python.org/file46009/Issue29057_random_include.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29057> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29057] Compiler failure on Mac OS X - sys/random.h
New submission from Pam McA'Nulty: make failed on Mac OS X including sys/random.h It looks to be caused by this commit: https://github.com/python/cpython/commit/1958527a2c5dda766b1917ab563622434b3dad0d Restoring the removed ifdefs solves the problem (see github PR) Official patch to follow Failure message. ``` In file included from Python/random.c:16: /usr/include/sys/random.h:37:32: error: unknown type name 'u_int' void read_random(void* buffer, u_int numBytes); ^ /usr/include/sys/random.h:38:33: error: unknown type name 'u_int' void read_frandom(void* buffer, u_int numBytes); ^ /usr/include/sys/random.h:39:33: error: unknown type name 'u_int' int write_random(void* buffer, u_int numBytes); ^ 3 errors generated. make: *** [Python/random.o] Error 1 ``` -- components: Build messages: 283889 nosy: Pam.McANulty priority: normal pull_requests: 6 severity: normal status: open title: Compiler failure on Mac OS X - sys/random.h type: compile error versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29057> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14483] inspect.getsource fails to read a file of only comments
Changes by Pam McA'Nulty <pam...@mcanulty.org>: -- nosy: +Pam.McANulty ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27395] Patch to Increase test coverage of unittest.runner.TextTestResult
Changes by Pam McA'Nulty <pam...@mcanulty.org>: -- title: Increase test coverage of unittest.runner.TextTestResult -> Patch to Increase test coverage of unittest.runner.TextTestResult ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27395> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27395] Increase test coverage of unittest.runner.TextTestResult
New submission from Pam McA'Nulty: While working on another issue, I added a test to increase (low-hanging fruit) test coverage in unittest.runner.TextTestResult -- components: Tests files: textresult_coverage.patch keywords: patch messages: 269330 nosy: Pam.McANulty priority: normal severity: normal status: open title: Increase test coverage of unittest.runner.TextTestResult versions: Python 3.6 Added file: http://bugs.python.org/file43551/textresult_coverage.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27395> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26859] unittest fails with "Start directory is not importable" when trying to run sourceless tests
Changes by Pam McA'Nulty <pam...@mcanulty.org>: -- nosy: +Pam.McANulty ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26859> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27152] Additional assert methods for unittest
Changes by Pam McA'Nulty <pam...@mcanulty.org>: -- nosy: +Pam.McANulty ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27152> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27198] Adding an assertClose() method to unittest.TestCase
Changes by Pam McA'Nulty <pam...@mcanulty.org>: -- nosy: +Pam.McANulty ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27198> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22812] Documentation of unittest -p usage wrong on windows.
Pam McA'Nulty added the comment: Here's a version of the docs with double quotes -- Added file: http://bugs.python.org/file39033/cpython-22812-discovery-double-quotes-v3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22812 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22812] Documentation of unittest -p usage wrong on windows.
Pam McA'Nulty added the comment: Thanks, Zach for both the comments and the mention of the email bounce. I changed jobs and didn't have this site listed in my must update email address list (fixed now) Should I re-update the doc patch and put in double quotes? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22812 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22812] Documentation of unittest -p usage wrong on windows.
Pam McA'Nulty added the comment: This version of the patch just updates the docs. Since the quotes aren't really necessary for the example to work, the patch removes the single quotes from the example. I don't think that the python unittest documentation should explain/document the various command-line quoting rules, so let's not add un-necessary confusion. -- Added file: http://bugs.python.org/file39025/cpython-22812-discovery-quotes-v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22812 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22812] Documentation of unittest -p usage wrong on windows.
Pam McA'Nulty added the comment: Remove quotes from quoted patterns only on windows systems (since if the quotes get parsed into the pattern field on a non-windows system, one should respect the user's command line efforts). Test uses unittest.mock.patch to test windows path. -- keywords: +patch nosy: +Pam.McANulty Added file: http://bugs.python.org/file38939/cpython-22812-discovery-quotes-v1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22812 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10612] StopTestRun exception to halt test run
Pam McA'Nulty added the comment: This version fixes a few things after using review. I still have some open questions: o Where in unittest.rst should the StopTestRun documentation actually live? I've put it right after the SkipTest exception. That doesn't feel perfect, but I didn't see a place where it would fit any better. o What should the flag structure be? I've implemented it with two flags on the Outcome object which lead to an optional flag on the result object. It works, but it's a bit messy o What word should haltTestRun really be? I've chosen the word halt to represent the halt-reporting flag. I think my firmware background is showing. Any suggestions for a better term? -- Added file: http://bugs.python.org/file38931/cpython-10612-StopTestRun-v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10612 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10612] StopTestRun exception to halt test run
Changes by Pam McA'Nulty pam...@webreply.com: -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10612 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10612] StopTestRun exception to halt test run
Changes by Pam McA'Nulty pam...@webreply.com: -- nosy: +kushal.das ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10612 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10612] StopTestRun exception to halt test run
Pam McA'Nulty added the comment: Added unittest.StopTestRun exception. It's caught and handled in testPartExecutor() - which is the same place SkipTest is caught. If report=False, then it sets the result.haltTestRun attribute, which is a signal to TestTextRunner to not generate any output. Added notes to whatsnew and unittest docs -- keywords: +patch Added file: http://bugs.python.org/file38925/cpython-10612-StopTestRun.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10612 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10612] StopTestRun exception to halt test run
Changes by Pam McA'Nulty pam...@webreply.com: -- nosy: +Pam.McANulty ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10612 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17530] pprint could use line continuation for long bytes literals
Pam McA'Nulty added the comment: Here's a new version. It looks more like the str_parts patch and uses parentheses instead of continuation as suggested. Sample output: pprint.pprint(b\n\na\x00, width=1) (b'\n' b'\n' b'a' b'\x00') -- Added file: http://bugs.python.org/file29915/bytes_pprint2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17530 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17530] pprint could use line continuation for long bytes literals
Pam McA'Nulty added the comment: Here's a patch. I needed to handle the fact that the repr of a single byte can be 1, 2 or 4 characters long and did not want to wrap in the middle of a byte representation. Note also that bytes literals require a continuation character. In the pathological case where the wrap size is smaller than the representation of a single byte, I chose to always print at least one byte per line. As an aside, I also replaced the str wrapping code's calls to len with the cached _len used in the rest of pprint.py -- keywords: +patch nosy: +Pam.McANulty Added file: http://bugs.python.org/file29865/bytes_pprint.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17530 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17530] pprint could use line continuation for long bytes literals
Pam McA'Nulty added the comment:
oops, forgot to add some samples:
pprint.pprint(b\n\n\n\n\n\n, width=5)
b'\n'\
b'\n'\
b'\n'\
b'\n'\
b'\n'\
b'\n'
pprint.pprint({a: b\x00\xff * 20})
{'a': b'\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00'\
b'\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff'\
b'\x00\xff\x00\xff\x00\xff'}
pprint.pprint({a: b\x00\xff * 20}, width=20)
{'a': b'\x00\xff'\
b'\x00\xff'\
b'\x00\xff'\
b'\x00\xff'\
b'\x00\xff'\
b'\x00\xff'\
b'\x00\xff'\
b'\x00\xff'\
b'\x00\xff'\
b'\x00\xff'\
b'\x00\xff'\
b'\x00\xff'\
b'\x00\xff'\
b'\x00\xff'\
b'\x00\xff'\
b'\x00\xff'\
b'\x00\xff'\
b'\x00\xff'\
b'\x00\xff'\
b'\x00\xff'}
pprint.pprint(b'a\x00\n\\x00', width=20)
b'a\x00\n\\x00'
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17530
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17530] pprint could use line continuation for long bytes literals
Pam McA'Nulty added the comment: - eval expects bytes to have a continuation character and test_str_wrap did an eval check so I figured test_bytes_wrap should as well: # repr some bytes: b = b\x00\xff * 5 b b'\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff' r = repr(b) r b'\\x00\\xff\\x00\\xff\\x00\\xff\\x00\\xff\\x00\\xff' eval(r) b'\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff' # hand-wrap it without the continuation character and it fails to eval (stuck the s = b'\\x00\\xff\\x00\\xff\\x00'\nb'\\xff\\x00\\xff\\x00\\xff' print(s) b'\x00\xff\x00\xff\x00' b'\xff\x00\xff\x00\xff' eval(s) Traceback (most recent call last): File stdin, line 1, in module File string, line 2 b'\xff\x00\xff\x00\xff' ^ SyntaxError: invalid syntax # stick the continuation character in, and it evals properly s = s.replace(\n, \\\n) print(s) b'\x00\xff\x00\xff\x00'\ b'\xff\x00\xff\x00\xff' eval(s) b'\x00\xff\x00\xff\x00\xff\x00\xff\x00\xff' - I agree about the len v _len, but figured this wasn't all that foolish a consistency issue (i.e. the rest of pprint.py used _len) - I also wanted to refactor _str_parts and _bytes_parts, but couldn't decide on the best course. I was favoring a helper function to run the common loop since the two if issubclass... calls were so different and parameterizing the differences felt like it would obfuscate things too much. - I also agree on the doc. I figured I'd see if there weren't any hidden surprises with the patch before I worked on better doc. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17530 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
