[Python-Dev] Compact dict implementations (was: PEP 468
Hi, developers. I'm trying to implement compact dict. https://github.com/methane/cpython/pull/1 Current status is passing most of tests. Some tests are failing because of I haven't updated `sizeof` until layout fix. And I haven't dropped OrderedDict has linked list. Before finishing implementation, I want to see comments and tests from core developers. Please come to core-mentorship ML or pull request and try it if you interested in. Regards, -- INADA Naoki ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2016-06-10 - 2016-06-17) Python tracker at http://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: open5544 ( -9) closed 33557 (+66) total 39101 (+57) Open issues with patches: 2417 Issues opened (41) == #10839: email module should not allow some header field repetitions http://bugs.python.org/issue10839 reopened by rhettinger #26171: heap overflow in zipimporter module http://bugs.python.org/issue26171 reopened by ned.deily #27288: secrets should use getrandom() on Linux http://bugs.python.org/issue27288 opened by dstufft #27292: Warn users that os.urandom() can return insecure values http://bugs.python.org/issue27292 opened by christian.heimes #27293: Summarize issues related to urandom, getrandom etc in secrets http://bugs.python.org/issue27293 opened by steven.daprano #27294: Better repr for Tkinter event objects http://bugs.python.org/issue27294 opened by serhiy.storchaka #27297: Add support for /dev/random to "secrets" http://bugs.python.org/issue27297 opened by larry #27298: redundant iteration over digits in _PyLong_AsUnsignedLongMask http://bugs.python.org/issue27298 opened by Oren Milman #27299: urllib does not splitport while putrequest realhost to HTTP he http://bugs.python.org/issue27299 opened by gr zhang #27300: tempfile.TemporaryFile(): missing errors=... argument http://bugs.python.org/issue27300 opened by mmarkk #27302: csv.Sniffer guesses wrong when unquoted fields contain quotes http://bugs.python.org/issue27302 opened by Redoute #27303: [argparse] Unify options in help output http://bugs.python.org/issue27303 opened by memeplex #27304: Create "Source Code" links in module sections, where relevant http://bugs.python.org/issue27304 opened by Yoni Lavi #27305: Crash with "pip list --outdated" on Windows 10 with Python 2.7 http://bugs.python.org/issue27305 opened by James.Paget #27307: string.Formatter does not support key/attribute access on unnu http://bugs.python.org/issue27307 opened by tbeadle #27309: Visual Styles support http://bugs.python.org/issue27309 opened by [HYBRID BEING] #27312: test_setupapp (idlelib.idle_test.test_macosx.SetupTest) fails http://bugs.python.org/issue27312 opened by ned.deily #27313: test case failures in test_widgets.ComboboxTest.of test_ttk_gu http://bugs.python.org/issue27313 opened by ned.deily #27314: Cannot install 3.5.2 with 3.6.0a1 installed http://bugs.python.org/issue27314 opened by steve.dower #27315: pydoc: prefer the pager command in favor of the specifc less c http://bugs.python.org/issue27315 opened by doko #27317: Handling data_files: too much is removed in uninstall http://bugs.python.org/issue27317 opened by sylvain.corlay #27318: Add support for symlinks to zipfile http://bugs.python.org/issue27318 opened by ldoktor #27319: Multiple item arguments for selection operations http://bugs.python.org/issue27319 opened by serhiy.storchaka #27320: ./setup.py --help-commands should sort extra commands http://bugs.python.org/issue27320 opened by Antony.Lee #27321: Email parser creates a message object that can't be flattened http://bugs.python.org/issue27321 opened by msapiro #27322: test_compile_path fails when python has been installed http://bugs.python.org/issue27322 opened by xdegaye #27323: ncurses putwin() fails in test_module_funcs http://bugs.python.org/issue27323 opened by xdegaye #27326: SIGSEV in test_window_funcs of test_curses http://bugs.python.org/issue27326 opened by xdegaye #27328: Documentation corrections for email defects http://bugs.python.org/issue27328 opened by martin.panter #27329: Document behavior when CDLL is called with None as an argumen http://bugs.python.org/issue27329 opened by Jeffrey Esquivel Sibaja #27331: Add a policy argument to email.mime.MIMEBase http://bugs.python.org/issue27331 opened by berker.peksag #27332: Clinic: first parameter for module-level functions should be P http://bugs.python.org/issue27332 opened by encukou #27333: validate_step in rangeobject.c, incorrect code logic but right http://bugs.python.org/issue27333 opened by xiang.zhang #27334: pysqlite3 context manager not performing rollback when a datab http://bugs.python.org/issue27334 opened by lciti #27335: Clarify that writing to locals() inside a class body is suppor http://bugs.python.org/issue27335 opened by steven.daprano #27337: 3.6.0a2 tarball has weird paths http://bugs.python.org/issue27337 opened by petere #27340: bytes-like objects with socket.sendall(), SSL, and http.client http://bugs.python.org/issue27340 opened by martin.panter #27341: mock.patch decorator fails silently on generators http://bugs.python.org/issue27341 opened by shoshber #27342: Clean up some Py_XDECREFs in rangeobject.c and bltinmodule.c http://bugs.python.org/issue27342 opened by xiang.zhang #27343: Incorrect error message for co
Re: [Python-Dev] Discussion overload
On 16 June 2016 at 19:00, Kevin Ollivier wrote: > Hi Guido, > > From: on behalf of Guido van Rossum > > Reply-To: > Date: Thursday, June 16, 2016 at 5:27 PM > To: Kevin Ollivier > Cc: Python Dev > Subject: Re: [Python-Dev] Discussion overload > > Hi Kevin, > > I often feel the same way. Are you using GMail? It combines related messages > in threads and lets you mute threads. I often use this feature so I can > manage my inbox. (I presume other mailers have the same features, but I > don't know if all of them do.) There are also many people who read the list > on a website, e.g. gmane. (Though I think that sometimes the delays incurred > there add to the noise -- e.g. when a decision is reached on the list > sometimes people keep responding to earlier threads.) > > > I fear I did quite a poor job of making my point. :( I've been on open > source mailing lists since the late 90s, so I've learned strategies for > dealing with mailing list overload. I've got my mail folders, my mail rules, > etc. Having been on many mailing lists over the years, I've seen many > productive discussions and many unproductive ones, and over time you start > to see patterns. You also see what happens to those communities over time. This is one of the major reasons we have the option of escalating things to the PEP process (and that's currently in train for os.urandom), as well as the SIGs for when folks really need to dig into topics that risk incurring a relatively low signal-to-noise ration on python-dev. It's also why python-ideas was turned into a separate list, since folks without the time for more speculative discussions and brainstorming can safely ignore it, while remaining confident that any ideas considered interesting enough for further review will be brought to python-dev's attention. But yes, one of the more significant design errors I've made with the contextlib API was due to just such a draining pile-on by folks that weren't happy the original name wasn't a 100% accurate description of the underlying mechanics (even though it was an accurate description of the intended use case), and "people yelling at you on project communication channels without doing adequate research first" is the number one reason we see otherwise happily engaged core developers decide to find something else to do with their time. The challenge and art in community management in that context is balancing telling both old and new list participants "It's OK to ask 'Why is this so?', as sometimes the answer is that there isn't a good reason and we may want to change it" and "Learn to be a good peer manager, and avoid behaving like a micro-managing autocrat that chases away experienced contributors". Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace
On 7 June 2016 at 17:50, Eric Snow wrote: > Why is __definition_order__ even necessary? > --- > > Since the definition order is not preserved in ``__dict__``, it would be > lost once class definition execution completes. Classes *could* > explicitly set the attribute as the last thing in the body. However, > then independent decorators could only make use of classes that had done > so. Instead, ``__definition_order__`` preserves this one bit of info > from the class body so that it is universally available. The discussion in the PEP 487 thread made me realise that I'd like to see a discussion in PEP 520 regarding whether or not to define __definition_order__ for builtin types initialised via PyType_Ready or created via PyType_FromSpec in addition to defining it for types created via the class statement or types.new_class(). For static types, PyType_Ready could potentially set it based on tp_members, tp_methods & tp_getset (see https://docs.python.org/3/c-api/typeobj.html ) Similarly, PyType_FromSpec could potentially set it based on the contents of Py_tp_members, Py_tp_methods and Py_tp_getset slot definitions Having definition order support in both types.new_class() and builtin types would also make it clear why we can't rely purely on the compiler to provide the necessary ordering information - in both of those cases, the Python compiler isn't directly involved in the type creation process. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] frame evaluation API PEP
I have taken PEP 523 for this: https://github.com/python/peps/blob/master/pep-0523.txt . I'm waiting until Guido gets back from vacation, at which point I'll ask for a pronouncement or assignment of a BDFL delegate. On Fri, 3 Jun 2016 at 14:37 Brett Cannon wrote: > For those of you who follow python-ideas or were at the PyCon US 2016 > language summit, you have already seen/heard about this PEP. For those of > you who don't fall into either of those categories, this PEP proposed a > frame evaluation API for CPython. The motivating example of this work has > been Pyjion, the experimental CPython JIT Dino Viehland and I have been > working on in our spare time at Microsoft. The API also works for > debugging, though, as already demonstrated by Google having added a very > similar API internally for debugging purposes. > > The PEP is pasted in below and also available in rendered form at > https://github.com/Microsoft/Pyjion/blob/master/pep.rst (I will assign > myself a PEP # once discussion is finished as it's easier to work in git > for this for the rich rendering of the in-progress PEP). > > I should mention that the difference from python-ideas and the language > summit in the PEP are the listed support from Google's use of a very > similar API as well as clarifying the co_extra field on code objects > doesn't change their immutability (at least from the view of the PEP). > > -- > PEP: NNN > Title: Adding a frame evaluation API to CPython > Version: $Revision$ > Last-Modified: $Date$ > Author: Brett Cannon , > Dino Viehland > Status: Draft > Type: Standards Track > Content-Type: text/x-rst > Created: 16-May-2016 > Post-History: 16-May-2016 > 03-Jun-2016 > > > Abstract > > > This PEP proposes to expand CPython's C API [#c-api]_ to allow for > the specification of a per-interpreter function pointer to handle the > evaluation of frames [#pyeval_evalframeex]_. This proposal also > suggests adding a new field to code objects [#pycodeobject]_ to store > arbitrary data for use by the frame evaluation function. > > > Rationale > = > > One place where flexibility has been lacking in Python is in the direct > execution of Python code. While CPython's C API [#c-api]_ allows for > constructing the data going into a frame object and then evaluating it > via ``PyEval_EvalFrameEx()`` [#pyeval_evalframeex]_, control over the > execution of Python code comes down to individual objects instead of a > hollistic control of execution at the frame level. > > While wanting to have influence over frame evaluation may seem a bit > too low-level, it does open the possibility for things such as a > method-level JIT to be introduced into CPython without CPython itself > having to provide one. By allowing external C code to control frame > evaluation, a JIT can participate in the execution of Python code at > the key point where evaluation occurs. This then allows for a JIT to > conditionally recompile Python bytecode to machine code as desired > while still allowing for executing regular CPython bytecode when > running the JIT is not desired. This can be accomplished by allowing > interpreters to specify what function to call to evaluate a frame. And > by placing the API at the frame evaluation level it allows for a > complete view of the execution environment of the code for the JIT. > > This ability to specify a frame evaluation function also allows for > other use-cases beyond just opening CPython up to a JIT. For instance, > it would not be difficult to implement a tracing or profiling function > at the call level with this API. While CPython does provide the > ability to set a tracing or profiling function at the Python level, > this would be able to match the data collection of the profiler and > quite possibly be faster for tracing by simply skipping per-line > tracing support. > > It also opens up the possibility of debugging where the frame > evaluation function only performs special debugging work when it > detects it is about to execute a specific code object. In that > instance the bytecode could be theoretically rewritten in-place to > inject a breakpoint function call at the proper point for help in > debugging while not having to do a heavy-handed approach as > required by ``sys.settrace()``. > > To help facilitate these use-cases, we are also proposing the adding > of a "scratch space" on code objects via a new field. This will allow > per-code object data to be stored with the code object itself for easy > retrieval by the frame evaluation function as necessary. The field > itself will simply be a ``PyObject *`` type so that any data stored in > the field will participate in normal object memory management. > > > Proposal > > > All proposed C API changes below will not be part of the stable ABI. > > > Expanding ``PyCodeObject`` > -- > > One field is to be added to the ``PyCodeObject`` struct > [#pycodeobject]_:: > > typedef struct
[Python-Dev] security SIG? (was: Discussion overload)
On Fri, 17 Jun 2016 at 18:13 Nick Coghlan wrote: > On 16 June 2016 at 19:00, Kevin Ollivier > wrote: > > Hi Guido, > > > > From: on behalf of Guido van Rossum > > > > Reply-To: > > Date: Thursday, June 16, 2016 at 5:27 PM > > To: Kevin Ollivier > > Cc: Python Dev > > Subject: Re: [Python-Dev] Discussion overload > > > > Hi Kevin, > > > > I often feel the same way. Are you using GMail? It combines related > messages > > in threads and lets you mute threads. I often use this feature so I can > > manage my inbox. (I presume other mailers have the same features, but I > > don't know if all of them do.) There are also many people who read the > list > > on a website, e.g. gmane. (Though I think that sometimes the delays > incurred > > there add to the noise -- e.g. when a decision is reached on the list > > sometimes people keep responding to earlier threads.) > > > > > > I fear I did quite a poor job of making my point. :( I've been on open > > source mailing lists since the late 90s, so I've learned strategies for > > dealing with mailing list overload. I've got my mail folders, my mail > rules, > > etc. Having been on many mailing lists over the years, I've seen many > > productive discussions and many unproductive ones, and over time you > start > > to see patterns. You also see what happens to those communities over > time. > > This is one of the major reasons we have the option of escalating > things to the PEP process (and that's currently in train for > os.urandom), as well as the SIGs for when folks really need to dig > into topics that risk incurring a relatively low signal-to-noise > ration on python-dev. It's also why python-ideas was turned into a > separate list, since folks without the time for more speculative > discussions and brainstorming can safely ignore it, while remaining > confident that any ideas considered interesting enough for further > review will be brought to python-dev's attention. > Do we need a security SIG? E.g. would people like Christian and Cory like to have a separate place to talk about the ssl stuff brought up at the language summit? -Brett ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] security SIG? (was: Discussion overload)
On Jun 18, 2016, at 03:06 AM, Brett Cannon wrote: >Do we need a security SIG? E.g. would people like Christian and Cory like >to have a separate place to talk about the ssl stuff brought up at the >language summit? The only thing I'd be worried about is people thinking that the sig is the place to report confidential security issues. Thesaurusly suggesting danger-sig and not just because that sounds so much cooler. not-a-serious-suggestion-ly y'rs, -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
