Re: [Python-ideas] Revisiting str.rreplace()
I starting g reading this thread in the middle, on a phone. But was very confused for a while because I didn’t notice that there were two ‘r’s at the beginning of .rreplace Just sayin’ -CHB Sent from my iPhone > On Jul 19, 2018, at 9:29 AM, Paul Moore wrote: > >> On 19 July 2018 at 16:25, Eric V. Smith wrote: >> It currently does something: it replaces all instances, just as if you >> hadn't supplied a count (see my example below). You can't change its >> behavior. > > ... without a deprecation cycle. Which is of course not worth it for > something which could much more easily be done by adding an rreplace > function - which is the real point of the comment. > Paul > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 505: None-aware operators
On Sun, Jul 22, 2018 at 11:54 AM, Steven D'Aprano wrote: > If we gained a function > or even a keyword from Italian, let's say "ripetere", would that really > change the nature of Python? I don't think so. English speakers are > adaptable, we don't so much borrow words from other languages as chase > them down the alley and mug them for new vocabulary. "lambda" would like to have a word with you. Or maybe a letter. I'm not really sure. ChrisA ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 505: None-aware operators
On Sun, Jul 22, 2018 at 01:56:35AM +0200, Giampaolo Rodola' wrote:
> On Thu, Jul 19, 2018 at 3:39 PM Steven D'Aprano wrote:
> > Tens of thousands of non-English speakers have had to learn the meaning
> > of what might as well be meaningless, random sets of symbols (to them)
> > like "class", "import", "while" and "True". If they can do so, perhaps
> > we English-speakers should stop complaining about how hard it is to
> > memorise the meaning of a couple of symbols like ??.
>
> "class", "import", "while" and "True" are keywords, not symbols.
They are only key WORDS if you are an English speaker. If your language
doesn't use the Latin script, they don't even look like words. They look
like gibberish: ∌≇⊅∇∫
> A symbol is more cryptic than a keyword
I was using "symbol" in its most general sense, "a visible sign or
representation of an idea". Words, letters, icons, emblems etc are all
symbols. Sorry for being unclear.
> hence it comes at a higher cost in terms of readability.
It is not clear to me that this is always true even when it comes to
non-word symbols. I don't think that "+" is harder to read than
"standard_mathematics_operators_numeric_addition" for example.
It is possible to be too verbose as well as too terse. This is why we
aren't copying COBOL.
> which is the reason why conditionals use
> keywords instead symbols:
>
> - we say "and" instead of "&&"
[...]
Indeed we do. But we also say:
- we say "+" instead of "add"
- we say "//" instead of "floor division"
- we say "**" instead of "exponentiation"
- we say "&" instead of "bitwise AND"
- we say "f( ... )" instead of "call f with arguments ..."
etc. Python has no shortage of non-word symbols:
== != ~ - + * ** / // @ % ^ & | << >> < <= > >= [] ()
[...]
> > *Its just spelling*. If it is a useful and well-defined feature, we'll
> > get used to the spelling soon enough.
>
> Such an argument may apply to other languages but not Python.
I disagree. I think it applies equally to Python. Python functions and
keywords are usually English words, but not always:
def elif
have to be memorised even by English speakers. If we gained a function
or even a keyword from Italian, let's say "ripetere", would that really
change the nature of Python? I don't think so. English speakers are
adaptable, we don't so much borrow words from other languages as chase
them down the alley and mug them for new vocabulary.
The same applies to non-word symbols. Look at how quickly and easily
people adapted to @ (the commercial "at" sign, a variation of
multiplication) as a separator in emails, not to mention #hashtags.
I'll admit that the number and variety of new operators gives me some
reason to pause, but for the simplest and most obvious case, the
proposed ?? operator, I think that the fears about readability are
grossly exaggerated.
> The philosophy of the language is all about readability and beauty since
> day 1, and the main reason why Python got so successful despite being
> slow.
Let's talk about Python's readability: the first time I saw Python code,
I had *no idea* how to read it. This was Python 1.5, long before
comprehensions, @ decorator syntax, etc. I could read Pascal, Forth,
Hypertalk, BASIC and Fortran, and I looked at Python and couldn't make
heads or tails of it. It was full of cryptic idioms like:
for i in range(len(sequence))
which is meaningless until you learn what range does and learn to read
it as a for loop:
for i = 0 to len(sequence) - 1
And as for slice notation:
suffix = word[n:]
that might as well have been advanced quantum mechanics transliterated
into Korean by a native Navaho speaker for all I could read it. I knew
round brackets were used for function calls f() but the only experience
I had with square and curly brackets was in mathematics, where they are
used as second and third levels of brackets:
x = {[a (b+1)][b (a - 1)] - 1}/2
Now *that* I understood. What on earth was this mysterious {'a': 1}
syntax that I keep seeing in Python code?
My initial experience with this bizarre, cryptic language Python was so
off-putting that I put it aside for literally three or four years before
coming back to it.
Of course I believe that Python is, generally speaking, a beautiful and
elegant language, extremely readable. But readability doesn't exist in a
vacuum. We still need to learn the symbols of the language, not just
operators like ** % and // but words as well. To appreciate the elegance
of the language, we need to know the common idioms, as well as the
semantics of keywords and functions.
Unfortunately, ?? does have one disadvantage: even though it is used as
an operator in a number of languages, Google doesn't seem to have
indexed it. Goggling for "??" is unhelpful. But then googling for "@
python" is similarly unhelpful. Clearly decorators was a mistake. /s
> That's why we have mandatory indentation, to say one. We don't
> *have to* get used to idioms
Re: [Python-ideas] PEP 505: None-aware operators
On Thu, Jul 19, 2018 at 3:39 PM Steven D'Aprano wrote: > Tens of thousands of non-English speakers have had to learn the meaning > of what might as well be meaningless, random sets of symbols (to them) > like "class", "import", "while" and "True". If they can do so, perhaps > we English-speakers should stop complaining about how hard it is to > memorise the meaning of a couple of symbols like ??. "class", "import", "while" and "True" are keywords, not symbols. A symbol is more cryptic than a keyword hence it comes at a higher cost in terms of readability. Which is the reason why conditionals use keywords instead symbols: - we say "and" instead of "&&" - we say "or" instead of "||" - we say "not" instead of "!" - we say "is" instead of "===" AFAICT "?" would be the first one breaking this rule for conditionals [1], and not only for them since it can also arbitrarily appear in non-conditionals (x.?y). [1] I know, we say "==" instead of "equal" and "!=" instead of "different" but the equal sign implies an equality. "?" does not imply "None-ness": it's arbitrary. Furthermore "==" and "!=" are much more common than testing for "None", hence they have more reason to exist. > Surely its no more > difficult than learning the various meanings of ** and [] which we've > already done. It is more difficult if you consider that ? has different spellings (?, ??, a?.b, ??=, ...), each spelling with a different meaning. > *Its just spelling*. If it is a useful and well-defined feature, we'll > get used to the spelling soon enough. Such an argument may apply to other languages but not Python. The philosophy of the language is all about readability and beauty since day 1, and the main reason why Python got so successful despite being slow. That's why we have mandatory indentation, to say one. We don't *have to* get used to idioms which can decrease readability. When we do there must be a good reason and the spelling should matter (I remember the debates about decorators' syntax). -- Giampaolo - http://grodola.blogspot.com ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] if we were to ever shorten `A if A else B` (was: PEP 505: None-aware operators)
Coming from the @ side (I was strong +1 on this), I have troubles seeing the real benefits from ?? (And even more from associates): did we really have long and complex expressions where the compactness of an operator would help? Operators are inherently obscure (except for those that are learnt in elementary school), but they help when you combine multiple operators and benefit from their precedence rules. There you can benefit from them, even if explicit it's better than implicit... It was the case for @, and even with proofs of long formulas, and a history of matrix algebra from hundreds of years before computing science, the resistance was strong: a majority of non-numpy users resisted it, saying a function matmul(A,B) was good enough and A@B would bring nothing. It was eventually accepted, 7 or so years after the initial proposal, through another PEP, when relative weight of numpy community was probably larger. So i'd like to see examples of long expressions that would really benefit groin using an very specific operator. At this point, the explicitness of "a if a is not None else []" wins, by a long shot...___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Performance improvements via static typing
On Fri, Jul 20, 2018, 02:33 Stefan Behnel, wrote:
> Michael Hall schrieb am 19.07.2018 um 15:51:
> > While I am aware of projects like Cython and mypy, it seems to make sense
> > for CPython to allow optional enforcement of type hints, with compiler
> > optimizations related to it to be used. While this would not receive the
> > same level of performance benefits as using ctypes directly, there do
> > appear to be various gains available here.
>
> Well, first of all, a C level type check at runtime is quite fast compared
> to a byte code dispatch with stack argument handling, and can be done
> regardless of any type hints. There are various code patterns that would
> suggest a certain type ("x.append()" probably appends to a list, "x.get()"
> will likely be a dict lookup, etc.), and that can be optimised for without
> static type declarations and even without any type hints.
>
> Then, the mere fact that user code says "a: List" does not help in any way.
> Even "a: list" would not help, because any behaviour of that "list" might
> have been overridden by the list subtype that the function eventually
> receives.
>
> The same applies to "x: float". Here, in order to gain speed, the compiler
> would have to generate two separate code paths through the entire function,
> one for C double computations, and one for Python float subtypes. And then
> exponentiate that by the number of other typed arguments that may or may
> not contain subtypes. Quite some overhead.
>
> It's unclear if the gain would have any reasonable relation to the effort
> in the end. Sure, type hints could be used as a bare trigger for certain
> optimistic optimisations, but then, it's cheap enough to always apply these
> optimisations regardless, via a C type check.
>
I'll also mention that my masters thesis disproved the benefit of
type-specific opcodes for CPython:
https://scholar.google.com/scholar?cluster=2007053175643839734=en_sdt=0,5=0,5
What this means is someone will have to demonstrate actual performance
benefits before we talk about semantic changes or modifying the
interpreter. IOW don't prematurely optimize for an optimization until it's
actually been proven to be an optimization.
> Stefan
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Performance improvements via static typing
A note here:
Earlier in the conversation about standardizing type hinting, I (among
others) was interested in applying it to C-level static typing (e.g.
Cython).
Guido made it very clear that that was NOT a goal of type hints —
rather, they were to be used for dynamic, python style types — so a
“list” is guaranteed to act like a list in python code, but not to
have the same underlying binary representation.
We could still use the same syntax for things like Cython, but they
would have a different meaning.
And a JIT compiler may not benefit from the hints at all, as it would
have to check the actual type at run-time anyway.
-CHB
Sent from my iPhone
> On Jul 20, 2018, at 2:32 AM, Stefan Behnel wrote:
>
> Michael Hall schrieb am 19.07.2018 um 15:51:
>> While I am aware of projects like Cython and mypy, it seems to make sense
>> for CPython to allow optional enforcement of type hints, with compiler
>> optimizations related to it to be used. While this would not receive the
>> same level of performance benefits as using ctypes directly, there do
>> appear to be various gains available here.
>
> Well, first of all, a C level type check at runtime is quite fast compared
> to a byte code dispatch with stack argument handling, and can be done
> regardless of any type hints. There are various code patterns that would
> suggest a certain type ("x.append()" probably appends to a list, "x.get()"
> will likely be a dict lookup, etc.), and that can be optimised for without
> static type declarations and even without any type hints.
>
> Then, the mere fact that user code says "a: List" does not help in any way.
> Even "a: list" would not help, because any behaviour of that "list" might
> have been overridden by the list subtype that the function eventually
> receives.
>
> The same applies to "x: float". Here, in order to gain speed, the compiler
> would have to generate two separate code paths through the entire function,
> one for C double computations, and one for Python float subtypes. And then
> exponentiate that by the number of other typed arguments that may or may
> not contain subtypes. Quite some overhead.
>
> It's unclear if the gain would have any reasonable relation to the effort
> in the end. Sure, type hints could be used as a bare trigger for certain
> optimistic optimisations, but then, it's cheap enough to always apply these
> optimisations regardless, via a C type check.
>
> Stefan
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Multi-core reference count garbage collection
> You wrote: > > I'd argue that the ref counts are not interesting at all, only a > > side effect of one possible solution to the object life time problem. > > I'm happy for you to regard multi-core reference counting (MCRC) as a toy > problem, which won't become part of useful software. Perhaps the point was that reference counting is only one of the issues (race conditions?) the GIL solves. So a GIL - free reference counting scheme may not prove to be helpful. If that were it, we could (optionally) turn off reference counting in multi-threaded code, and run a garbage collector once in a while instead. After all, cPython’s (mostly) deterministic garbage collection is not guaranteed by the language standard. -CHB ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] if we were to ever shorten `A if A else B` (was: PEP 505: None-aware operators)
> my vote would go to `A otherwise B` since it's unambiguous, the case you care > about the state of comes first, and it doesn't trip your brain up looking > for 'if'. :) And I’d hope “otherwise” is a rare variable name :-) - CHB > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 505: None-aware operators
I think I am with Michael here. I like the parallel between `??` and `or`, we don't have `or=`, so `??=` is also not needed. Although I understand a parallel between `obj.attr` and `obj['attr']`, I think there is an additional point (in addition to two valid points by Michael) why I don't like `?[`: in many situations in my experience optional container attributes were results of suboptimal APIs, so I would not encourage this pattern. FWIW, I am rather -0 on adding all proposed operators, but I would be +1 on adding just the two essential ones: ?? and ?. -- Ivan On 20 July 2018 at 01:40, Michael Lee wrote: > Hi -- I'm a new voice here, though I've been lurking for a while now. > > How do people feel about removing "??=" and "foo?[bar]" from the PEP and > sticking with just "foo?.bar" and "foo ?? bar"? > > Reasons for not implementing "??=": > >1. I think the other operators are useful in that they can be chained >together to shrink many different lines of code. In contrast, ??= can >shrink at most one line of code: we get to remove a single 'if foo is >None'. If the rest of the PEP is implemented, we can also just express >this by doing "foo = foo ?? some_expr" which I think is still >relatively concise. > >2. None of the other short-circuiting operators have an augmented >assignment form -- e.g. we can do "foo = foo or bar", but there's no >such thing as "foo or= bar". I don't really see why ?? in particular >deserves to have an augmented assignment form. > >3. We already have two different kinds of assignment operators with >the inclusion of PEP 572 -- in the interests of keeping Python as simple as >possible, I think it'd be a good idea not to add a third one. > > > Reasons for not implementing "foo?[bar]": > >1. It seems like "foo?[bar]" could be easily confused with "foo??[bar]". >I don't think it's immediately obvious to a newcomer which spelling >corresponds to which usage, and getting the two mixed up seems like the >sort of thing that could cause all sorts of subtle bugs. > >2. We can already easily get the same functionality using standard >Python. E.g., instead of doing foo?["bar"]?[0]?["baz"], we could do > lookup(foo, >"bar", 0, "baz") where lookup is a function that looks roughly like >this: > >def lookup(item, *parts): >for part in parts: >if item is None: >return None >item = item[parts] >return item > >Of course, we could probably create the same sort of function to >replace foo?.bar (albeit less ergonomically), but unlike foo?[bar], >there's no possibility for confusion: doing foo??.bar will never be a >valid Python expression. > >3. One counter-argument against removing foo?[bar] is that it would >make expression that need both safe index and attribute lookups look weird >-- you'd sometimes be using the "lookup" function described above (or >something similar) and sometimes using ".?". However, I'd argue that these >sorts of scenarios are relatively rare in practice, and that if you really >need to deal with a bunch of code that requires you to use both forms of >safe navigation, your code is likely already becoming pretty unreadable and >should be rewritten -- maybe split up into multiple lines or something, or >maybe just redesigned from scratch so you don't need to constantly manage a >mess of Nones. > > > More broadly, I think I agree with the sentiment some other people have > that Python has acquired a lot of new features in a relatively short period > of time, and that it would be nice to have some cooldown to let tooling and > other implementations catch up. In that regard, I'd personally be happy if > we didn't implement this PEP or just deferred it again. But if we *are* > moving forward with it, I think it's worth trying to simplify it as much as > possible/try and make it orthogonal with existing Python features. > > (But of course, I'm just some random person on the internet, so IDK if my > opinion counts for much.) > > Regards, > -- Michael > > > On Thu, Jul 19, 2018 at 5:06 PM, Chris Angelico wrote: > >> On Fri, Jul 20, 2018 at 10:03 AM, Greg Ewing >> wrote: >> > Rhodri James wrote: >> >> >> >> If anyone can think of a good word for "if it isn't None, otherwise", >> I'd >> >> be all for it :-) >> > >> > >> > I don't think there's any single Engish word that captures >> > all of that, so we'd have to invent one. >> > >> > Some suggestions: >> > >> > inno (If Not None, Otherwise) >> > >> > oft (Or, Failing That) >> >> Iunno, that'd oft be confusing. >> >> Kappa >> >> ChrisA >> ___ >> Python-ideas mailing list >> Python-ideas@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > >
Re: [Python-ideas] Multi-core reference count garbage collection
On Sat, Jul 21, 2018 at 11:05:43AM +0100, Daniel Moisset wrote: [snip interesting and informative discussion, thank you] > @Steven D'Aprano: you mentioned soemthign about race conditions but I don't > think this algorithm has any (the article you linked just said that doing > refcounting in the traditional way and without synchronization in a multi > core environment has race conditions, which is not what is being discussed > here). Could you expand on this? Certainly not. I already said that my view of this was very naive. Now that I have a better understanding that Jonathan doesn't have a specific issue to solve, other than "improved performance through better ref counting", I'll most likely just sit back and lurk. -- Steve ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Multi-core reference count garbage collection
Hi Barry We've met before. Nice to meet you again, this time electronically. You suggested that is a different problem that needs a solution. To help maintain focus, I won't respond to that now. You wrote: > I'd argue that the ref counts are not interesting at all, only a > side effect of one possible solution to the object life time problem. I'm happy for you to regard multi-core reference counting (MCRC) as a toy problem, which won't become part of useful software. We can learn a lot by understanding a good toy. Einstein was fascinated by the compass, and the spinning top is surprisingly deep. https://www.johnshepler.com/articles/einstein.html https://www.einsteinscompass.com/ https://en.wikipedia.org/wiki/Gyrocompass Of course, I hope you won't mind if MCRC turns out to useful. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] The future of Python parallelism. The GIL. Subinterpreters. Actors.
Eric, > On 17 Jul 2018, at 20:35, Eric Snow wrote: > > With this in mind, here's how I'm approaching the problem: > > 1. interp A "shares" an object with interp B (e.g. through a channel) >* the object is incref'ed under A before it is sent to B > 2. the object is wrapped in a proxy owned by B >* the proxy may not make C-API calls that would mutate the object > or even cause an incref/decref > 3. when the proxy is GC'd, the original object is decref'ed >* the decref must happen in a thread in which A is running How does the proxy at the same time make the object accessible and prevent mutation? Would it help if there was an explicit owning thread for each object? I'm thinking that you can do a fast check that the object belongs to the current thread and can use that knowledge to avoid locking. If the object is owned by another thread acquire the GIL in the traditional way and mutating the state will be safe. The "sharing" process can ensure that until an explicit "unsharing" the object remains safe to test in all threads that share an object, avoiding the need for the special processor instructions. Barry ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Multi-core reference count garbage collection
> On 21 Jul 2018, at 08:54, Jonathan Fine wrote: > > Hi Steve > > Thank you for your message. I think my response below allows us to go move > forward. > > WHAT'S THE PROBLEM > You asked: > > What problem are you trying to solve? > > Its okay if there is no immediate problem, that you're just exploring > > alternative garbage collection strategies. Or if you're trying to remove > > the GIL. > > I'm exploring. I hope we'll find something that helps CPython run faster on > multi-core machines, at least for some users. I hope this helps you > understand where I'm coming from. > I think that the problem that needs a solution is providing each thread with knowledge that is safe to update state. The questions that any solution needs to answer is then: 1) How does the solution provide each thread with the knowledge that it is safe to mutate state? 2) How does the solution manage the life time of the objects? For 1 today: In python all state is shared between all threads. One lock, the GIL, provides the code with the knowledge that it is safe to mutate state. For 2 today: The reference counts track the number of uses of an object. In the simple case when the ref count reaches 0 run the __del__ protocol. In the cases where circular reference patterns prevents detecting that an object is no longer needed via reference counts the exist python garbage collector figures out that such objects can be deleted. I'd note that the reference counts are just one piece of state of many pieces of state in an object. As an example of a idea that is looking directly at these questions is the work on using a sub-interpreter for each thread is interesting. It is aiming to solve (1) by using a per/interpreter lock, which will allow each thread to run at full speed. I'm following with interest how the life time management will work. In multi processing (1) is solved by no longer sharing object state. > Please, in this thread, can we confine ourselves to getting a better > understanding of multi-core reference count garbage collection. That is for > me already hard enough, in isolation, without mixing in other issues. I'd argue that the ref counts are not interesting at all, only a side effect of one possible solution to the object life time problem. Barry ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Multi-core reference count garbage collection
Hi Steve Thank you for your message. I think my response below allows us to go move forward. WHAT'S THE PROBLEM You asked: > What problem are you trying to solve? > Its okay if there is no immediate problem, that you're just exploring > alternative garbage collection strategies. Or if you're trying to remove > the GIL. I'm exploring. I hope we'll find something that helps CPython run faster on multi-core machines, at least for some users. I hope this helps you understand where I'm coming from. Please, in this thread, can we confine ourselves to getting a better understanding of multi-core reference count garbage collection. That is for me already hard enough, in isolation, without mixing in other issues. RACE CONDITION You wrote > multithreaded reference counting can suffer from race conditions > when incrementing or decrementing In support you referenced (the very useful) > http://flyingfrogblog.blogspot.com/2013/09/how-do-reference-counting-and-tracing.html The relevant statement on that page is > multithreaded reference counting is non-deterministic because increments and decrements race. According to https://en.wikipedia.org/wiki/Race_condition --- A race condition or race hazard is the behavior of an electronics, software, or other system where the output is dependent on the sequence or timing of other uncontrollable events. It becomes a bug when events do not happen in the order the programmer intended. --- I like this, but I would change the last sentence to read > It becomes a bug when the outputs are incorrect, for example are in a wrong order. Sometimes, eg iterating over a set, there is no intended order. DEALING WITH THE RACE CONDITION There is a race condition (or hazard) in buffered reference counting garbage collection. You wrote that this "would be a bad thing". I hope that, at the expense of some complexity in the code, the potential for a bug arising from race hazard can be avoided. Certainly, a bug in garbage collection is a bad thing. I was aware of this race hazard when I started this discussion thread. In my first post of yesterday I made "a start on the hard part" of "doing the right thing". I also then said > The remainder of the hard part is to get hold of adjusted reference > counts, without having to lock the worker threads. GOING FORWARD I hope in the next day or two to make a start on the remainder of the hard part. Your link to flyingfrog is valuable. I hope you'll contribute again. Finally, you might help you to know that I'm trying in my exploration to use top-down or stepwise design. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Multi-core reference count garbage collection
Hi Chris Thank you for your message about two processes together sorting a deck of cards. My example was in response to a comment from Steve D'Aprano. He understood in the way it was intended, which was the algorithm is in execution non-deterministic, but that the outcome is deterministic. Steve, in a message after yours, explains this point. And so I won't repeat what would be essentially the same explanation. Once again, I thank you (and Steve) for their contributions. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
