Re: [Python-ideas] PEP 505: None-aware operators

[Steve Dower ] > ... * The "``None``-aware attribute access" operator ``?.`` evaluates the > complete expression if the left hand side evaluates to a value that is not > ``None`` > And if the LHS does evaluate to `None` ...? I'll assume the result is also `None` then. > ... > From

[Python-ideas] Revisiting str.rreplace()

This was previously proposed here in 2014 < https://mail.python.org/pipermail/python-ideas/2014-January/025091.html>, but the discussion fizzled out. To me, str.rreplace() is an obvious and necessary complement to str.replace(), just as str.rsplit() is a complement to str.split(). It would make

Re: [Python-ideas] PEP 505: None-aware operators

On Thu, Jul 19, 2018 at 2:06 AM Chris Angelico wrote: > > With all due respect (and I am sorry for being “vocal” about a PEP once > > again) I find this simply ugly. To me this basically doesn’t look like > > python anymore, so a strong -1 from me. > > I'd love to hear an explanation of WHY this

Re: [Python-ideas] PEP 505: None-aware operators

The examples in the PEP strengthen my opinion. I think every one of them read much more clearly in the existing syntax. I can only understand any by mentally inserting 'if Foo is None' everywhere... Basically mentally replacing the "code golf" syntax with the actual intent that is spelled like it

Re: [Python-ideas] PEP 505: None-aware operators

As before, I'm a strong -1 on this. I recognize the semantic utility (albeit, I've needed it much less than some folks testify). But the obscure characters are accumulating far too fast with this. Even with PEP 572, I would have preferred 'as' and restrictions on where it's allowed, but ':=' is

Re: [Python-ideas] PEP 505: None-aware operators

On Thu, Jul 19, 2018 at 9:55 AM, Giampaolo Rodola' wrote: [ please trim quotes, you just quoted the entire PEP in your post ] > With all due respect (and I am sorry for being “vocal” about a PEP once > again) I find this simply ugly. To me this basically doesn’t look like > python anymore, so a

Re: [Python-ideas] PEP 505: None-aware operators

On Wed, Jul 18, 2018 at 7:46 PM Steve Dower wrote: > > Possibly this is exactly the wrong time to propose the next big syntax > change, since we currently have nobody to declare on it, but since we're > likely to argue for a while anyway it probably can't hurt (and maybe > this will become the

Re: [Python-ideas] The future of Python parallelism. The GIL. Subinterpreters. Actors.

On Wed, Jul 18, 2018 at 11:49 AM, Stephan Houben wrote: > Basically, what I am suggesting is a direct translation of Javascript's > Web Worker API > (https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API) > to Python. > > The Web Worker API is generally considered a "share-nothing"

Re: [Python-ideas] PEP 505: None-aware operators

Thanks! Bit of discussion below about precedence, but thanks for spotting the typos. On 18Jul2018 1318, MRAB wrote: On 2018-07-18 18:43, Steve Dower wrote: Grammar changes --- The following rules of the Python grammar are updated to read::   augassign: ('+=' | '-=' | '*=' |

Re: [Python-ideas] The future of Python parallelism. The GIL. Subinterpreters. Actors.

On Wed, Jul 18, 2018 at 2:38 PM MRAB wrote: > What if an object is not going to be shared, but instead "moved" from > one subinterpreter to another? The first subinterpreter would no longer > have a reference to the object. > > If the object's refcount is 1 and the object doesn't refer to any

Re: [Python-ideas] The future of Python parallelism. The GIL. Subinterpreters. Actors.

On 2018-07-18 20:35, Eric Snow wrote: On Wed, Jul 18, 2018 at 12:49 PM Stephan Houben wrote: Antoine said that what I proposed earlier was very similar to what Eric is trying to do, but from the direction the discussion has taken so far that appears not to be the case. It looks like we are

Re: [Python-ideas] PEP 505: None-aware operators

On 2018-07-18 18:43, Steve Dower wrote: Possibly this is exactly the wrong time to propose the next big syntax change, since we currently have nobody to declare on it, but since we're likely to argue for a while anyway it probably can't hurt (and maybe this will become the test PEP for whoever

Re: [Python-ideas] The future of Python parallelism. The GIL. Subinterpreters. Actors.

On Wed, Jul 18, 2018 at 12:49 PM Stephan Houben wrote: > Antoine said that what I proposed earlier was very similar to what Eric > is trying to do, but from the direction the discussion has taken so far > that appears not to be the case. It looks like we are after the same thing actually. :)

Re: [Python-ideas] The future of Python parallelism. The GIL. Subinterpreters. Actors.

Hi Python in the age of the multi-core processor is an important question. And garbage collection is one of the many issues involved. I've been thinking about the garbage collection problem, and lurking on this list, for a while. I think it's now about time I showed myself, and shared my

Re: [Python-ideas] The future of Python parallelism. The GIL. Subinterpreters. Actors.

On Wed, Jul 18, 2018 at 1:37 AM Barry Scott wrote: > Let me try a longer answer. The inc+test and dec+test do not require a > lock if coded correctly. All OS and run times have solved this to provide > locks. All processors provide the instructions that are the building blocks > for lock

[Python-ideas] PEP 505: None-aware operators

Possibly this is exactly the wrong time to propose the next big syntax change, since we currently have nobody to declare on it, but since we're likely to argue for a while anyway it probably can't hurt (and maybe this will become the test PEP for whoever takes the reins?). FWIW, Guido had

Re: [Python-ideas] The future of Python parallelism. The GIL. Subinterpreters. Actors.

On Wed, Jul 18, 2018 at 3:31 AM Antoine Pitrou wrote: > Please read in context: we are not talking about making all refcounts > atomic, only a couple refcounts on shared objects (which probably > won't be Python objects, actually). I have no plans to use refcounts for shared data (outside of

Re: [Python-ideas] grouping / dict of lists

Counter also consider any missing key has the value "0". With the constructor (accepting any iterable) and the most_common(n), it's just a very set of features if you need to count anything. Le 13/07/2018 à 19:45, Michael Selik a écrit : > On Mon, Jul 2, 2018 at 8:49 AM Chris Barker

Re: [Python-ideas] The future of Python parallelism. The GIL. Subinterpreters. Actors.

On Wed, 18 Jul 2018 08:21:31 +0100 Ronald Oussoren via Python-ideas wrote: > Some past attempts at getting rid of the GIL used atomic inc/dec, and that > resulted in bad performance because these instructions aren’t cheap. Please read in context: we are not talking about making all refcounts

Re: [Python-ideas] The future of Python parallelism. The GIL. Subinterpreters. Actors.

> On 18 Jul 2018, at 08:21, Ronald Oussoren wrote: > > Op 18 jul. 2018 om 08:02 heeft Barry > het volgende geschreven: > >> >> On 17 Jul 2018, at 21:00, Eric Snow wrote: On Tue, Jul 17, 2018 at 1:44 PM Barry wrote: The decrement itself

Re: [Python-ideas] The future of Python parallelism. The GIL. Subinterpreters. Actors.

> On 17 Jul 2018, at 21:00, Eric Snow wrote: > > On Tue, Jul 17, 2018 at 1:44 PM Barry wrote: >> The decrement itself is not the problem, that can be made thread safe. > > Yeah, by using the GIL. Otherwise, please elaborate. My > understanding is that if the decrement itself were not the

Re: [Python-ideas] The future of Python parallelism. The GIL. Subinterpreters. Actors.

Op 18 jul. 2018 om 08:02 heeft Barry het volgende geschreven: > > >>> On 17 Jul 2018, at 21:00, Eric Snow wrote: >>> >>> On Tue, Jul 17, 2018 at 1:44 PM Barry wrote: >>> The decrement itself is not the problem, that can be made thread safe. >> >> Yeah, by using the GIL. Otherwise,

Re: [Python-ideas] The future of Python parallelism. The GIL. Subinterpreters. Actors.

>> On 17 Jul 2018, at 21:00, Eric Snow wrote: >> >> On Tue, Jul 17, 2018 at 1:44 PM Barry wrote: >> The decrement itself is not the problem, that can be made thread safe. > > Yeah, by using the GIL. Otherwise, please elaborate. My > understanding is that if the decrement itself were not