[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
New submission from Vitaly: Python 2.6.7 on Mac OS 10.7.4 running on MacBookPro laptop. run attachment as: python test_pipe_error.py The test() function makes multiple calls to _execute_child() in a loop. Every other call to _execute_child() fails with: = os.read(3, 1048576) self pid: 43953 EINVAL FROM TEST: Traceback (most recent call last): File "test_pipe_error.py", line 127, in test _execute_child() File "test_pipe_error.py", line 95, in _execute_child newData = os.read(errpipe_read, rSize) OSError: [Errno 22] Invalid argument = _execute_child() is based on subprocess.Popen._execute_child, but with most Popen code removed and errpipe_read configured as os.O_NONBLOCK in the parent process. Raising of an Exception() instance is used to simulate failure in os.execvp() instead of calling os.execvp(). We initially experienced the EINVAL issue in the parent process' os.read call when os.execvp failed in the child (e.g., errno=2, "file not found"), so I stripped the code to bare minimum in order to reproduce the problem with a smaller code snippet. -- components: Library (Lib) files: test_pipe_error.py messages: 170144 nosy: vitaly priority: normal severity: normal status: open title: Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS type: crash versions: Python 2.6 Added file: http://bugs.python.org/file27160/test_pipe_error.py ___ Python tracker <http://bugs.python.org/issue15896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
Vitaly added the comment: Per Charles-François Natali (neologix), I tried the following: 1. Reduce the initial read size argument (rSize in my code snippet) from 1048576 (1MB, the same amount as used by subprocess.Popen._executeChild) to 100: the problem appears to go away (could be just red herring, though); this actually makes me think that it's a Python implementation problem on MacOS - why should an initial read request with 1048576 read size trigger EINVAL every other time (1,3,5,9, etc.), but using the initial size of 100 doesn't? 2. "put a short sleep before exiting the child process (after pickling the exception) to see what happens if the reader reads before the pipe is closed by the other end" -- I took that to mean a delay after the "os.write(errpipe_write, pickle.dumps(exc_value))" call in my snippet: I tried 1, 2, and 4-second delays (via time.sleep()). One time, I saw the Invalid Argument in only one of the 9 iterations, but in all the other runs Invalid Argument showed up as before on iterations: 1, 3, 5, 7, 9 3. put the delay (tried with 1 and 2 seconds) before "os.write(errpipe_write, pickle.dumps(exc_value))": Invalid Argument showed up as before on iterations: 1, 3, 5, 7, 9 -- ___ Python tracker <http://bugs.python.org/issue15896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
Changes by Vitaly : Added file: http://bugs.python.org/file27170/test_fork_pipe_error.py ___ Python tracker <http://bugs.python.org/issue15896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
Vitaly added the comment: os.read() must also be allocating the read buffer in addition to calling the system read() function. I just uploaded a new test script "test_fork_pipe_error.py" that iterates in increasing or decreasing order over initial pipe read sizes and accumulates failed size values. It iterates in multiples of 1024 (1024*1, 1024*2, 1024*3, ... 1024*1024 or in reverse) . It makes some interesting (possibly also red-herring) discoveries: 1. When iterating the initial read size in increasing order (1024, 2048, 3072, ...) the test doesn't trigger the EINVAL error. 2. When iterating the initial read size in decreasing order, the test triggers EINVAL every 4KB (1024*1024, 1024*1020, 1024*1016, etc.) all the way down to 1024*128. However, the test doesn't trigger any more EINVAL errors for initial read sizes of 127KB and lower (1024*127, 1024*126, 1024*125, ... 1024*1). Failed initialReadSize multipliers of 1024: [1024, 1020, 1016, 1012, 1008, 1004, 1000, 996, 992, 988, 984, 980, 976, 972, 968, 964, 960, 956, 952, 948, 944, 940, 936, 932, 928, 924, 920, 916, 912, 908, 904, 900, 896, 892, 888, 884, 880, 876, 872, 868, 864, 860, 856, 852, 848, 844, 840, 836, 832, 828, 824, 820, 816, 812, 808, 804, 800, 796, 792, 788, 784, 780, 776, 772, 768, 764, 760, 756, 752, 748, 744, 740, 736, 732, 728, 724, 720, 716, 712, 708, 704, 700, 696, 692, 688, 684, 680, 676, 672, 668, 664, 660, 656, 652, 648, 644, 640, 636, 632, 628, 624, 620, 616, 612, 608, 604, 600, 596, 592, 588, 584, 580, 576, 572, 568, 564, 560, 556, 552, 548, 544, 540, 536, 532, 528, 524, 520, 516, 512, 508, 504, 500, 496, 492, 488, 484, 480, 476, 472, 468, 464, 460, 456, 452, 448, 444, 440, 436, 432, 428, 424, 420, 416, 412, 408, 404, 400, 396, 392, 388, 384, 380, 376, 372, 368, 364, 360, 356, 352, 348, 344, 340, 336, 332, 328, 324, 320, 316, 312, 308, 304, 300, 296, 292, 288, 284, 280, 276, 272, 2 68, 264, 260, 256, 252, 248, 244, 240, 236, 232, 228, 224, 220, 216, 212, 208, 204, 200, 196, 192, 188, 184, 180, 176, 172, 168, 164, 160, 156, 152, 148, 144, 140, 136, 132, 128] The reason I said above that those might be red-herring discoveries is this: if I insert a short time.sleep(0.001) delay before the outer pipe-read loop, the EINVAL errors don't get triggered either. Still, these remain a mystery: 1. Why doesn't the test encounter EINVAL in the range 127KB ... 1KB (when iterating initialReadSize in *decreasing* order). If the pre-read delay is significant, then does it take significantly more time to allocate a 127KB chunk of memory than it does a 128KB chunk? 2. Why doesn't the test encounter EINVAL at all when iterating initialReadSize in *increasing* order? -- ___ Python tracker <http://bugs.python.org/issue15896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
Vitaly added the comment: I wrote a C-language program to reproduce this issue on Mac OS without Python. It reproduces the issue in both increasing and decreasing order of initial read sizes, and it reliably reproduces it for each KB from 128KB to 1024KB ; the Python version reproduced the issue every 4K and only in decreasing order (probably something related to Python's memory management optimizations). A new caveat: if the read buffer is allocated once before entering the read loop, then we don't get any EINVAL in the entire run; however, if the read buffer is allocated for each read request inside the loop, then we get EINVAL every other time in the range from 128KB and up. I would like to file this issue with apple/Mac OS. What's the appropriate URL for this? -- Added file: http://bugs.python.org/file27172/test_fork_pipe_error.cpp ___ Python tracker <http://bugs.python.org/issue15896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
Vitaly added the comment: The C-language program for reproducing the same issue is attached as test_fork_pipe_error.cpp -- ___ Python tracker <http://bugs.python.org/issue15896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
Vitaly added the comment: I used g++ to compile test_fork_pipe_error.cpp on both Mac OS and on Linux. EINVAL showed up only on Mac OS. -- ___ Python tracker <http://bugs.python.org/issue15896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
Vitaly added the comment: By the way, the existing code in subprocess.Popen (at least on 2.6.7) reads the pipe incorrectly: It doesn't loop to read all the data until EOF -- it only loops over EINTR until it gets a single successful os.read() call. However, since this is a pipe read (not a real file read), the system doesn't guarantee that the blocking read will read everything up to requested read size or EOF, whichever comes first. So, the single os.read call could return a partial read, and the subsequent un-pickling of the exception would fail. -- ___ Python tracker <http://bugs.python.org/issue15896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
Vitaly added the comment: I filed this issue with apple: Problem ID: 12274650: https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa/64/wo/VE1RGG9qEL5OS9KdzFSDHw/19.66 -- ___ Python tracker <http://bugs.python.org/issue15896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
Vitaly added the comment: Apple bug report URL correction: https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa/64/wo/VE1RGG9qEL5OS9KdzFSDHw/17.66 -- ___ Python tracker <http://bugs.python.org/issue15896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
Vitaly added the comment: Sorry, I don't know why the URL comes out all messed up. I can't seem to find the correct syntax for this. -- ___ Python tracker <http://bugs.python.org/issue15896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15918] subprocess.Popen reads errpipe_read incorrectly, can result in short read
New submission from Vitaly: subprocess.Popen (at least on 2.6.7) reads the pipe incorrectly: It doesn't loop to read all the data until EOF -- it only loops over EINTR until it gets a single successful os.read() call. However, since this is a pipe read (not a real file read), the system doesn't guarantee that the blocking read will read everything up to requested read size or EOF, whichever comes first. So, the single os.read call could return a partial read, and the subsequent un-pickling of the exception would fail/crash. Sorry, I can't submit a patch as I am merely a Python user, not a Python developer, and it would take me too long to set up and figure out Python build just for this one issue. -- components: Library (Lib) messages: 170279 nosy: vitaly priority: normal severity: normal status: open title: subprocess.Popen reads errpipe_read incorrectly, can result in short read type: crash versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue15918> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
Vitaly added the comment: Filed http://bugs.python.org/issue15918 for the incorrect pipe read logic in subprocess.Popen. -- ___ Python tracker <http://bugs.python.org/issue15896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
Vitaly added the comment: > What's wrong with working around this bug by reading a smaller amount? How > much data is there supposed to be? This makes sense for working around the issue. Even in the blocking-read case, such as in subprocess.Popen, attempting to read a 1MB chunk of data in a single os.read call is unhelpful anyway - see http://bugs.python.org/issue15918. Also, the 1MB read forces os.read() to unnecessarily allocate a huge !MB buffer (even if only for a short lifetime) -- ___ Python tracker <http://bugs.python.org/issue15896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15918] subprocess.Popen reads errpipe_read incorrectly, can result in short read
Vitaly added the comment: Also, attempting to read a 1MB chunk of data in a single os.read call forces os.read() to unnecessarily allocate a huge !MB buffer (even if only for a short lifetime). Using something like 4KB read calls in a loop is more practical (and looping is necessary anyway). -- ___ Python tracker <http://bugs.python.org/issue15918> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
Changes by Vitaly : -- versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue15896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15918] subprocess.Popen reads errpipe_read incorrectly, can result in short read
Vitaly added the comment: My bug report refers to the following code block in subprocess.py. The problem is the same in 2.6.7 and 2.7.3: === From subprocess.py in Python 2.7.3 Source Distribution: # Wait for exec to fail or succeed; possibly raising exception # Exception limited to 1M data = _eintr_retry_call(os.read, errpipe_read, 1048576) finally: # be sure the FD is closed no matter what os.close(errpipe_read) === However, Python 3.2.3 appears to be doing this correctly; it loops, gathers the data from multiple os.read calls, and doesn't make huge (1048576) os.read requests: === from subprocess.py in 3.2.3 source distribution # Wait for exec to fail or succeed; possibly raising an # exception (limited in size) data = bytearray() while True: part = _eintr_retry_call(os.read, errpipe_read, 5) data += part if not part or len(data) > 5: break === -- versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue15918> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15918] subprocess.Popen reads errpipe_read incorrectly, can result in short read
Vitaly added the comment: Sorry, there is no traceback. The issue was identified in code review. 'man 2 read' states: === The system guaran- tees to read the number of bytes requested if the descriptor references a normal file that has that many bytes left before the end-of-file, but in no other case. === Since a pipe is not a "normal file", the guarantee to "read the number of bytes requested" does not apply. -- ___ Python tracker <http://bugs.python.org/issue15918> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15918] subprocess.Popen reads errpipe_read incorrectly, can result in short read
Vitaly added the comment: The prior 'man 2 read' quote was from Mac OS X; On amazon (centos) Linux, 'man 2 read' makes the same claim, albeit in different verbiage: === It is not an error if this number is smaller than the number of bytes requested; this may happen for example because fewer bytes are actually available right now (maybe because we were close to end-of-file, or because we are reading from a pipe, or from a terminal), or because read() was interrupted by a signal. === -- ___ Python tracker <http://bugs.python.org/issue15918> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15918] subprocess.Popen reads errpipe_read incorrectly, can result in short read
Vitaly added the comment: > In practice I doubt this matters much as this error string is likely to be > less than one page (depends on pathnames involved) but it is still technically incorrect as written. Agreed. Thank you. -- ___ Python tracker <http://bugs.python.org/issue15918> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
Vitaly added the comment: In the work-around, we need to watch out for what 'man 2 read' on Mac OS refers to as "normal file": == Upon successful completion, read(), readv(), and pread() return the number of bytes actually read and placed in the buffer. *The system guarantees to read the number of bytes requested if the descriptor references a normal file that has that many bytes left before the end-of-file*, but in no other case. == I am guessing that fstat() + S_ISREG() can be used to discern "normal files" from other types of file descriptors. -- ___ Python tracker <http://bugs.python.org/issue15896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
Vitaly added the comment: > Nothing, except that there are probably other places in the stdlib > where we can get bitten by this bug. Note that this should eventually > be done for another reason, see http://bugs.python.org/issue15918 For greatest benefit, I think that the work-around should be implemented in os.read() -- ___ Python tracker <http://bugs.python.org/issue15896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
Vitaly added the comment: > The workaround should not be implemented in os.read because it is a very thin > wrapper around the system call and should stay that way. Although this issue was initially filed as "Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS", the subsequent investigation revealed that this has nothing to do with a forked child failing. Rather, it's a bug in the read() syscall on Mac OS X. What would be a more appropriate place to work around this read() syscall bug than os.read? -- ___ Python tracker <http://bugs.python.org/issue15896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
Vitaly added the comment: > And what kind of workaround do you propose? [os.read(fd, buffersize)] I am thinking about these options: Option 1: Fix breakages as they are discovered at higher level (above os.read) as needed in places where usage semantics are known, and address the issue via errata documentation (i.e., "On Mac OS X, don't make individual pipe read requests that would result in os.read() buffersize arg being above 127KB on non-blocking pipes."); should also check if the same issue occurs with sockets (e.g., socket.socketpair() instead of os.pipe()) to make the errata more complete. This may be perfectly acceptable and how things have worked for a long time. Option 2: Implement a work-around in the lowest common denominator wrapper function, so that anything in Python that needs to call read() and could benefit from this work-around, would call that wrapper instead of read(). The read() work-around might go something like this in *pseudocode*: if running_on_darwin and buffersize > 127KB: # fix up buffer size to work around a Mac OS x bug... if stat.S_ISFIFO(os.fstat(fd).st_mode): buffersize = 127KB Then do whatever else the read function is supposed to do. -- ___ Python tracker <http://bugs.python.org/issue15896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
Vitaly added the comment: > It's not Python's job to workaround stupid platform bugs... > So I'd suggest closing this, and urge people to complain to the OS-X folks After digesting the postings, I've come around to this point of view as well, so closing as "rejected". And, as mentioned earlier, I filed the issue on https://bugreport.apple.com as Problem ID: 12274650. -- resolution: -> rejected ___ Python tracker <http://bugs.python.org/issue15896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
Changes by Vitaly : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue15896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16168] SysLogHandler constructor ignores socktype arg when address refers to a Unix Domain Socket
New submission from Vitaly: _connect_unixsocket() (see below) does not use socktype value that was passed into SysLogHandler.__init__(): def _connect_unixsocket(self, address): self.socket = socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM) # syslog may require either DGRAM or STREAM sockets try: self.socket.connect(address) except socket.error: self.socket.close() self.socket = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) self.socket.connect(address) -- components: Library (Lib) messages: 172418 nosy: vitaly priority: normal severity: normal status: open title: SysLogHandler constructor ignores socktype arg when address refers to a Unix Domain Socket versions: Python 2.7, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue16168> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16168] SysLogHandler constructor ignores socktype arg when address refers to a Unix Domain Socket
Vitaly added the comment: SOCK_DGRAM causes log messages larger than about 2000 bytes to be dropped altogether on MacOS X 10.7.5 and to be truncated to 2081 bytes on Linux (tested with Amazon's linux, which is based on centos). This is quite unfortunate, since many exception tracebacks for production apps are larger than 2000 bytes, and it's paramount to capture the entire traceback in order to debug the issue. This limitation can be overcome if _connect_unixsocket() used the socktype arg value that was passed to SysLogHandler constructor. -- ___ Python tracker <http://bugs.python.org/issue16168> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1731717] race condition in subprocess module
Vitaly added the comment: Is this issue fixed in python 2.7.10? I am experiencing strange race conditions in code that combines threads with multiprocessing pool, whereby a thread is spawned by each pool worker. Running on latest Mac OS X. -- nosy: +vitaly ___ Python tracker <http://bugs.python.org/issue1731717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27060] Documentation of assertItemsEqual in unittest is VERY misleading in 2.7
New submission from Vitaly: Python 2.7 documentation is VERY misleading about the functionality of assertItemsEqual. The implementation only compares item counts, but the documentation actually claims to compare not only the counts, but the actual sorted elements themselves. This documentation mislead my group to use this method for comparing the elements. See https://hg.python.org/cpython/file/d9921cb6e3cd/Doc/library/unittest.rst, which is what appears on https://docs.python.org/2.7/library/unittest.html#unittest.TestCase.assertItemsEqual: .. method:: assertItemsEqual(actual, expected, msg=None) Test that sequence *expected* contains the same elements as *actual*, regardless of their order. When they don't, an error message listing the differences between the sequences will be generated. Duplicate elements are *not* ignored when comparing *actual* and *expected*. It verifies if each element has the same count in both sequences. It is the equivalent of ``assertEqual(sorted(expected), sorted(actual))`` but it works with sequences of unhashable objects as well. -- messages: 265889 nosy: vitaly priority: normal severity: normal status: open title: Documentation of assertItemsEqual in unittest is VERY misleading in 2.7 ___ Python tracker <http://bugs.python.org/issue27060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27060] Documentation of assertItemsEqual in unittest is VERY misleading in 2.7
Changes by Vitaly : -- versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue27060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27060] Documentation of assertItemsEqual in unittest is VERY misleading in 2.7
Changes by Vitaly : -- assignee: -> docs@python components: +Documentation nosy: +docs@python ___ Python tracker <http://bugs.python.org/issue27060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17866] TestCase.assertItemsEqual exists in 2.7, not in 3.3
Vitaly added the comment: Python 2.7 documentation is VERY misleading about the functionality of assertItemsEqual. It actually claims to compare not only the counts, but the actual sorted elements themselves. This documentation mislead my group to use this method for comparing the elements. See https://hg.python.org/cpython/file/d9921cb6e3cd/Doc/library/unittest.rst: .. method:: assertItemsEqual(actual, expected, msg=None) Test that sequence *expected* contains the same elements as *actual*, regardless of their order. When they don't, an error message listing the differences between the sequences will be generated. Duplicate elements are *not* ignored when comparing *actual* and *expected*. It verifies if each element has the same count in both sequences. It is the equivalent of ``assertEqual(sorted(expected), sorted(actual))`` but it works with sequences of unhashable objects as well. -- nosy: +vitaly ___ Python tracker <http://bugs.python.org/issue17866> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17866] TestCase.assertItemsEqual exists in 2.7, not in 3.3
Vitaly added the comment: I opened http://bugs.python.org/issue27060 regarding the erroneous documentation of assertItemsEqual in python 2.7. -- ___ Python tracker <http://bugs.python.org/issue17866> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27060] Documentation of assertItemsEqual in unittest is VERY misleading in 2.7
Vitaly added the comment: According to comment http://bugs.python.org/issue17866#msg188052 in #17866, the maintainers renamed `assertItemsEqual` to `assertCountEqual` somewhere in the 3.x development timeframe. They apparently latched on to the implementation of `assertItemsEqual` in 2.7.x, which compares counts only, rather than its documentation. -- ___ Python tracker <http://bugs.python.org/issue27060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27060] Documentation of assertItemsEqual in unittest is VERY misleading in 2.7
Vitaly added the comment: Thanks Terry, your assessment is correct. The maintainers appear to have drawn the wrong conclusion in #17866, which mislead me about the existing assertItemsEqual in 2.7, which appears to work correctly after all! import unittest as u class Test(u.TestCase): def test_equal_count_of_same_elements(self): self.assertItemsEqual([1,2,3], [1,2,3]) def test_equal_count_of_different_elements(self): self.assertItemsEqual([1,2,3], [1,2,4]) def test_different_count(self): self.assertItemsEqual([1,2,3], [1,2,3,4]) u.main() $ python assert_items_equal_test.py --verbose test_different_count (__main__.Test) ... FAIL test_equal_count_of_different_elements (__main__.Test) ... FAIL test_equal_count_of_same_elements (__main__.Test) ... ok == FAIL: test_different_count (__main__.Test) -- Traceback (most recent call last): File "assert_items_equal_test.py", line 12, in test_different_count self.assertItemsEqual([1,2,3], [1,2,3,4]) AssertionError: Element counts were not equal: First has 0, Second has 1: 4 == FAIL: test_equal_count_of_different_elements (__main__.Test) -- Traceback (most recent call last): File "assert_items_equal_test.py", line 8, in test_equal_count_of_different_elements self.assertItemsEqual([1,2,3], [1,2,4]) AssertionError: Element counts were not equal: First has 1, Second has 0: 3 First has 0, Second has 1: 4 -- Ran 3 tests in 0.001s FAILED (failures=2) -- ___ Python tracker <http://bugs.python.org/issue27060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27060] Documentation of assertItemsEqual in unittest is VERY misleading in 2.7
Vitaly added the comment: I think that we can close this as not a bug, as concerning 2.7. However, I think that 3.x made the wrong decision when it renamed assertItemsEqual with assertCountEqual, which now misleads users into thinking that it compares counts. -- ___ Python tracker <http://bugs.python.org/issue27060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17866] TestCase.assertItemsEqual exists in 2.7, not in 3.3
Vitaly added the comment: Folks, assertCountEqual sounds like a really bad name. It misleads users into thinking that it only compares the number of elements in each sequence, whereas it actually asserts that equivalent items are present in both sequences, regardless of order. The original name from 2.7 assertItemsEqual was so much better and more meaningful. -- ___ Python tracker <http://bugs.python.org/issue17866> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
New submission from Vitaly: Somewhere in 3.x assertItemsEqual was renamed to assertCountEqual. assertCountEqual sounds like a really inappropriate, misleading name for what it does. It misleads users into thinking that it only compares the number of elements in each sequence, whereas it actually asserts that equivalent items are present in both sequences, regardless of order. The original name from 2.7 assertItemsEqual was so much more meaningful. -- components: Library (Lib) messages: 265980 nosy: vitaly priority: normal severity: normal status: open title: unittest.TestCase.assertCountEqual is a very misleading name versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27060] Documentation of assertItemsEqual in unittest is VERY misleading in 2.7
Vitaly added the comment: Yes, this caused me to examine Counter, which I had not used before, and now I understand it, too. However, the new name by itself does not sufficiently reflect the subtlety of element-by-element counts, which does a disservice to the readability of test code. -- ___ Python tracker <http://bugs.python.org/issue27060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27060] Documentation of assertItemsEqual in unittest is VERY misleading in 2.7
Vitaly added the comment: ... and an unnecessary incompatibility between 2.7 and 3.x -- ___ Python tracker <http://bugs.python.org/issue27060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
Vitaly added the comment: The new name by itself does not sufficiently reflect the subtlety of element-by-element counts, which does a disservice to the readability of test code. And it's also an unnecessary incompatibility between 2.7 and 3.x. -- ___ Python tracker <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
Vitaly added the comment: As far as I can tell, issue #10242 deals with the renaming. I think that the arguments for the new name are flawed (sorry to be so blunt, but I don't know how else to express it). Regardless of whether it's Count or Counts, to most people it sounds like it's going to compare just the simple counts of the elements (i.e., lengths of the sequences). Ask yourself the questions: 1. What is the element count in sequence S? Reasonable answer: len(S). 2. What are the element counts of sequences Q and S? Reasonable answer len(Q) and len(S). Those are the most straightforward, non-nuanced answers you would get from most people IMHO. With ambiguous names like these, readability of the code is greatly diminished. When I review code, a name like assertCountEqual tells me (and likely most other reviewers) that it's comparing lengths of the sequences, and I have no reason to resort to the documentation. A well-named function should do what its name says, and its name should say what it does. assertCountEqual doesn't pass that test, unless you read the documentation, and apply the nuanced interpretation that is biased by the documentation. assertElementCountsEqual is in the same category, I am afraid :) The straightforward interpretation of these names is misleading at worst and ambiguous at best. I think that the authors of the new name assertCountEqual were thinking along the lines of "assert frequency counts equal", which might lead to the arguably unambiguous name assertFrequencyCountsEqual, but but all that sounds more complicated than it needs to be. Personally, something like assertElementsEqual seems to me to capture the spirit of the assertion better and is easier for most people to grasp. It doesn't imply order as it emphasizes the elements (vs. assertSequenceEqual, which emphasizes sequence), and it doesn't imply uniqueness. I like assertElementsEqual more than assertItemsEqual, but then again, assertElementsEqual is not sufficiently better than assertItemsEqual to warrant a backward-incompatible name change in my opinion. -- ___ Python tracker <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
Vitaly added the comment: If there really is a good systemic reason why names like assertItemsEqual and assertElementsEqual are flawed, then assertFrequencyCountsEqual might be a less-ambiguous alternative. -- ___ Python tracker <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
Vitaly added the comment: Gentlemen, the point is that the name of a function should be all that is necessary to unambiguously understand what this method does without having to know that it's implemented in terms of collections.Counter or any other internal detail like that. That's not a good strategy for picking names in computer programming. The name of a function should certainly not be tied to an internal implementation detail (use Counter to implement, so let's name it "Count"?). Something that asserts the equality of two collections of elements is not rocket science and does not deserve an ambiguous name. "Count" is simply too ambiguous in this case. -- ___ Python tracker <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
Vitaly added the comment: By leaps and bounds, I like assertUnorderedEqual versus assertCountEqual, which is terribly misleading. The first, and simplest, thing that comes to my mind from the word Count by itself is the count of all elements in a sequence (i.e., its length), certainly not frequency count. I am also happy with the status quo of assertItemsEqual, but I have to agree that assertUnorderedEqual removes any ambiguity that assertItemsEqual purportedly suffers from. Thank you for suggesting assertUnorderedEqual. -- ___ Python tracker <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
Vitaly added the comment: When I read "Unordered", it makes me think of collections, including sequences and sets. -- ___ Python tracker <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
Vitaly added the comment: Why do you say that "we aren't dealing with python sets"? Try: import unittest as u class Test(u.TestCase): def test_equal_count_of_same_elements(self): self.assertItemsEqual(set([1,2,3]), set([1,2,3])) def test_equal_count_of_different_elements(self): self.assertItemsEqual(set([1,2,3]), set([1,2,4])) def test_different_count(self): self.assertItemsEqual(set([1,2,3]), set([1,2,3,4])) u.main() -- ___ Python tracker <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
Vitaly added the comment: $ python assert_items_equal_test.py FF. == FAIL: test_different_count (__main__.Test) -- Traceback (most recent call last): File "assert_items_equal_test.py", line 12, in test_different_count self.assertItemsEqual(set([1,2,3]), set([1,2,3,4])) AssertionError: Element counts were not equal: First has 0, Second has 1: 4 == FAIL: test_equal_count_of_different_elements (__main__.Test) -- Traceback (most recent call last): File "assert_items_equal_test.py", line 8, in test_equal_count_of_different_elements self.assertItemsEqual(set([1,2,3]), set([1,2,4])) AssertionError: Element counts were not equal: First has 1, Second has 0: 3 First has 0, Second has 1: 4 -- ___ Python tracker <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
Vitaly added the comment: The preceding results are via Python 2.7.10 -- ___ Python tracker <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
Vitaly added the comment: Same results on Python.org's Python 3.5.1 shell: >>> class Test(u.TestCase): ... def test_equal_count_of_same_elements(self): ... self.assertCountEqual(set([1,2,3]), set([1,2,3])) ... def test_equal_count_of_different_elements(self): ... self.assertCountEqual(set([1,2,3]), set([1,2,4])) ... def test_different_count(self): ... self.assertCountEqual(set([1,2,3]), set([1,2,3,4])) ... >>> u.main() FF. == FAIL: test_different_count (__main__.Test) -- Traceback (most recent call last): File "", line 7, in test_different_count AssertionError: Element counts were not equal: First has 0, Second has 1: 4 == FAIL: test_equal_count_of_different_elements (__main__.Test) -- Traceback (most recent call last): File "", line 5, in test_equal_count_of_different_elements AssertionError: Element counts were not equal: First has 1, Second has 0: 3 -- ___ Python tracker <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
Vitaly added the comment: With missing last line, this time: == FAIL: test_equal_count_of_different_elements (__main__.Test) -- Traceback (most recent call last): File "", line 5, in test_equal_count_of_different_elements AssertionError: Element counts were not equal: First has 1, Second has 0: 3 First has 0, Second has 1: 4 -- ___ Python tracker <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
Vitaly added the comment: I think that assertUnorderedEqual would contrast nicely with assertSequenceEqual -- ___ Python tracker <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
Vitaly added the comment: assertSequenceEqualUnordered is not a good fit, because it doesn't follow the de facto naming convention, whereby "Equal" should be the suffix. Also assertSequenceEqualUnordered would be considered an oxymoron, since the word "Sequence" implies ordered, while "Unordered" is the opposite. It's like saying "ordered unordered collection". My vote (if I had one) is still with assertUnorderedEqual. I think that from the word "Unordered" it's a reasonable leap that it refers to an unordered collection of elements, and it would be easy to remember. -- ___ Python tracker <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38240] assertCountEqual is horribly misleading, sounds like only counts are being compared
New submission from Vitaly Kruglikov : assertCountEqual is a horribly misleading name because it misleads the programmer and reader of the test code into thinking that it only compares the counts of the elements. It's name misrepresents what it does in a really bad way. -- components: Tests messages: 352901 nosy: vitaly.krug priority: normal severity: normal status: open title: assertCountEqual is horribly misleading, sounds like only counts are being compared versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39518] Dark theme
Change by Vitaly Zdanevich : -- type: -> enhancement ___ Python tracker <https://bugs.python.org/issue39518> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39518] Dark theme
New submission from Vitaly Zdanevich : Please save our eyes. And batteries. Do not ignore this property of useragent https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme -- assignee: docs@python components: Documentation messages: 361177 nosy: Vitaly Zdanevich, docs@python priority: normal severity: normal status: open title: Dark theme ___ Python tracker <https://bugs.python.org/issue39518> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39518] Dark theme
Vitaly Zdanevich added the comment: Added bug report to their repo https://github.com/python/python-docs-theme/issues/43 -- ___ Python tracker <https://bugs.python.org/issue39518> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38240] assertCountEqual is horribly misleading, sounds like only counts are being compared
Change by Vitaly Kruglikov : -- status: closed -> open ___ Python tracker <https://bugs.python.org/issue38240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38240] assertCountEqual is horribly misleading, sounds like only counts are being compared
Vitaly Kruglikov added the comment: Reopened per request from ammar2 -- ___ Python tracker <https://bugs.python.org/issue38240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38240] assertCountEqual is horribly misleading, sounds like only counts are being compared
Vitaly Kruglikov added the comment: Re-opened, thanks! On Fri, Sep 20, 2019 at 3:01 PM Ammar Askar wrote: > > Ammar Askar added the comment: > > Hey Vitaly, not sure if you're the author of the original bug here: > https://bugs.python.org/issue27071 > > Could you re-open that so the discussion is kept in one place. > > -- > nosy: +ammar2 > > ___ > Python tracker > <https://bugs.python.org/issue38240> > ___ > -- ___ Python tracker <https://bugs.python.org/issue38240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38240] assertCountEqual is horribly misleading, sounds like only counts are being compared
Vitaly Kruglikov added the comment: Well, when you do tab-completion in unit tests on `self.` and `assertCountEqual` pops up, it sure sounds a lot like it's going to compare just the count of the items. The point is that the name of the function is not self-documenting, hence "misleading". A better name could be `assertItemsEqual` or `assertCountAndItemsEqual` On Sat, Sep 5, 2020 at 1:02 PM Raymond Hettinger wrote: > > Raymond Hettinger added the comment: > > This should stay closed as a duplicate. > > If you must, reopen of the original 27071, but it was closed for a > reason. The majority of respondents voted for the status quo. Each > alternative that was considered had its own share of problems. > > BTW, it is hyperbolic to call the name "horribly misleading". The method > literally runs Counter and checks for equality. The docstring is clear > about this: > > def assertCountEqual(self, first, second, msg=None): > """Asserts that two iterables have the same elements, the same > number of > times, without regard to order. > > self.assertEqual(Counter(list(first)), > Counter(list(second))) > > Example: > - [0, 1, 1] and [1, 0, 1] compare equal. > - [0, 0, 1] and [0, 1] compare unequal. > > """ > > -- > nosy: +rhettinger > status: open -> closed > > ___ > Python tracker > <https://bugs.python.org/issue38240> > ___ > -- ___ Python tracker <https://bugs.python.org/issue38240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
New submission from Vitaly Kruglikov : ``` import copy import ssl copy.copy(ssl.create_default_context()) ``` results in `TypeError: can't pickle SSLContext objects` This prevents me from being able to `copy.deepcopy()` an object that references `ssl.SSLContext`. The apparent root cause is apparently that `ssl.SSLContext` passes an extra arg to its `__new__` method, but doesn't implement the method `__getnewargs__` that would let `copy` extract the extra arg. -- messages: 313422 nosy: vitaly.krug priority: normal severity: normal status: open title: Unable to copy ssl.SSLContext versions: Python 2.7, Python 3.6 ___ Python tracker <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
Change by Vitaly Kruglikov : -- type: -> crash ___ Python tracker <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
Change by Vitaly Kruglikov : -- assignee: -> christian.heimes components: +SSL nosy: +christian.heimes ___ Python tracker <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33024] asyncio.WriteTransport.set_write_buffer_limits orders its args unintuitively and inconsistently with its companion function's return value
New submission from Vitaly Kruglikov : `asyncio.WriteTransport.set_write_buffer_limits()` uses an unintuitive order of the args (high, low). I would expect `low` to be the first arg, especially since `asyncio.WriteTransport.get_write_buffer_limits()` returns them in the opposite order. This ordering and inconsistency with the companion function's return value is error-prone. See https://docs.python.org/3/library/asyncio-protocol.html#asyncio.WriteTransport.set_write_buffer_limits -- components: asyncio messages: 313423 nosy: asvetlov, vitaly.krug, yselivanov priority: normal severity: normal status: open title: asyncio.WriteTransport.set_write_buffer_limits orders its args unintuitively and inconsistently with its companion function's return value type: behavior versions: Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue33024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33025] urlencode produces bad output from ssl.CERT_NONE and friends that chokes decoders
New submission from Vitaly Kruglikov :
```
In [9]: from urllib.parse import urlencode, parse_qs
In [10]: import ast, ssl
In [11]: d = dict(cert_reqs=ssl.CERT_NONE)
In [12]: urlencode(d)
Out[12]: 'cert_reqs=VerifyMode.CERT_NONE'
In [25]: parse_qs('cert_reqs=VerifyMode.CERT_NONE')
Out[25]: {'cert_reqs': ['VerifyMode.CERT_NONE']}
In [29]: ast.literal_eval('VerifyMode.CERT_NONE')
Traceback (most recent call last)
...
ValueError: malformed node or string: <_ast.Attribute object at 0x105c22358>
```
This used to work fine and produce `'cert_reqs=0'` on Python 2.7, allowing it
to be decoded properly downstream. However, `'cert_reqs=VerifyMode.CERT_NONE'`
can't be decoded generically. So, something it's that used to work in prior
python versions that is breaking now.
Additional information. json.dumps() actually dumps that value as a number
instead of 'VerifyMode.CERT_NONE'.
It appears that urlencode doesn't work properly with enums, where I would
expect it to emit the numeric value of the enum.
--
assignee: christian.heimes
components: Library (Lib), SSL
messages: 313424
nosy: christian.heimes, vitaly.krug
priority: normal
severity: normal
status: open
title: urlencode produces bad output from ssl.CERT_NONE and friends that chokes
decoders
type: crash
versions: Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue33025>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
Vitaly Kruglikov added the comment: Hi Christian, thank you for following up. Here is my use case, and perhaps you can suggest something else that will work: I am refactoring the transport layer in the Pika AMQP client library. The user provides an ssl.SSLContext instance for connecting to an AMQP broker (e.g., RabbitMQ). Pika will resolve the hostname via getaddrinfo and make attempts to establish TCP and AMQP connection to the candidate IP addresses until one succeeds in establishing an AMQP connection over SSL. Each connection attempt will require a fresh unadulterated clone of the ssl.SSLContext instance provided by user to avoid any side-effects from prior connection attempts. How can I obtain this pristine clone cleanly for each new connection attempt? -- ___ Python tracker <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
Vitaly Kruglikov added the comment: Also, updating ssl.SSLContext documentation about intentional inability to copy generically and suggestion how to go about it if you need to obtain a clone or similar would be terrific and save developers time so they won't run into this gotcha when designing and implementing solutions. Many thanks! -- ___ Python tracker <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
Vitaly Kruglikov added the comment: > What would those side-effects be? Christian Heimes suggested that > A context contains elements that can't be cloned easily, e.g. session > resumption tickets. My concern then would be potential side-effects from such session resumption tickets and anything else that one connection attempt might save/change within an SSL Context that might have an undesirable side-effect on the follow-on connection attempts. -- ___ Python tracker <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33062] ssl_renegotiate() doesn't seem to be exposed
New submission from Vitaly Kruglikov : I need to write a test for my client to make sure it's non-blocking ssl interactions are able to survive SSL renegotiation. However, I can't seem to find anything in our python ssl API that calls `SSL_renegotiate()` in order to force renegotiation. -- assignee: christian.heimes components: SSL messages: 313706 nosy: christian.heimes, vitaly.krug priority: normal severity: normal status: open title: ssl_renegotiate() doesn't seem to be exposed type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue33062> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33062] ssl_renegotiate() doesn't seem to be exposed
Vitaly Kruglikov added the comment: > By the way, renegotiation is a problematic and has been replaced by rekeying > in TLS 1.3 How can I trigger rekeying via python ssl? Many thanks. -- ___ Python tracker <https://bugs.python.org/issue33062> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33062] ssl_renegotiate() doesn't seem to be exposed
Vitaly Kruglikov added the comment: > For extra fun, openssl itself doesn't fully support renegotiation on duplex > connections ... The necessitated modification to the application protocol on that thread sounds like an OpenSSL cop-out. There is no good reason that OpenSSL shouldn't be able to cache incoming application data during the client-initiated handshake just as it does at other times. It should be able to cache the incoming pre-negotiation records, decoding them. The pending() check would inform the client that they need to reap the incoming data during the handshake too. -- ___ Python tracker <https://bugs.python.org/issue33062> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33118] No clean way to get notified when a Transport's write buffer empties out
New submission from Vitaly Kruglikov : There doesn't appear to be an ordained mechanism for getting notified when a Transport's (or WriteTransport's) write buffer drains to zero (i.e., all output data has been transferred to socket). I don't want to hijack `set_write_buffer_limits()` for this purpose, because that would preclude me from using it for its intended purpose. I see that transport in selector_events.py has a private method `_make_empty_waiter()`, which is along the lines of what I need, but it's private and is used by `BaseSelectorEventLoop._sendfile_native()`. Just like `BaseSelectorEventLoop._sendfile_native()`, my app needs equivalent functionality in order to be able to run the loop (`run_until_complete()`) until the transport's write buffer empties out. -- components: asyncio messages: 314236 nosy: asvetlov, vitaly.krug, yselivanov priority: normal severity: normal status: open title: No clean way to get notified when a Transport's write buffer empties out type: enhancement versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue33118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33118] No clean way to get notified when a Transport's write buffer empties out
Vitaly Kruglikov added the comment: Thank you for following up. My use case is this: In the Pika AMQP client package, we have a blocking AMQP connection adapter - `BlockingConnection` - wrapped around an asynchronous AMQP connection adapter. Presently, BlockingConnection is wrapped around the asynchronous `SelectConnection` which has a home-grown proprietary IOLoop. I would like to switch BlockingConnection to use an asyncio-based adapter when running on Python3. SelectConnection's proprietary IOLoop provides a single-stepping run function (poll with a timeout as normally determined by pending callbacks, timers, etc., process all ready events/timers/callbacks, and return). When BlockingConnection needs to send something to the AMQP broker and/or wait for an expected reply, it sends the request (which typically gets queued up in a write buffer) and then runs the proprietary IOLoop's single-stepping method in a loop (thus blocking efficiently on I/O); each time after the single-stepping IOLoop method returns, BlockingConnection checks whether the conditions of interest have been satisfied (e.g., the write buffer size being zero and AMQP Channel.OpenOk has been received). So, another way that asyncio could help, and certainly simplest for me and my use case, is by providing a single-stepping function in the event loop implementations, such as the single-stepping method that I described at the top of the previous paragraph. E.g., `events.AbstractEventLoop.run_one_step()`. -- ___ Python tracker <https://bugs.python.org/issue33118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33118] No clean way to get notified when a Transport's write buffer empties out
Vitaly Kruglikov added the comment: ... or `events.AbstractEventLoop.run_one_iteration()`. -- ___ Python tracker <https://bugs.python.org/issue33118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33118] No clean way to get notified when a Transport's write buffer empties out
Vitaly Kruglikov added the comment: > 'events.AbstractEventLoop.run_one_step()' > This is highly unlikely to ever happen. Sure, I can see how that could be a problem with other underlying implementations, such as Twisted reactor. Just wishful thinking :). -- ___ Python tracker <https://bugs.python.org/issue33118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33118] No clean way to get notified when a Transport's write buffer empties out
Vitaly Kruglikov added the comment: I'll have to settle for `set_write_buffer_limits(0, 0)` for my blocking wrapper case. I think that 'write_buffer_drained' callback is a good idea, though. -- ___ Python tracker <https://bugs.python.org/issue33118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33118] No clean way to get notified when a Transport's write buffer empties out
Vitaly Kruglikov added the comment: Yet another paradigm is the likes of `GSource` in gnome's glib. GSource "tasks" added to the event loop are polled by the event loop for readiness before the event loop blocks on select/epoll/etc.. The ones that are ready are removed from the loop and their callbacks are dispatched. I suppose that it would also be difficult to get buy-in for a feature like this from the different frameworks? -- ___ Python tracker <https://bugs.python.org/issue33118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
Vitaly Kruglikov added the comment: It would be very helpful to make a statement in SSLContext's documentation to the effect that it's not copyable. This is frankly the first time I run into a non-copyable object.I spend quite a bit of time researching this after implementing a copying strategy that failed. It would have saved me (and others...) so much time is there was a warning in SSLContext documentation about not being able to serialize/copy/deepcopy by design! Also, making that exception message more generic (ha, I wasn't pickling anything?!) as Serhiy Storchaka suggested would be a welcome addition, but not replacement for documentation. -- ___ Python tracker <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
Vitaly Kruglikov added the comment: Thank you, I'll consider myself having been warned :) On Sat, Mar 24, 2018, 7:28 AM Christian Heimes wrote: > > Christian Heimes added the comment: > > Serhiy, > I don't understand what you are trying to tell me. "cannot serialize '%s' > object" is used all over the interpreter, e.g. io, pickle, etree, and more. > I feel it's the standard message. > > Vitaly, > A lot of objects can't be copied. It's the general case for all kinds of > objects that hold operating system resources (files, sockets) or wrap > external C libraries (bz2, lzma, sqlite, ssl). We generally don't document > that an object cannot be pickled, serialized, or copied. If documentation > doesn't state that an object is copy-able or doesn't provide a dedicated > copy method, than it can't be copied. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue33023> > ___ > -- ___ Python tracker <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33148] RuntimeError('Event loop is closed') after cancelling getaddrinfo and closing loop
New submission from Vitaly Kruglikov :
I see this exception on the terminal:
```
exception calling callback for
Traceback (most recent call last):
File
"/usr/local/Cellar/python/3.6.4_3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/concurrent/futures/_base.py",
line 324, in _invoke_callbacks
callback(self)
File
"/usr/local/Cellar/python/3.6.4_3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/futures.py",
line 414, in _call_set_state
dest_loop.call_soon_threadsafe(_set_state, destination, source)
File
"/usr/local/Cellar/python/3.6.4_3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/base_events.py",
line 620, in call_soon_threadsafe
self._check_closed()
File
"/usr/local/Cellar/python/3.6.4_3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/base_events.py",
line 357, in _check_closed
raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
```
When executing this code:
```
import asyncio
while True:
loop = asyncio.new_event_loop()
coro = loop.getaddrinfo('www.google.com', 80)
task = asyncio.ensure_future(coro, loop=loop)
task.cancel()
loop.call_soon_threadsafe(loop.stop)
loop.run_forever()
loop.close()
```
Shouldn't a cancelled operation go away (or at least pretend to go away)
cleanly?
--
components: asyncio
messages: 314484
nosy: asvetlov, vitaly.krug, yselivanov
priority: normal
severity: normal
status: open
title: RuntimeError('Event loop is closed') after cancelling getaddrinfo and
closing loop
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue33148>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33206] Windows inet_pton(socket.AF_INET6, 'localhost') raises ValueError instead of socket.error
New submission from Vitaly Kruglikov :
I am seeing this with `socket.AF_INET6` on Windows running python 2.7.14
```
[00:02:33] File "C:\projects\pika\pika\adapters\host_tcp_connector.py", line
153, in _check_already_resolved
[00:02:33] socket.inet_pton(socket.AF_INET6, 'localhost')
[00:02:33] File "C:\Python27\lib\site-packages\twisted\python\compat.py",
line 68, in inet_pton
[00:02:33] raise ValueError("Illegal characters: %r" % (''.join(x),))
[00:02:33] ValueError: Illegal characters: 't'
```
With `socket.AF_INET`, `socket.inet_pton(socket.AF_INET, 'localhost')` raises
`socket.error` as expected.
For comparison, with Python 2.7.10 running on OS X, both AF_INET and AF_INET6
raise `socket.error`.
--
components: Library (Lib), Windows
messages: 314814
nosy: paul.moore, steve.dower, tim.golden, vitaly.krug, zach.ware
priority: normal
severity: normal
status: open
title: Windows inet_pton(socket.AF_INET6, 'localhost') raises ValueError
instead of socket.error
versions: Python 2.7
___
Python tracker
<https://bugs.python.org/issue33206>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33206] Windows inet_pton(socket.AF_INET6, 'localhost') raises ValueError instead of socket.error
Change by Vitaly Kruglikov : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue33206> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33206] Windows inet_pton(socket.AF_INET6, 'localhost') raises ValueError instead of socket.error
Vitaly Kruglikov added the comment: This behavior goes against the socket documentation https://docs.python.org/2/library/socket.html which states "Supported values for address_family are currently AF_INET and AF_INET6. If the IP address string ip_string is invalid, *socket.error* will be raised." -- ___ Python tracker <https://bugs.python.org/issue33206> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33206] Windows inet_pton(socket.AF_INET6, 'localhost') raises ValueError instead of socket.error
Vitaly Kruglikov added the comment: Zachary, thank you for noticing that Twisted is involved. inet_pton definitely exists on Windows 2.7.14, but it turns out that Twisted monkey-patches it if `socket.inet_pton(socket.AF_INET6, "::")` fails. Aha! - but this suggests that Window's Python 2.7.14 implementation of `socket.inet_pton()` has a bug in that it fails to recognize '::' as the the IPv6 unspecified address 0:0:0:0:0:0:0:0, so `socket.inet_pton(socket.AF_INET6, "::")` fails. I wonder if this exists on Windows Python3 implementations? -- ___ Python tracker <https://bugs.python.org/issue33206> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33206] Windows inet_pton(socket.AF_INET6, 'localhost') raises ValueError instead of socket.error
Vitaly Kruglikov added the comment: Indeed, confirmed no `inet_pton()` on Windows in Python 2.7 :(. -- ___ Python tracker <https://bugs.python.org/issue33206> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18307] Relative path in co_filename for zipped modules
Vitaly Murashev added the comment: Guys, a couple questions ... I want to suggest new patches for python3.7 and python2.7 with regression tests included What is proper way to do it now, in year 2018 ? May I do it on github.com ? Should I submit new issue for that there ? Or am I still supposed to attach new patches here - on bugs.python.org ? -- ___ Python tracker <https://bugs.python.org/issue18307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18307] Relative path in co_filename for zipped modules
Vitaly Murashev added the comment: > Vitaly, in the future please use gender-neutral words Mariatta, OK, got it, I am sorry for that. I am not a native speaker. -- ___ Python tracker <https://bugs.python.org/issue18307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18307] Relative path in co_filename for zipped modules
Change by Vitaly Murashev : -- versions: +Python 2.7, Python 3.7, Python 3.8 -Python 3.3, Python 3.4 ___ Python tracker <https://bugs.python.org/issue18307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18307] Relative path in co_filename for zipped modules
Vitaly Murashev added the comment: Pull-requests for 2.7, 3.7 and master submitted on github, all tests look passed, so Python dev-team, please, take a look. -- ___ Python tracker <https://bugs.python.org/issue18307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18307] Relative path in co_filename for zipped modules
Vitaly Murashev added the comment: > Only a PR for master is needed. Serhiy Storchaka, thanks for advice, I cancelled unnecessary PRs. -- ___ Python tracker <https://bugs.python.org/issue18307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18307] Relative path in co_filename for zipped modules
New submission from Vitaly Murashev: Recently I found out that it not possible to debug python code if it is a part of zip-module. Python version being used is 3.3.0 Well known GUI debuggers like Eclipse+PyDev or PyCharm are unable to start debugging and give the following warning: --- pydev debugger: CRITICAL WARNING: This version of python seems to be incorrectly compiled (internal generated filenames are not absolute) pydev debugger: The debugger may still function, but it will work slower and may miss breakpoints. --- So I started my own investigation of this issue and results are the following. At first I took traditional python debugger 'pdb' to analyze how it behaves during debug of zipped module. 'pdb' showed me some backtaces and filename part for stack entries looks malformed. I expected something like 'full-path-to-zip-dir/my_zipped_module.zip/subdir/test_module.py' but realy it looks like 'full-path-to-current-dir/subdir/test_module.py' Source code in pdb.py and bdb.py (which one are a part of python stdlib) gave me the answer why it happens. The root cause are inside Bdb.format_stack_entry() + Bdb.canonic() Please take a look at the following line inside 'format_stack_entry' method: filename = self.canonic(frame.f_code.co_filename) For zipped module variable 'frame.f_code.co_filename' holds _relative_ file path started from the root of zip archive like 'subdir/test_module.py' And as relult Bdb.canonic() method gives what we have - 'full-path-to-current-dir/subdir/test_module.py' --- Looks like it is a bug in: - in python core subsystem which one is responsible for loading zipped modules - or in pdb debugger -- components: Interpreter Core, Library (Lib) messages: 191907 nosy: vmurashev priority: normal severity: normal status: open title: Relative path in co_filename for zipped modules type: behavior versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue18307> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18777] Cannot compile _ssl.c using openssl > 1.0
New submission from Vitaly Murashev: Cannot compile _ssl module when openssl version > 1.0 and it is configured with turned on macro OPENSSL_NO_DEPRECATED Everything looks like in recent versions of openssl routine 'CRYPTO_set_id_callback' has gone away. Patch suggested. -- components: Build files: ssl.patch keywords: patch messages: 195602 nosy: vmurashev priority: normal severity: normal status: open title: Cannot compile _ssl.c using openssl > 1.0 type: compile error versions: Python 3.3 Added file: http://bugs.python.org/file31368/ssl.patch ___ Python tracker <http://bugs.python.org/issue18777> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18307] Relative path in co_filename for zipped modules
Vitaly Murashev added the comment: unit-test attached. There are 3 tests inside it: 2 failed, 1 succeeded. According to this test results it becomes clear that specified issue is reproduced only with zip modules which contain precompiled bytecode inside (pyc-files) -- Added file: http://bugs.python.org/file31451/test_zipimport_co_filename.py ___ Python tracker <http://bugs.python.org/issue18307> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20912] [zipfile.py]: Make zip directory attributes more friendly for MS-Windows
New submission from Vitaly Murashev: When I use 'zip' command-line tool on my Ubuntu 10.04 to pack a directory in zip-archive, it internally assigns '0x41ed0010' attributes for it. 0x41ed0010 = 0x41ed << 0xfff + 0x0010 Where: 0x41ed - unix attributes (40755) 0x0010 - means # MS-DOS directory flag At the same time zipfile.py doesn't provide MS-DOS directory flag. It seems be a good idea to do it. Patch suggested over 3.3.3 code-base. -- components: Library (Lib) files: zipfile.py.diff keywords: patch messages: 213416 nosy: vmurashev priority: normal severity: normal status: open title: [zipfile.py]: Make zip directory attributes more friendly for MS-Windows type: behavior versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34399/zipfile.py.diff ___ Python tracker <http://bugs.python.org/issue20912> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21453] Support of RPM subpackages in distutils
New submission from Vitaly Isaev: RPM Subpackages are very useful when you maintain the big project on the RHEL-kind Linux distro and you need to sparse the project into several differing packages (for instance - , -libs, -devel, -debuginfo). It would be convenient to do the same in a purely Pythonic projects (i mean to place something in setup.py and to obtain the output spec-file with a corresponding number of `%package ` sections). I didn't manage to find the code that matches these purposes in the most up-to-date release of the distutils (/usr/lib64/python2.7/distutils/command/bdist_rpm.py). So I would ask to implement this feature. Also I can try to do it on my own in case if the community considers it as a good offer. Thank you. -- components: Distutils messages: 218119 nosy: dstufft, eric.araujo, vitalyisaev2 priority: normal severity: normal status: open title: Support of RPM subpackages in distutils type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue21453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18307] Relative path in co_filename for zipped modules
Vitaly Murashev added the comment: patch suggested (over 3.3.0 code base). Without patch test fails, with patch - passed -- components: -Library (Lib) keywords: +patch Added file: http://bugs.python.org/file31781/zipimport.diff ___ Python tracker <http://bugs.python.org/issue18307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20337] bdist_rpm should support %config(noreplace)
Vitaly Isaev added the comment: I confirm the urgent need in this feature. -- nosy: +vitalyisaev2 ___ Python tracker <http://bugs.python.org/issue20337> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5103] ssl.SSLSocket timeout not working correctly when remote end is hanging
Vitaly Babiy added the comment: Why not just remove the removal of the timeout. -- nosy: +vbabiy ___ Python tracker <http://bugs.python.org/issue5103> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
