[issue40255] Fixing Copy on Writes from reference counting

Rémi Lapeyre added the comment: >> We also have the real world app that is Instagram. > I don't think Instagram is a single app. What is Python used for at Instagram? According to their engineering blog

[issue40255] Fixing Copy on Writes from reference counting

Antoine Pitrou added the comment: > We also have the real world app that is Instagram. I don't think Instagram is a single app. What is Python used for at Instagram? -- ___ Python tracker

[issue40255] Fixing Copy on Writes from reference counting

Steve Dower added the comment: > But micro-benchmarks may tell you things which are not true in the real-world > (for example an easily-predicted branch) This is true, though this branch should be more easily predictable because INCREF/DECREF are inlined. If there were only one function

[issue40255] Fixing Copy on Writes from reference counting

Antoine Pitrou added the comment: > Benchmarking already showed that the branching version is faster. But micro-benchmarks may tell you things which are not true in the real-world (for example an easily-predicted branch). -- ___ Python tracker

[issue40255] Fixing Copy on Writes from reference counting

Steve Dower added the comment: > I would expect that the negative impact on branch predictability would easily > outweigh the cost of the memory write (A guaranteed L1 hit) If that were true then Spectre and Meltdown wouldn't have been so interesting :) Pipelining processors are going to

[issue40255] Fixing Copy on Writes from reference counting

Mark Shannon added the comment: Eddie, How did you compare the branching vs. non-branching implementations? I have read the code in the PR. What is the non-branching version that you used to compare it against? Why not use the sign bit as the immortal bit? It simplifies the test

[issue40255] Fixing Copy on Writes from reference counting

Neil Schemenauer added the comment: I resurrected an old thread on Discourse that seems quite relevant to this PR: https://discuss.python.org/t/switching-from-refcounting-to-libgc/1641/35?u=nas -- ___ Python tracker

[issue40255] Fixing Copy on Writes from reference counting

Neil Schemenauer added the comment: > immutability vs immutable object headers Sorry, I meant to write "immortal vs immutable". -- ___ Python tracker ___

[issue40255] Fixing Copy on Writes from reference counting

R is about opting-out of the default Python reference counting. Put that way, could we consider this PR as an incremental step in a process of making it possible to have a non-reference count based GC for CPython? E.g. perhaps we could eventually have a mixture of mark-and-sweep and reference

[issue40255] Fixing Copy on Writes from reference counting

Eddie Elizondo added the comment: > which would potentially save the two word per object overhead Btw, I misread. I thought `gc_bits` referred to the bits used by the GC in the reference count. In any case, you can still use a bit in the reference co

[issue40255] Fixing Copy on Writes from reference counting

Eddie Elizondo added the comment: > I'm somewhat puzzled how a version that does no more work and has no jumps is > slower. Oh I think I know why there's some confusion. I've updated the PR from the initial version (which is probably the one that you saw). The branching does less work in

[issue40255] Fixing Copy on Writes from reference counting

Mark Shannon added the comment: Do you have more details on your comparison? I'm somewhat puzzled how a version that does no more work and has no jumps is slower. The memory hit is not immediate, but making the object header immutable prevents changes like

[issue40255] Fixing Copy on Writes from reference counting

only one reference to copy-on-write in a comment. Yet this issue > about making object headers immutable. The PR summary expands on Copy on Writes. If you think this belongs in-code, let me know and I can update the PR. > then make the obvious improvement of changing the branchy code T

[issue40255] Fixing Copy on Writes from reference counting

Mark Shannon added the comment: A big -1 to this. You are asking the whole world to take a hit on both performance and memory use, in order to save Instagram memory. The PR uses the term "immortal" everywhere. There is only one reference to copy-on-write in a comment. Yet this i

[issue40255] Fixing Copy on Writes from reference counting

Eddie Elizondo added the comment: After the added optimizations and assuming that running this more rigorously (i.e PGO + LTO + full cpu isolation + speed.python.org machine) also shows the PR as perf neutral, what are people's thoughts so far? Would this be enough to consider adding this

[issue40255] Fixing Copy on Writes from reference counting

rom what you mentioned. I was mostly concerned about having a small object that we did not reach through the GC roots. If this small object would get a reference count bump, the whole arena would Copy on Write. I added a commit to the PR with this Arena Immortalization so that you could

[issue40255] Fixing Copy on Writes from reference counting

Eddie Elizondo added the comment: I was able to get an equal (maybe slightly better) performance by following the advice from Steve and Neil and skipping reference counting of instances that we know are immortal. It seems that by getting performance parity, we should be able to ease most

[issue40255] Fixing Copy on Writes from reference counting

Carl Meyer added the comment: Makes sense. Yes, caution is required about what code runs before fork, but forkserver’s solution for that would be a non-starter for us, since it would ensure that we can share no basically no memory at all between worker processes. --

[issue40255] Fixing Copy on Writes from reference counting

Antoine Pitrou added the comment: Steve is right. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40255] Fixing Copy on Writes from reference counting

Steve Dower added the comment: > What problem do you have in mind that the fork server would solve? My understanding is that the fork server solves the *general* problem of running arbitrary code before fork by making sure that only CPython/multiprocessing gets to run code before fork. In

[issue40255] Fixing Copy on Writes from reference counting

Carl Meyer added the comment: > I would be interested to hear the answer to Antoine's question which is > basically: why not using the multiprocessing fork server? Concretely, because for a long time we have used the uWSGI application server and it manages forking worker processes (among

[issue40255] Fixing Copy on Writes from reference counting

Neil Schemenauer added the comment: Eddie mentions in the PR about using memory arenas to contain immortal objects. I think it could be worth investigating further. With the current PR, the immortal status is dependent on the value of the refcnt field of the object. Using immortal arenas

[issue40255] Fixing Copy on Writes from reference counting

Antoine Pitrou added the comment: I'll note that this "extremely common" model can break as soon as you have hidden worker threads somewhere (this can happen in a third-party library). For example, the libhdfs library is not fork-safe. -- ___

[issue40255] Fixing Copy on Writes from reference counting

STINNER Victor added the comment: Carl: > A lot of the "big data" in question here is simply lots of Python > module/class/code objects resulting from importing lots of Python modules. > > And yes, this "pre-fork" model is extremely common for serving Python web > applications; it is the way

[issue40255] Fixing Copy on Writes from reference counting

Carl Meyer added the comment: > Is it a common use case to load big data and then fork to use preloaded data? A lot of the "big data" in question here is simply lots of Python module/class/code objects resulting from importing lots of Python modules. And yes, this "pre-fork" model is

[issue40255] Fixing Copy on Writes from reference counting

STINNER Victor added the comment: This feature seems to be driven by Instagram use case. Are there other users who would benefit of that? Is it a common use case to load big data and then fork to use preloaded data? PR 19474 has a maintenance cost: * new configuration option * new macro *

[issue40255] Fixing Copy on Writes from reference counting

as confusing me in this line of reasoning is that I was not taking into account that the immortal bit is a very high one, making the refcount gigantic. I was treating it mentally like a flag without factoring the implications of such big reference count. --

[issue40255] Fixing Copy on Writes from reference counting

cts (isolated and untracked before and now tracked) acquire > strong references to immortal objects, those objects will be visited when the > gc starts calculating the isolated cycles and that requires a balanced > reference count to work. I'm not sure what you mean here by "balanced ref

[issue40255] Fixing Copy on Writes from reference counting

Pablo Galindo Salgado added the comment: > But if said objects (isolated and untracked before and now tracked) acquire > strong references to immortal objects, those objects will be visited when the > gc starts calculating the isolated cycles and that requires a balanced > ref

[issue40255] Fixing Copy on Writes from reference counting

die within N hours or days. Memory leaks of too many things persisting is a non-issue in this kind of system. The alternative of trying to pick and choose exactly what (and anything they reference) sticks around is a maintenance nightmare exercise in futi

[issue40255] Fixing Copy on Writes from reference counting

Pablo Galindo Salgado added the comment: > all objects that are tracked by the gc also, all the objects that are reachable from objects tracked by the gc. -- ___ Python tracker

[issue40255] Fixing Copy on Writes from reference counting

Pablo Galindo Salgado added the comment: > There hasn't been much said about which kind of objects would be immortal. The current patch makes *all objects that are tracked by the gc* immortal, independently of their type (unless I am missing something). --

[issue40255] Fixing Copy on Writes from reference counting

Change by Steve Dower : -- nosy: +dino.viehland ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40255] Fixing Copy on Writes from reference counting

Steve Dower added the comment: There hasn't been much said about which kind of objects would be immortal. Could this be a creation-time option? Or a type object (similar to a no-op tp_dealloc)? If it's something that is known when the object is created, then some of the "infection" concern

[issue40255] Fixing Copy on Writes from reference counting

ell: I am saying that I perceive this as a problem because when you immortalize the heap at a given time you will also immortalize any strong reference that these objects made afterwards. The immortal property will be "infecting" other objects as strong references are created. > I t

[issue40255] Fixing Copy on Writes from reference counting

Dino Viehland added the comment: I think there's other cases of performance related features being hidden under an ifdef. Computed gotos show up that way, although probably more because it's a compiler extension that's not supported everywhere. Pymalloc is also very similar in that it

[issue40255] Fixing Copy on Writes from reference counting

Carl Meyer added the comment: > This may break the garbage collector algorithm that relies on the balance > between strong references between objects and its reference count to do the > calculation of the isolated cycles. I don't think it really breaks anything. Wha

[issue40255] Fixing Copy on Writes from reference counting

Carl Meyer added the comment: > An immortalized object will never start participating in reference counting > again after it is immortalized. Well, "passed to an extension compiled with no-immortal headers" is an exception to this. But for the "not GC tracked but lat

[issue40255] Fixing Copy on Writes from reference counting

Carl Meyer added the comment: > Anything that is touched by the immortal object will be leaked. This can also > happen in obscure ways if reference cycles are created. I think this is simply expected behavior if you choose to create immortal objects, and not really an issue. How cou

[issue40255] Fixing Copy on Writes from reference counting

Antoine Pitrou added the comment: As a separate discussion, I would be interested to know whether the original use case (Eddie's) could be satisfied differently. It probably doesn't belong to this issue, though. (Eddie, if you want to discuss this, feel free to e-mail me privately. I think

[issue40255] Fixing Copy on Writes from reference counting

Antoine Pitrou added the comment: > I run the pyperformance test suite with PGO + LTO + full cpu isolation in the > speed.python.org machine and these were the results: Be mindful that synthetic benchmarks are probably a gentle case for branch prediction. Real-world performance on

[issue40255] Fixing Copy on Writes from reference counting

Steve Dower added the comment: >> This isn't actually about removing immortal objects, but removing *mutable* >> objects that would be shared between subinterpreters. Making some objects >> immortal, such as interned strings or stateless singletons, would actually >> benefit this work, as they

[issue40255] Fixing Copy on Writes from reference counting

Change by hai shi : -- nosy: +shihai1991 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40255] Fixing Copy on Writes from reference counting

STINNER Victor added the comment: I would be more interested by an experiment to move ob_refcnt outside PyObject to solve the Copy-on-Write issue, especially to measure the impact on performances. -- ___ Python tracker

[issue40255] Fixing Copy on Writes from reference counting

the GC so the only leaks are cycle-based. With this patch immortal object will leak every strong reference that they have even if they don't participate in cycles (but also if they participate in cycles). -- ___ Python tracker <https://bugs.p

[issue40255] Fixing Copy on Writes from reference counting

ng_silent or unpickle_pure_python is a very expensive price :-( Pablo: > Anything that is touched by the immortal object will be leaked. This can also > happen in obscure ways if reference cycles are created. gc.freeze() has a similar issue, no? This function also comes from Instagram sp

[issue40255] Fixing Copy on Writes from reference counting

Steve Dower added the comment: > There is a trend right now to try to remove immortal objects (started by > Victor and others) like static types and transforming them to heap types. This isn't actually about removing immortal objects, but removing *mutable* objects that would be shared

[issue40255] Fixing Copy on Writes from reference counting

Pablo Galindo Salgado added the comment: > If it's easy to set up, it might be interesting to see if there's a > difference if (e.g.) all interned strings are marked as immortal, or all > small ints. Or type objects. Maybe set a flag during initialization and treat > everything created

[issue40255] Fixing Copy on Writes from reference counting

that we add conditional compilation, here are some of the things I feel uneasy about: - Anything that is touched by the immortal object will be leaked. This can also happen in obscure ways if reference cycles are created. - As Eddie mentions in the PR, this does not fully cover all cases

[issue40255] Fixing Copy on Writes from reference counting

Steve Dower added the comment: If it's easy to set up, it might be interesting to see if there's a difference if (e.g.) all interned strings are marked as immortal, or all small ints. Or type objects. Maybe set a flag during initialization and treat everything created before that as

[issue40255] Fixing Copy on Writes from reference counting

Pablo Galindo Salgado added the comment: System state CPU: use 12 logical CPUs: 1,3,5,7,9,11,13,15,17,19,21,23 Perf event: Maximum sample rate: 1 per second ASLR: Full randomization Linux scheduler: Isolated CPUs (12/24): 1,3,5,7,9,11,13,15,17,19,21,23 Linux scheduler: RCU

[issue40255] Fixing Copy on Writes from reference counting

Pablo Galindo Salgado added the comment: I run the pyperformance test suite with PGO + LTO + full cpu isolation in the speed.python.org machine and these were the results: +-+--+---+ | Benchmark

[issue40255] Fixing Copy on Writes from reference counting

Change by Steve Dower : -- nosy: +steve.dower ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40255] Fixing Copy on Writes from reference counting

Change by Dong-hee Na : -- nosy: +corona10 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40255] Fixing Copy on Writes from reference counting

he python performance test suite > should Agreed. I only added the Richards benchmark as a reference. I'm hoping someone can pick it up and have more concrete numbers on an average Python workload. > Given that most people's applications don't fork workers, I do not expect to > see such an i

[issue40255] Fixing Copy on Writes from reference counting

Gregory P. Smith added the comment: Thanks for sharing! It's good to have a patch implementing for others who might need it to try out. We experimented with an implementation of this on CPython 2.7 that we called Eternal Refcounts for YouTube many years ago. For the same reason (saving

[issue40255] Fixing Copy on Writes from reference counting

Change by Dong-hee Na : -- nosy: +pablogsal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40255] Fixing Copy on Writes from reference counting

Change by Pablo Galindo Salgado : -- nosy: +nascheme, pitrou, tim.peters ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue40255] Fixing Copy on Writes from reference counting

Change by Eddie Elizondo : -- keywords: +patch pull_requests: +18829 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19474 ___ Python tracker ___

[issue40255] Fixing Copy on Writes from reference counting

New submission from Eddie Elizondo : Copy on writes are a big problem in large Python application that rely on multiple processes sharing the same memory. With the implementation of `gc.freeze`, we've attenuated the problem by removing the CoW coming from the GC Head. However, reference

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Pablo Galindo Salgado added the comment: Sorry when I said: > If we do the same experiment after PR19314: I meant: If we do the same experiment after PR 19414: -- ___ Python tracker

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

gt; sys.getrefcount(x) 6 # We know that now there should be a link between new_obj and x because one points to the other >>> x in gc.get_referents(new_obj) False # Oh no, there is no link >>> class A: ...def __del__(self): ... print("Ouch") ... >>&

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Pablo Galindo Salgado added the comment: In https://github.com/python/cpython/pull/19414 I have attached a proof of concept of a wrapper for tp_traverse that only affects types created by PyType_FromSpec that will call Py_VISIT(Py_TYPE(self)) and then the user function. --

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +18774 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19414 ___ Python tracker

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Pablo Galindo Salgado added the comment: > Now we changed rules. A strong reference is created implicitly. Who is > responsible to manage a strong reference? Whose who created it, ant it is the > interpreter, not the user. Even if we decide that the patch that introduced the

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Serhiy Storchaka added the comment: The problem is that we suddenly changed rules. It was not required that the object's type should be visited in tp_visit. It was incorrect to visit it, because object did not have strong reference to its type. User never created it, and it was not created

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Pablo Galindo Salgado added the comment: > We cannot change all user code, so we should change the interpreter code so > that it will work correctly with existing user code. If we made a change that make all user code suddenly incorrect, that change should be reverted. The GC has clear

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Serhiy Storchaka added the comment: Recently many static allocated types were converted to heap allocated types (using PyType_FromSpec). Now you need to add Py_VISIT(Py_TYPE(self)) in all corresponding tp_visit implementations. And since even official example for heap allocated types do not

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Pablo Galindo Salgado added the comment: > Hummm, I think we may just be missing a Py_VISIT(Py_TYPE(self))here: Checking it more closely, that is incorrect, so we are not missing that visitation :( -- ___ Python tracker

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Pablo Galindo Salgado added the comment: Hummm, I think we may just be missing a Py_VISIT(Py_TYPE(self))here: https://github.com/python/cpython/blob/master/Objects/typeobject.c#L3562 A class owns references to its type (type) or another metaclass Tim, could you confirm that that is the

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Pablo Galindo Salgado added the comment: Also, as I mentioned, you don't need to modify all objects tp_traverse, only it's type.tp_traverse slot. For instance, all python objects know how to traverse stuff because they share the same tp_traverse:

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Serhiy Storchaka added the comment: Interesting, this issue may be related to issue24379. The problem with the proposed implementation of subscript was that it created a reference loop, and not all links in this loop were visible by GC

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

why these functions do not visit the type if they own s reference to it, this looks incorrect" and then we need to explain that that is an exception in the GC just because we were lazy to implement them correctly. -- ___ Python tracker <htt

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Serhiy Storchaka added the comment: It would be inconvenient to require adding Py_VISIT(Py_TYPE(self)) in all tp_visit implementations of heap allocated types (including third-party extensions). Since tp_visit is GC specific thing, I think it wold be more convenient make a special case for

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Tim Peters added the comment: If object A owns a strong reference to object B, and A participates in cyclic gc, and B may be part of a cycle, then it's necessary and sufficient that A's type's tp_traverse implementation invoke Py_VISIT() passing A's pointer to B. It would be a Really Bad

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Pablo Galindo Salgado added the comment: Also, heap types (created with type_new()) are already taking into account the type when visiting references: https://github.com/python/cpython/blob/master/Objects/typeobject.c#L -- ___ Python tracker

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Pablo Galindo Salgado added the comment: > I propose to modify the GC to take bpo-35810 in account. What? The GC is agnostic of what it receives. It works with objects in general that implement the gc support, but it does not care about what those objects are. The only specal case are

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Change by hai shi : -- nosy: +shihai1991 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

Change by Dong-hee Na : -- nosy: +corona10 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

New submission from STINNER Victor : The bpo-35810 modified the object allocate to hold a *strong* reference to the type in PyObject.ob_type, whereas PyObject.ob_type is a *borrowed* references if the type is statically allocated. commit 364f0b0f19cc3f0d5e63f571ec9163cf41c62958 Author: Eddie

[issue40177] Python Language Reference Documentation

Mark Dickinson added the comment: Thanks for the report! Now fixed. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: enhancement -> behavior ___ Python tracker

[issue40177] Python Language Reference Documentation

Change by miss-islington : -- pull_requests: +18747 pull_request: https://github.com/python/cpython/pull/19384 ___ Python tracker ___

[issue40177] Python Language Reference Documentation

Change by miss-islington : -- nosy: +miss-islington nosy_count: 6.0 -> 7.0 pull_requests: +18746 pull_request: https://github.com/python/cpython/pull/19383 ___ Python tracker

[issue40177] Python Language Reference Documentation

Change by Mark Dickinson : -- keywords: +patch pull_requests: +18718 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19357 ___ Python tracker ___

[issue40177] Python Language Reference Documentation

Steven D'Aprano added the comment: Oh never mind, I'm just going to slink away now and stop posting corrections when distracted... -- ___ Python tracker ___

[issue40177] Python Language Reference Documentation

Steven D'Aprano added the comment: Oops, that should be ... ``x == x``, ``3 < x``, and ``x > 3`` are all false ... -- ___ Python tracker ___

[issue40177] Python Language Reference Documentation

Steven D'Aprano added the comment: How about this? "The not-a-number values ``float('NaN')`` and ``decimal.Decimal('NaN')`` are special. Not-a-number values always compare unordered and unequal to any other value, including themselves. For example, if ``x = float('NaN')``, then ``x == x``,

[issue40177] Python Language Reference Documentation

Change by Karthikeyan Singaravelan : -- nosy: +mark.dickinson, rhettinger, stutzbach ___ Python tracker ___ ___ Python-bugs-list

[issue40177] Python Language Reference Documentation

New submission from Arnuld : In section "6.10.1 Value comparisons", it is written: https://docs.python.org/3/reference/expressions.html "The not-a-number values float('NaN') and decimal.Decimal('NaN') are special. Any ordered comparison of a number to a not-a-number value is f

[issue39879] Update language reference to specify that dict is insertion-ordered.

STINNER Victor added the comment: What's New in Python 3.7 says: > the insertion-order preservation nature of dict objects has been declared to > be an official part of the Python language spec. Reference: https://mail.python.org/pipermail/python-dev/2017-December/151283.html

[issue39879] Update language reference to specify that dict is insertion-ordered.

Zachary Ware added the comment: Thanks for the patch! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue39879] Update language reference to specify that dict is insertion-ordered.

miss-islington added the comment: New changeset 96686c761d0587080effc113367431a0d396eb45 by Miss Islington (bot) in branch '3.8': bpo-39879: Update datamodel docs to include dict ordering (GH-19006) https://github.com/python/cpython/commit/96686c761d0587080effc113367431a0d396eb45

[issue39879] Update language reference to specify that dict is insertion-ordered.

miss-islington added the comment: New changeset ea0eeb8d3a0544334f8836c98a761b2e3df2bd94 by Miss Islington (bot) in branch '3.7': bpo-39879: Update datamodel docs to include dict ordering (GH-19006) https://github.com/python/cpython/commit/ea0eeb8d3a0544334f8836c98a761b2e3df2bd94

[issue39879] Update language reference to specify that dict is insertion-ordered.

Change by miss-islington : -- pull_requests: +18534 pull_request: https://github.com/python/cpython/pull/19174 ___ Python tracker ___

[issue39879] Update language reference to specify that dict is insertion-ordered.

Change by miss-islington : -- nosy: +miss-islington nosy_count: 6.0 -> 7.0 pull_requests: +18533 pull_request: https://github.com/python/cpython/pull/19173 ___ Python tracker

[issue39879] Update language reference to specify that dict is insertion-ordered.

Zachary Ware added the comment: New changeset 59c644eaa72b0cc48302f59d66852c4ea8332eba by Lahfa Samy in branch 'master': bpo-39879: Update datamodel docs to include dict ordering (GH-19006) https://github.com/python/cpython/commit/59c644eaa72b0cc48302f59d66852c4ea8332eba --

[issue39879] Update language reference to specify that dict is insertion-ordered.

Lahfa Samy added the comment: Thank you for your quick work, I have successfully merged your changes in the branch of the first PR, now awaiting review from Zachary. -- ___ Python tracker

[issue39879] Update language reference to specify that dict is insertion-ordered.

Furkan Önder added the comment: Hello Samy, I sent you pr from the docs-dict-ordered branch in your cpython repository. Now both of us have merged pr. I closed my own pr. You can also close your pr and send these changes again as bpo-39879. It's my

[issue39879] Update language reference to specify that dict is insertion-ordered.

Lahfa Samy added the comment: Hi Furkan, would you mind to combine your revised PR with mine so that we can do as suggested by Zachary? -- ___ Python tracker ___

[issue39879] Update language reference to specify that dict is insertion-ordered.

Zachary Ware added the comment: Hi Furkan. Please note that Lahfa Samy had already submitted a PR for this issue after "claiming" it with a note here; proper "netiquette" suggests not jumping in with your own PR in such a situation. Fortuitously though, it looks like the both of you have

<    1   2   3   4   5   6   7   8   9   10   >