[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2017-09-29 - 2017-10-06) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open6225 (+17) closed 37243 (+62) total 43468 (+79) Open issues with patches: 2393 Issues opened (53) == #11063: Rework uuid module: lazy initialization and add a new C extens https://bugs.python.org/issue11063 reopened by haypo #31178: [EASY] subprocess: TypeError: can't concat str to bytes, in _e https://bugs.python.org/issue31178 reopened by haypo #31415: Add -X option to show import time https://bugs.python.org/issue31415 reopened by terry.reedy #31639: http.server and SimpleHTTPServer hang after a few requests https://bugs.python.org/issue31639 opened by mattpr #31640: Document exit() from parse_args https://bugs.python.org/issue31640 opened by CharlesMerriam #31642: None value in sys.modules no longer blocks import https://bugs.python.org/issue31642 opened by christian.heimes #31643: test_uuid: test_getnode and test_windll_getnode fail if connec https://bugs.python.org/issue31643 opened by Ivan.Pozdeev #31645: openssl build fails in win32 if .pl extension is not associate https://bugs.python.org/issue31645 opened by Ivan.Pozdeev #31647: asyncio: StreamWriter write_eof() after close raises mysteriou https://bugs.python.org/issue31647 opened by twisteroid ambassador #31650: implement PEP 552 https://bugs.python.org/issue31650 opened by benjamin.peterson #31652: make install fails: no module _ctypes https://bugs.python.org/issue31652 opened by Dandan Lee #31653: Don't release the GIL if we can acquire a multiprocessing sema https://bugs.python.org/issue31653 opened by Daniel Colascione #31654: ctypes should support atomic operations https://bugs.python.org/issue31654 opened by Daniel Colascione #31655: SimpleNamespace accepts non-string keyword names https://bugs.python.org/issue31655 opened by serhiy.storchaka #31658: xml.sax.parse won't accept path objects https://bugs.python.org/issue31658 opened by craigh #31659: ssl module should not use textwrap for wrapping PEM format. https://bugs.python.org/issue31659 opened by inada.naoki #31660: sys.executable different in os.execv'd python3.6 virtualenv se https://bugs.python.org/issue31660 opened by Stephen Moore #31664: Add support of new crypt methods https://bugs.python.org/issue31664 opened by serhiy.storchaka #31665: Edit "Setting [windows] environmental variables" https://bugs.python.org/issue31665 opened by terry.reedy #31666: Pandas_datareader Error Message - ModuleNotFoundError: No modu https://bugs.python.org/issue31666 opened by Scott Tucholka #31667: Wrong links in the gettext.NullTranslations class https://bugs.python.org/issue31667 opened by linkid #31668: "fixFirefoxAnchorBug" function in doctools.js causes navigatin https://bugs.python.org/issue31668 opened by fireattack #31670: Associate .wasm with application/wasm https://bugs.python.org/issue31670 opened by flagxor #31672: string.Template should use re.ASCII flag https://bugs.python.org/issue31672 opened by inada.naoki #31674: Buildbots: random "Failed to connect to github.com port 443: C https://bugs.python.org/issue31674 opened by haypo #31676: test.test_imp.ImportTests.test_load_source has side effects https://bugs.python.org/issue31676 opened by serhiy.storchaka #31678: Incorrect C Function name for timedelta https://bugs.python.org/issue31678 opened by phobosmir #31680: Expose curses library name and version on Python level https://bugs.python.org/issue31680 opened by serhiy.storchaka #31681: pkgutil.get_data() leaks open files in Python 2.7 https://bugs.python.org/issue31681 opened by Elvis.Pranskevichus #31683: a stack overflow on windows in faulthandler._fatal_error() https://bugs.python.org/issue31683 opened by Oren Milman #31684: Scientific formatting of decimal 0 different from float 0 https://bugs.python.org/issue31684 opened by Aaron.Meurer #31686: GZip library doesn't properly close files https://bugs.python.org/issue31686 opened by Jake Lever #31687: test_semaphore_tracker() of test_multiprocessing_spawn fails r https://bugs.python.org/issue31687 opened by haypo #31690: Make RE "a", "L" and "u" inline flags local https://bugs.python.org/issue31690 opened by serhiy.storchaka #31691: Include missing info on required build steps and how to build https://bugs.python.org/issue31691 opened by Ivan.Pozdeev #31692: [2.7] Test `test_huntrleaks()` of test_regrtest fails in debug https://bugs.python.org/issue31692 opened by ishcherb #31694: Running Windows installer with LauncherOnly=1 should not regis https://bugs.python.org/issue31694 opened by uranusjr #31695: Improve bigmem tests https://bugs.python.org/issue31695 opened by serhiy.storchaka #31698: Add REQ_NAME to the node.h API https://bugs.python.org/issue31698 opened by Jelle Zijlstra #31699: Deadlocks
Re: [Python-Dev] PEP 554 v3 (new interpreters module)
While I'm actually trying not to say much here so that I can avoid this discussion now, here's just a couple of ideas and thoughts from me at this point: (A) Instead of sending bytes and receiving memoryviews, one could consider sending *and* receiving memoryviews for now. That could then be extended into more types of objects in the future without changing the basic concept of the channel. Probably, the memoryview would need to be copied (but not the data of course). But I'm guessing copying a memoryview would be quite fast. This would hopefully require less API changes or additions in the future. OTOH, giving it a different name like MemChannel or making it 3rd party will buy some more time to figure out the right API. But maybe that's not needed. (B) We would probably then like to pretend that the object coming out the other end of a Channel *is* the original object. As long as these channels are the only way to directly pass objects between interpreters, there are essentially only two ways to tell the difference (AFAICT): 1. Calling id(...) and sending it over to the other interpreter and checking if it's the same. 2. When the same object is sent twice to the same interpreter. Then one can compare the two with id(...) or using the `is` operator. There are solutions to the problems too: 1. Send the id() from the sending interpreter along with the sent object so that the receiving interpreter can somehow attach it to the object and then return it from id(...). 2. When an object is received, make a lookup in an interpreter-wide cache to see if an object by this id has already been received. If yes, take that one. Now it should essentially look like the received object is really "the same one" as in the sending interpreter. This should also work with multiple interpreters and multiple channels, as long as the id is always preserved. (C) One further complication regarding memoryview in general is that .release() should probably be propagated to the sending interpreter somehow. (D) I think someone already mentioned this one, but would it not be better to start a new interpreter in the background in a new thread by default? I think this would make things simpler and leave more freedom regarding the implementation in the future. If you need to run an interpreter within the current thread, you could perhaps optionally do that too. ––Koos PS. I have lots of thoughts related to this, but I can't afford to engage in them now. (Anyway, it's probably more urgent to get some stuff with PEP 555 and its spin-off thoughts out of the way). On Fri, Oct 6, 2017 at 6:38 AM, Nick Coghlan wrote: > On 6 October 2017 at 11:48, Eric Snow wrote: > >> > And that's the real pay-off that comes from defining this in terms of >> the >> > memoryview protocol: Py_buffer structs *aren't* Python objects, so it's >> only >> > a regular C struct that gets passed across the interpreter boundary (the >> > reference to the original objects gets carried along passively as part >> of >> > the CIV - it never gets *used* in the receiving interpreter). >> >> Yeah, the (PEP 3118) buffer protocol offers precedent in a number of >> ways that are applicable to channels here. I'm simply reticent to >> lock PEP 554 into such a specific solution as the buffer-specific CIV. >> I'm trying to accommodate anticipated future needs while keeping the >> PEP as simple and basic as possible. It's driving me nuts! :P Things >> were *much* simpler before I added Channels to the PEP. :) >> > > Starting with memory-sharing only doesn't lock us into anything, since you > can still add a more flexible kind of channel based on a different protocol > later if it turns out that memory sharing isn't enough. > > By contrast, if you make the initial channel semantics incompatible with > multiprocessing by design, you *will* prevent anyone from experimenting > with replicating the shared memory based channel API for communicating > between processes :) > > That said, if you'd prefer to keep the "Channel" name available for the > possible introduction of object channels at a later date, you could call > the initial memoryview based channel a "MemChannel". > > >> > I don't think we should be touching the behaviour of core builtins >> solely to >> > enable message passing to subinterpreters without a shared GIL. >> >> Keep in mind that I included the above as a possible solution using >> tp_share() that would work *after* we stop sharing the GIL. My point >> is that with tp_share() we have a solution that works now *and* will >> work later. I don't care how we use tp_share to do so. :) I long to >> be able to say in the PEP that you can pass bytes through the channel >> and get bytes on the other side. >> > > Memory views are a builtin type as well, and they emphasise the practical > benefit we're trying to get relative to typical multiprocessing > arranagements: zero-copy data sharing. > > So here's my proposed experimentation-enabling development stra
Re: [Python-Dev] PEP 553
apologies - I didn't "reply all" to this. For the record: I made an argument (in reply) about interactive tinkering, and setting "condition", and Guido replied essentially that "if condition: breakpoint()" is just as good for tinkering... a condition parameter to debuggers is not useful, and not as explicit. Yes - agreed (and the `gist` which I tinkered w/ one day - I've now discarded ;-). Thanks, Guido! - Yarko On Wed, Oct 4, 2017 at 9:12 PM, Guido van Rossum wrote: > Yarko, there's one thing I don't understand. Maybe you can enlighten me. > Why would you prefer > > breakpoint(x >= 1000) > > over > > if x >= 1000: breakpoint() > > ? > > The latter seems unambiguous and requires thinking all around. Is there > something in iPython that makes this impractical? > > -- > --Guido van Rossum (python.org/~guido) > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
