Re: [Python-Dev] PEP 550 v3

On Sat, Aug 19, 2017 at 4:17 AM, Nick Coghlan wrote: [..] >> >> * Generator's ``.send()`` and ``.throw()`` methods are modified as >> follows (in pseudo-C):: >> >> if gen.__logical_context__ is not NULL: >> tstate = PyThreadState_Get() >> >> tstate.execution_context.push(gen.

Re: [Python-Dev] PEP 550 v3

On Mon, Aug 21, 2017 at 3:10 PM, Guido van Rossum wrote: [..] > Agreed. However now I am confused as to how the HAMT fits in. Yury says > somewhere that the HAMT will be used for the EC and then cloning the EC is > just returning a pointer to the same EC. But even if I interpret that as > making a

Re: [Python-Dev] PEP 550 v3 naming

-1 on using "frame" in PEP 550 terminology. Antoine is right, the API is not frame-specific, and "frame" in Python has only one meaning. I can certainly see how "ContextFrame" can be correct if we think about "frame" as a generic term, but in Python, people will inadvertently think about a connect

[Python-Dev] PEP 550 v3

you, Yury PEP: 550 Title: Execution Context Version: $Revision$ Last-Modified: $Date$ Author: Yury Selivanov Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 11-Aug-2017 Python-Version: 3.7 Post-History: 11-Aug-2017, 15-Aug-2017, 18-Aug-2017 Abstract This PEP

Re: [Python-Dev] __signature__ for PySide ready

Hi Christian, On Fri, Aug 18, 2017 at 4:41 AM, Christian Tismer wrote: > Hi friends, > > in the last months, I have developed signature support for > PySide. The module creates the same signatures as are known > for plain Python functions. > > As a non-trivial addition, the module also handles mu

Re: [Python-Dev] API design: where to add async variants of existing stdlib APIs?

On 2017-03-01 2:16 AM, Nathaniel Smith wrote: On Tue, Feb 28, 2017 at 9:42 PM, Nick Coghlan wrote: Short version: - there are some reasonable requests for async variants of contextlib APIs for 3.7 - prompted by Raymond, I'm thinking it actually makes more sense to add these in a new `asyncio

Re: [Python-Dev] API design: where to add async variants of existing stdlib APIs?

On 2017-03-01 12:42 AM, Nick Coghlan wrote: Short version: - there are some reasonable requests for async variants of contextlib APIs for 3.7 - prompted by Raymond, I'm thinking it actually makes more sense to add these in a new `asyncio.contextlib` module than it does to add them directly to

Re: [Python-Dev] Can we use "designated initializer" widely in core modules?

On 2017-01-17 11:55 AM, Brett Cannon wrote: So, how widely can we use "designated initializer"? Only in Modules (_asyncio uses it already)? Or almost everywhere (Objects/ and Python/)? I say everywhere we can (and that also means we should probably update the xx* files in Modules/). +1. Yur

Re: [Python-Dev] Adding bytes.frombuffer() constructor to PEP 467

On 2017-01-05 7:11 PM, INADA Naoki wrote: bytes.frombuffer(x) is bytes(memoryview(x)) or memoryview(x).tobytes(). There is pitfall: memoryview should be closed. So b = bytes.frombuffer(x) is: with memoryview(x) as m: b = bytes(m) # or b = m.tobytes() Thinking more about this, an

Re: [Python-Dev] [Python-checkins] Daily reference leaks (b78574cb00ab): sum=1120

On 2016-11-19 2:46 PM, Kevin Modzelewski wrote: Hi Yury, you may be interested in some leak-finding code that wrote for Pyston. It uses the GC infrastructure to show you objects that were directly leaked, ignoring indirect leaks -- ie objects that were only leaked because they were referenced

Re: [Python-Dev] [Python-checkins] Daily reference leaks (b78574cb00ab): sum=1120

On 2016-11-09 10:16 AM, Yury Selivanov wrote: I'm trying to fix refleaks in 3.6. So far: On 2016-11-09 4:02 AM, solip...@pitrou.net wrote: results for b78574cb00ab on branch "default" test_ast leaked [98, 98, 98] references, s

Re: [Python-Dev] [Python-checkins] Daily reference leaks (b78574cb00ab): sum=1120

I'm trying to fix refleaks in 3.6. So far: On 2016-11-09 4:02 AM, solip...@pitrou.net wrote: results for b78574cb00ab on branch "default" test_ast leaked [98, 98, 98] references, sum=294 test_ast leaked [98, 98, 98] memory blocks, sum=294 test_asyn

Re: [Python-Dev] Benchmarking Python and micro-optimizations

Thank you Victor! This is a massive amount of work. On 2016-10-20 6:56 AM, Victor Stinner wrote: * I plan to run performance on CPython 2.7, CPython 3.7, PyPy and PyPy 3. Maybe also CPython 3.5 and CPython 3.6 if they don't take too much resources. I think it's important to run 3.5 & 3.6 to

[Python-Dev] Python 3.6 what's new

Hi, Elvis and I authored What's New in Python 3.5. We'd like to volunteer to do the same for 3.6. If there are no objections, we can make the first editing pass in a couple of weeks. Yury ___ Python-Dev mailing list Python-Dev@python.org https://m

Re: [Python-Dev] Python 3.7: remove all private C functions from the Python C API?

Some of the functions we have are really intended to be used *only* by the interpreter itself. For those it would be cool to have them in private headers (AFAIK we already do this, see dict-common.h for instance). Other than that, I think that using the underscore convention is fine. Yury

Re: [Python-Dev] PEP 525, fourth update

usly optimistic and I am grateful to Yury for the care and effort he has put into it. --Guido On Tue, Sep 6, 2016 at 5:10 PM, Yury Selivanov wrote: Hi, I've updated PEP 525 with a new section about asyncio changes. Essentially, asyncio event loop will get a new "shutdown_asyncgens&quo

[Python-Dev] PEP 525, fourth update

Hi, I've updated PEP 525 with a new section about asyncio changes. Essentially, asyncio event loop will get a new "shutdown_asyncgens" method that allows to close the loop and all associated AGs with it reliably. Only the updated section is pasted below: asyncio --- The asyncio event

Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

But without that new API (basically what Christian proposed) you'd need to iterate over the list in order to find the object that belongs to Pyjion. Yes. Yeah, which means the same for my opcode patch... Which unfortunately will make things slower :( If we manage t

Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

On 2016-09-03 5:19 PM, Brett Cannon wrote: On Sat, 3 Sep 2016 at 16:43 Yury Selivanov <mailto:yselivanov...@gmail.com>> wrote: On 2016-09-03 4:15 PM, Christian Heimes wrote: > On 2016-09-04 00:03, Yury Selivanov wrote: >> >> On 2016-09-03 12:2

Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

On 2016-09-03 4:13 PM, Chris Angelico wrote: On Sun, Sep 4, 2016 at 8:03 AM, Yury Selivanov wrote: On 2016-09-03 12:27 PM, Brett Cannon wrote: Below is the `co_extra` section of PEP 523 with the update saying that users are expected to put a tuple in the field for easier simultaneous use of

Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

On 2016-09-03 4:15 PM, Christian Heimes wrote: On 2016-09-04 00:03, Yury Selivanov wrote: On 2016-09-03 12:27 PM, Brett Cannon wrote: Below is the `co_extra` section of PEP 523 with the update saying that users are expected to put a tuple in the field for easier simultaneous use of the

Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

On 2016-09-03 12:27 PM, Brett Cannon wrote: Below is the `co_extra` section of PEP 523 with the update saying that users are expected to put a tuple in the field for easier simultaneous use of the field. Since the `co_extra` discussions do not affect CPython itself I'm planning on landing t

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On 2016-08-30 2:20 PM, Guido van Rossum wrote: I'm happy to present PEP 526 for your collective review: https://www.python.org/dev/peps/pep-0526/ (HTML) https://github.com/python/peps/blob/master/pep-0526.txt (source) There's also an implementation ready: https://github.com/ilevkivskyi/cpython

Re: [Python-Dev] PEP 525, third round, better finalization

Hi Oscar, I don't think PyPy is in breach of the language spec here. Python made a decision a long time ago to shun RAII-style implicit cleanup in favour if with-style explicit cleanup. The solution to this problem is to move resource management outside of the generator functions. This is true f

Re: [Python-Dev] PEP 525, third round, better finalization

Hi Nathaniel, On 2016-09-02 2:13 AM, Nathaniel Smith wrote: On Thu, Sep 1, 2016 at 3:34 PM, Yury Selivanov wrote: Hi, I've spent quite a while thinking and experimenting with PEP 525 trying to figure out how to make asynchronous generators (AG) finalization reliable. I've tried

[Python-Dev] PEP 525, third round, better finalization

Hi, I've spent quite a while thinking and experimenting with PEP 525 trying to figure out how to make asynchronous generators (AG) finalization reliable. I've tried to replace the callback for GCed with a callback to intercept first iteration of AGs. Turns out it's very hard to work with we

Re: [Python-Dev] PEP 525

On 2016-08-24 3:01 PM, Sven R. Kunze wrote: On 24.08.2016 18:35, Guido van Rossum wrote: On Wed, Aug 24, 2016 at 8:17 AM, Yury Selivanov mailto:yselivanov...@gmail.com>> wrote: On 2016-08-23 10:38 PM, Rajiv Kumar wrote: I was playing with your implementation to gain a

Re: [Python-Dev] PEP 525

On 2016-08-24 12:35 PM, Guido van Rossum wrote: On Wed, Aug 24, 2016 at 8:17 AM, Yury Selivanov mailto:yselivanov...@gmail.com>> wrote: On 2016-08-23 10:38 PM, Rajiv Kumar wrote: I was playing with your implementation to gain a better understanding of the operat

Re: [Python-Dev] PEP 525

Hi Rajiv, On 2016-08-23 10:38 PM, Rajiv Kumar wrote: Hi Yury, I was playing with your implementation to gain a better understanding of the operation of asend() and friends. Since I was explicitly trying to "manually" advance the generators, I wasn't using asyncio or other event loop. This me

[Python-Dev] PEP 525

all open AGs. The second approach gives event loops more control and allows to implement APIs to collect open resources gracefully. The only downside is that it's a bit harder for event loops to work with. Let's discuss. PEP: 525 Title: Asynchronous Generators Version: $Revision$ Last

Re: [Python-Dev] Review request: issue 27350, compact ordered dict

On 2016-08-09 9:12 AM, INADA Naoki wrote: Hi, devs. I've implemented compact and ordered dictionary [1], which PyPy implemented in 2015 [2]. Does this mean that keyword arguments will become ordered? Yury ___ Python-Dev mailing list Python-Dev@pyt

Re: [Python-Dev] New calling convention to avoid temporarily tuples when calling functions

On 2016-08-08 6:53 PM, Victor Stinner wrote: 2016-08-09 0:40 GMT+02:00 Guido van Rossum : tl;dr I found a way to make CPython 3.6 faster and I validated that there is no performance regression. But is there a performance improvement? Sure. On micro-benchmarks, you can see nice improvements:

Re: [Python-Dev] Rewrite @contextlib.contextmanager in C

On 2016-08-08 4:18 PM, Guido van Rossum wrote: I think Nick would be interested in understanding why this is the case. What does the decorator do that could be so expensive? From the looks of it it doesn't do anything special. Although with @contextlib.contextmanager we have to instantiate

Re: [Python-Dev] Rewrite @contextlib.contextmanager in C

On 2016-08-08 3:33 PM, Giampaolo Rodola' wrote: I wanted to give it a try rewriting this in C but since @contextmanager has a lot of magic I wanted to ask first whether this 1) is technically possible 2) is desirable. It is definitely technologically possible. However, the C implementation

[Python-Dev] Request for CPython 3.5.3 release

Long story short, I've discovered that asyncio is broken in 3.5.2. Specifically, there is a callbacks race in `loop.sock_connect` which can make subsequent `loop.sock_sendall` calls to hang forever. This thing is very tricky and hard to detect and debug; I had to spend a few hours investigating wh

Re: [Python-Dev] PEP 492: __aiter__ should return async iterator directly instead of awaitable

On 2016-06-06 4:02 PM, Łukasz Langa wrote: The proposed patch fixes the __aiter__ in a backwards compatible way: 1. ceval/GET_AITER opcode calls the __aiter__ method. 2. If the returned object has an '__anext__' method, GET_AITER silently wraps it in an awaitable, which is equivalent to the

[Python-Dev] PEP 492: __aiter__ should return async iterator directly instead of awaitable

There is a small flaw in PEP 492 design -- __aiter__ should not return an awaitable object that resolves to an asynchronous iterator. It should return an asynchronous iterator directly. Let me explain this by showing some examples. I've discovered this while working on a new asynchronous gener

Re: [Python-Dev] RFC: PEP 509: Add a private version to dict

On 2016-04-14 4:42 PM, Armin Rigo wrote: Hi Victor, On 14 April 2016 at 17:19, Victor Stinner wrote: Each time a dictionary is created, the global version is incremented and the dictionary version is initialized to the global version. A detail, but why not set the version tag of new empty d

Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units

On 2016-04-13 12:24 PM, Victor Stinner wrote: Can someone please review the change? +1 for the change. I can take a look at the patch in a few days. Yury ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/py

Re: [Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement

On 2016-02-08 8:02 PM, Steven D'Aprano wrote: On Mon, Feb 08, 2016 at 05:43:25PM -0500, Yury Selivanov wrote: On 2016-02-08 5:19 PM, Terry Reedy wrote: On 2/8/2016 4:51 PM, Victor Stinner wrote: 2016-02-08 22:28 GMT+01:00 Alexander Walters : What incantation do you need to do to make

Re: [Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement

On 2016-02-08 5:19 PM, Terry Reedy wrote: On 2/8/2016 4:51 PM, Victor Stinner wrote: 2016-02-08 22:28 GMT+01:00 Alexander Walters : What incantation do you need to do to make that behavior apparent? I didn't know. I just checked. It's assert used with a non-empty tuple: assert ("tuple",)

Re: [Python-Dev] speed.python.org

Zachary, Do you run the benchmarks in rigorous mode? Yury On 2016-02-04 1:48 AM, Zachary Ware wrote: I'm happy to announce that speed.python.org is finally functional! There's not much there yet, as each benchmark builder has only sent one result so far (and one of those involved a bit of chea

Re: [Python-Dev] PEP 0492 __aenter__ & __aexit__

Brett, Do you think we should update PEP 492 with links to the docs? I'm thinking of adding a new section to the top. Yury On 2016-02-06 5:05 PM, Brett Cannon wrote: On Sat, 6 Feb 2016 at 13:50 Daniel Miller > wrote: Hi Python-Dev Group, I am t

Re: [Python-Dev] speed.python.org

Big thanks to you, Zachary (and everyone involved)! It's a very good news. Yury On 2016-02-04 1:48 AM, Zachary Ware wrote: I'm happy to announce that speed.python.org is finally functional! There's not much there yet, as each benchmark builder has only sent one result so far (and one of those

Re: [Python-Dev] Opcode cache in ceval loop

On 2016-02-03 3:53 PM, francismb wrote: Hi, On 02/01/2016 10:43 PM, Yury Selivanov wrote: We also need to deoptimize the code to avoid having too many cache misses/pointless cache updates. I found that, for instance, LOAD_ATTR is either super stable (hits 100% of times), or really unstable

Re: [Python-Dev] Opcode cache in ceval loop

On 2016-02-02 1:45 PM, Serhiy Storchaka wrote: On 02.02.16 19:45, Yury Selivanov wrote: On 2016-02-02 12:41 PM, Serhiy Storchaka wrote: On 01.02.16 21:10, Yury Selivanov wrote: To measure the max/average memory impact, I tuned my code to optimize *every* code object on *first* run. Then I

Re: [Python-Dev] Opcode cache in ceval loop

On 2016-02-02 12:41 PM, Serhiy Storchaka wrote: On 01.02.16 21:10, Yury Selivanov wrote: To measure the max/average memory impact, I tuned my code to optimize *every* code object on *first* run. Then I ran the entire Python test suite. Python test suite + standard library both contain

Re: [Python-Dev] Opcode cache in ceval loop

Hi Victor, On 2016-02-02 4:33 AM, Victor Stinner wrote: Hi, Maybe it's worth to write a PEP to summarize all your changes to optimize CPython? It would avoid to have to follow different threads on the mailing lists, different issues on the bug tracker, with external links to GitHub gists, etc.

Re: [Python-Dev] Speeding up CPython 5-10%

entry for every opcode, then the memory usage will raise *significantly*. Right now the overhead of the offset table is *8 bits* per opcode, the overhead of the cache table is *32 bytes* per an optimized opcode. The overhead of using 1 extra indirection is minimal. [..] 2016-01-27 19:25 GMT+01:0

Re: [Python-Dev] Opcode cache in ceval loop

Andrew, On 2016-02-01 4:29 PM, Andrew Barnert wrote: Looking over the thread and the two issues, you've got good arguments for why the improved code will be the most common code, and good benchmarks for various kinds of real-life code, but it doesn't seem like you'd tried to stress it on anyt

Re: [Python-Dev] Opcode cache in ceval loop

Sven, On 2016-02-01 4:32 PM, Sven R. Kunze wrote: On 01.02.2016 22:27, Yury Selivanov wrote: Right now they are private constants in ceval.c. I will (maybe) expose a private API via the _testcapi module to re-define them (set them to 1 or 0), only to write better unittests. I have no plans

Re: [Python-Dev] Opcode cache in ceval loop

On 2016-02-01 3:27 PM, Sven R. Kunze wrote: On 01.02.2016 20:51, Yury Selivanov wrote: If LOAD_ATTR gets too many cache misses (20 in my current patch) it gets deoptimized, and the default implementation is used. So if the code is very dynamic - there's no improvement, but no perfor

Re: [Python-Dev] Opcode cache in ceval loop

On 2016-02-01 3:21 PM, Brett Cannon wrote: On Mon, 1 Feb 2016 at 12:16 Yury Selivanov <mailto:yselivanov...@gmail.com>> wrote: Brett, On 2016-02-01 3:08 PM, Brett Cannon wrote: > > > On Mon, 1 Feb 2016 at 11:51 Yury Selivanov mailto:yseli

Re: [Python-Dev] Opcode cache in ceval loop

On 2016-02-01 4:21 PM, Yury Selivanov wrote: Hi Damien, On 2016-02-01 3:59 PM, Damien George wrote: [..] But then how do you index the cache, do you keep a count of the current opcode number? If I remember correctly, CPython has some opcodes taking 1 byte, and some taking 3 bytes, so the

Re: [Python-Dev] Opcode cache in ceval loop

Brett, On 2016-02-01 3:08 PM, Brett Cannon wrote: On Mon, 1 Feb 2016 at 11:51 Yury Selivanov <mailto:yselivanov...@gmail.com>> wrote: Hi Brett, [..] The first two fields are used to make sure that we have objects of the same type. If it changes, we deoptimize t

Re: [Python-Dev] Opcode cache in ceval loop

Hi Brett, On 2016-02-01 2:30 PM, Brett Cannon wrote: On Mon, 1 Feb 2016 at 11:11 Yury Selivanov <mailto:yselivanov...@gmail.com>> wrote: Hi, [..] What's next? First, I'd like to merge the new LOAD_METHOD opcode, see issue 26110

Re: [Python-Dev] Opcode cache in ceval loop

On 2016-02-01 4:02 PM, Sven R. Kunze wrote: On 01.02.2016 21:35, Yury Selivanov wrote: It's important to understand that if we have a lot of cache misses after the code object was executed 1000 times, it doesn't make sense to keep trying to update that cache. It just means that th

Re: [Python-Dev] Opcode cache in ceval loop

Hi Damien, On 2016-02-01 3:59 PM, Damien George wrote: Hi Yury, That's great news about the speed improvements with the dict offset cache! The cache struct is defined in code.h [2], and is 32 bytes long. When a code object becomes hot, it gets an cache offset table allocated for it (+1 byte f

[Python-Dev] Opcode cache in ceval loop

Hi, This is the second email thread I start regarding implementing an opcode cache in ceval loop. Since my first post on this topic: - I've implemented another optimization (LOAD_ATTR); - I've added detailed statistics mode so that I can "see" how the cache performs and tune it; - some ma

Re: [Python-Dev] Speeding up CPython 5-10%

Hi Brett, On 2016-02-01 12:18 PM, Brett Cannon wrote: On Mon, 1 Feb 2016 at 09:08 Yury Selivanov <mailto:yselivanov...@gmail.com>> wrote: [..] If I were to do some big refactoring of the ceval loop, I'd probably consider implementing a register VM. While register

Re: [Python-Dev] Speeding up CPython 5-10%

On 2016-01-29 11:28 PM, Steven D'Aprano wrote: On Wed, Jan 27, 2016 at 01:25:27PM -0500, Yury Selivanov wrote: Hi, tl;dr The summary is that I have a patch that improves CPython performance up to 5-10% on macro benchmarks. Benchmarks results on Macbook Pro/Mac OS X, desktop CPU/

Re: [Python-Dev] Speeding up CPython 5-10%

Hi Damien, BTW I just saw (and backed!) your new Kickstarter campaign to port MicroPython to ESP8266, good stuff! On 2016-01-29 7:38 AM, Damien George wrote: Hi Yury, [..] Do you use opcode dictionary caching only for LOAD_GLOBAL-like opcodes? Do you have an equivalent of LOAD_FAST, or you u

Re: [Python-Dev] Speeding up CPython 5-10%

On 2016-01-29 5:00 AM, Stefan Behnel wrote: Yury Selivanov schrieb am 27.01.2016 um 19:25: [..] LOAD_METHOD looks at the object on top of the stack, and checks if the name resolves to a method or to a regular attribute. If it's a method, then we push the unbound method object and the o

Re: [Python-Dev] Speeding up CPython 5-10%

On 2016-01-27 3:46 PM, Glenn Linderman wrote: On 1/27/2016 12:37 PM, Yury Selivanov wrote: MicroPython also has dictionary lookup caching, but it's a bit different to your proposal. We do something much simpler: each opcode that has a cache ability (eg LOAD_GLOBAL, STORE_GLOBAL, LOAD

Re: [Python-Dev] Speeding up CPython 5-10%

Damien, On 2016-01-27 4:20 PM, Damien George wrote: Hi Yury, (Sorry for misspelling your name previously!) NP. As long as the first letter is "y" I don't care ;) Yes, we'll need to add CALL_METHOD{_VAR|_KW|etc} opcodes to optimize all kind of method calls. However, I'm not sure how big

Re: [Python-Dev] Speeding up CPython 5-10%

BTW, this optimization also makes some old optimization tricks obsolete. 1. No need to write 'def func(len=len)'. Globals lookups will be fast. 2. No need to save bound methods: obj = [] obj_append = obj.append for _ in range(10**6): obj_append(something) This hand-optimized code would onl

Re: [Python-Dev] Speeding up CPython 5-10%

As Brett suggested, I've just run the benchmarks suite with memory tracking on. The results are here: https://gist.github.com/1st1/1851afb2773526fd7c58 Looks like the memory increase is around 1%. One synthetic micro-benchmark, unpack_sequence, contains hundreds of lines that load a global v

Re: [Python-Dev] Speeding up CPython 5-10%

On 2016-01-27 3:10 PM, Damien George wrote: Hi Yuri, I think these are great ideas to speed up CPython. They are probably the simplest yet most effective ways to get performance improvements in the VM. Thanks! MicroPython has had LOAD_METHOD/CALL_METHOD from the start (inspired by PyPy,

[Python-Dev] Speeding up CPython 5-10%

Hi, tl;dr The summary is that I have a patch that improves CPython performance up to 5-10% on macro benchmarks. Benchmarks results on Macbook Pro/Mac OS X, desktop CPU/Linux, server CPU/Linux are available at [1]. There are no slowdowns that I could reproduce consistently. There are twodi

Re: [Python-Dev] Speeding up CPython 5-10%

On 2016-01-27 3:01 PM, Brett Cannon wrote: [..] We can also optimize LOAD_METHOD. There are high chances, that 'obj' in 'obj.method()' will be of the same type every time we execute the code object. So if we'd have an opcodes cache, LOAD_METHOD could then cache a p

Re: [Python-Dev] PEP 509: Add a private version to dict

On 2016-01-21 3:34 AM, Victor Stinner wrote: [..] But if a global counter doesn't make the slow more complex and opens new kinds of optimization, I agree to change my PEP 509. Please. That would allow us to use ma_version to implement caches in CPython itself. Yury

Re: [Python-Dev] PEP 509: Add a private version to dict

On 2016-01-20 5:01 PM, Greg Ewing wrote: Yury Selivanov wrote: What I propose is to add a pointer "ma_extra" (same 64bits), which will be set to NULL for most dict instances (instead of ma_version). "ma_extra" can then point to a struct that has a globally unique dic

Re: [Python-Dev] PEP 509: Add a private version to dict

On 2016-01-20 8:54 PM, Andrew Barnert via Python-Dev wrote: >I think Glenn was assuming we had a single, global version # that all dicts shared without having a per-dict version ID. The key thing here is that we have a global counter that tracks the number of mutations for all dictionaries bu

Re: [Python-Dev] PEP 509: Add a private version to dict

On 2016-01-20 2:45 PM, Glenn Linderman wrote: For the reuse case, can't you simply keep the ma_version "live" in dict items on the free list, rather than starting over at (presumably) 0 ? Then if the dict is reused, it bumps the ma_version, and the fallback code goes on with (presumably) rel

Re: [Python-Dev] PEP 509: Add a private version to dict

On 2016-01-20 2:09 PM, Maciej Fijalkowski wrote: > You don't free a version tag that's stored in the guard. You store the object and not id Ah, got it. Although for my current cache design it would be more memory efficient to use the dict itself to store its own unique id and tag, hence my

Re: [Python-Dev] PEP 509: Add a private version to dict

On 2016-01-20 2:02 PM, Maciej Fijalkowski wrote: On Wed, Jan 20, 2016 at 8:00 PM, Yury Selivanov wrote: [..] Brett, you need two things - the ID of the dict and the version tag. What we do in pypy is we have a small object (called, surprisingly, VersionTag()) and we use the ID of that. That

Re: [Python-Dev] PEP 509: Add a private version to dict

On 2016-01-20 1:36 PM, Maciej Fijalkowski wrote: On Wed, Jan 20, 2016 at 7:22 PM, Brett Cannon wrote: On Wed, 20 Jan 2016 at 10:11 Yury Selivanov wrote: [..] "ma_extra" would also make it easier for us to extend dicts in the future. Why can't you simply use the id of the

Re: [Python-Dev] PEP 509: Add a private version to dict

Brett, On 2016-01-20 1:22 PM, Brett Cannon wrote: On Wed, 20 Jan 2016 at 10:11 Yury Selivanov <mailto:yselivanov...@gmail.com>> wrote: On 2016-01-18 5:43 PM, Victor Stinner wrote: > Is someone opposed to this PEP 509? > > The main complain was the change on

Re: [Python-Dev] PEP 509: Add a private version to dict

On 2016-01-20 1:15 PM, Maciej Fijalkowski wrote: [..] Anyway, I would strongly suggest getting some benchmarks done and showing performance benefits first, because you don't want PEPs to be final when you don't exactly know the details. I agree 100%. Yury

Re: [Python-Dev] PEP 509: Add a private version to dict

On 2016-01-18 5:43 PM, Victor Stinner wrote: Is someone opposed to this PEP 509? The main complain was the change on the public Python API, but the PEP doesn't change the Python API anymore. I'm not aware of any remaining issue on this PEP. Victor, I've been experimenting with the PEP to imp

Re: [Python-Dev] Update PEP 7 to require curly braces in C

On 2016-01-18 6:20 PM, Brett Cannon wrote: On Sun, 17 Jan 2016 at 11:10 Brett Cannon > wrote: While doing a review of http://bugs.python.org/review/26129/ I asked to have curly braces put around all `if` statement bodies. Serhiy pointed out that PEP 7 sa

Re: [Python-Dev] Update PEP 7 to require curly braces in C

I'm usually fine with code like this: if ( ... ) return But when there is a multi-line 'else' clause, I just want to use braces for both 'if' and its 'else'. So, for consistency, I'm +1 for recommending to use braces everywhere. And +1 for requiring to use braces if one of the c

Re: [Python-Dev] async/await behavior on multiple calls

On 2015-12-16 1:11 AM, Nick Coghlan wrote: On 16 December 2015 at 11:41, Barry Warsaw wrote: The asyncio library documentation *really* needs a good overview and/or tutorial. These are difficult concepts to understand and it seems like bringing experience from other languages may not help (a

Re: [Python-Dev] New poll about a macro for safe reference replacing

Here are names gained the largest numbers of votes plus names proposed during polling. 1. Py_SETREF 2. Py_DECREF_REPLACE 3. Py_REPLACE 4. Py_SET_POINTER 5. Py_SET_ATTR 6. Py_REPLACE_REF I like Py_SETREF, so +1 for it. 0 for other names. Yury ___

Re: [Python-Dev] async/await behavior on multiple calls

On 2015-12-16 12:55 AM, Kevin Conway wrote: I think the list is trying to tell you that awaiting a coro multiple times is simply not a valid case in Python because they are exhaustible resources. In asyncio, they are primarily a helpful mechanism for shipping promises to the Task wrapper. In

Re: [Python-Dev] async/await behavior on multiple calls

Roy, On 2015-12-15 8:29 PM, Roy Williams wrote: [..] My proposal would be to automatically wrap the return value from an `async` function or any object implementing `__await__` in a future with `asyncio.ensure_future()`. This would allow async/await code to behave in a similar manner to oth

Re: [Python-Dev] async/await behavior on multiple calls

Hi Roy and Guido, On 2015-12-15 3:08 PM, Guido van Rossum wrote: [..] I don't know how long you have been using async/await, but I wonder if it's possible that you just haven't gotten used to the typical usage patterns? In particular, your claim "anything that takes an `awaitable` has to kno

[Python-Dev] nested try..except bug in generators

Hi, For anyone interested in tickling the low-level CPython internals (in this case eval loop and generators implementations), here's an interesting bug: http://bugs.python.org/issue25612. I have a patch that fixes it, but I'm not sure that it's correct, and I desperately need someone to review

Re: [Python-Dev] cpython (3.5): whatsnew/3.5: Editorialization pass on library section

On 2015-09-10 6:16 PM, Serhiy Storchaka wrote: On 11.09.15 00:36, yury.selivanov wrote: https://hg.python.org/cpython/rev/3265f33df731 changeset: 97874:3265f33df731 branch: 3.5 parent: 97872:70c97a626c41 user:Yury Selivanov date:Thu Sep 10 17:35:38 2015 -0400

Re: [Python-Dev] What's New editing

On 2015-09-05 2:23 PM, Guido van Rossum wrote: Awesome! We need more people with those skills! --Guido (on mobile) Great, we'll start today! Thanks, Yury ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/

Re: [Python-Dev] What's New editing

On 2015-09-05 1:27 PM, David Mertz wrote: I have to apologize profusely here. Just after I offered to do this (and work even said it was OK in principle to do it on work time), my work load went through the roof. And now it's really already later than most of it should have been done. I'd st

Re: [Python-Dev] What's New editing

On 2015-07-06 11:38 AM, David Mertz wrote: Hi Folks, I hereby volunteer to write "What's New for Python 3.5?" if folks on python-dev are fine with me taking the job (i.e. I ran it by Travis, my boss at Continuum, and he's happy to allow me to do that work within my salaried hours... so havi

Re: [Python-Dev] PEP 498: Literal String Interpolation

On 2015-08-31 9:10 AM, Nick Coghlan wrote: On 30 August 2015 at 23:41, Eric V. Smith wrote: Note there's a companion PEP 501 which extends this idea by delaying converting the expression into a string. This allows for more control over how the expressions are converted in to strings, and allo

Re: [Python-Dev] provisional status for asyncio

Larry, what will the release cycle for 3.5.x look like? Can we do bugfix releases every 3 or 4 months? Yury On 2015-08-29 1:36 PM, Larry Hastings wrote: On 08/28/2015 08:44 AM, Brett Cannon wrote: On Fri, 28 Aug 2015 at 08:35 Yury Selivanov wrote: Unfortunately, separating it from

Re: [Python-Dev] provisional status for asyncio

On 2015-08-28 11:44 AM, Brett Cannon wrote: Unfortunately, separating it from the standard library is something that I don't think we can do so late in the 3.5 release candidates process. Ultimately it's Larry's call, but I don't see why we couldn't. If we were talking about somet

Re: [Python-Dev] provisional status for asyncio

Victor, On 2015-08-28 5:01 AM, Victor Stinner wrote: Hi, 2015-08-27 23:15 GMT+02:00 Yury Selivanov : Recently, in an asyncio related issue [1], Guido said that new features for asyncio have to wait till 3.6, since asyncio is no longer a provisional package. (...) For example, there is an

Re: [Python-Dev] provisional status for asyncio

Brett, On 2015-08-27 6:46 PM, Brett Cannon wrote: [...] I say it's either fully provisional or it's not. I'm fine with extending its provisional status another feature release as long as it clearly states that in What's New for 3.5, but I don't think this granularity guarantee of not breaking

Re: [Python-Dev] provisional status for asyncio

On 2015-08-27 6:44 PM, Guido van Rossum wrote: Maybe asyncio should just be kept provisional during 3.5, with a separate promise to remain backward compatible? I'm +1. I'm also certain that by 3.6.0 we will stabilize asyncio to the point we can freeze it like any other stdlib module. Yury

Re: [Python-Dev] provisional status for asyncio

On 2015-08-27 5:53 PM, Brett Cannon wrote: Considering that Python versioning is defined as major.minor.micro, I'll rephrase the proposal: Level 1: Backwards incompatible changes might be introduced in new Python releases (including micro releases) Level 2: Only backwa

Re: [Python-Dev] provisional status for asyncio

On 2015-08-27 5:31 PM, Yury Selivanov wrote: On 2015-08-27 5:24 PM, Brett Cannon wrote: My proposal is to amend PEP 411 with two levels of provisional packages: Level 1: Backwards incompatible changes might be introduced in point releases. Level 2: Only backwards

<    1   2   3   4   5   6   >