Re: [Python-ideas] A better (simpler) approach to PEP 505

On Wednesday, July 25, 2018 at 10:33:37 AM UTC+2, Brice Parent wrote: > > I think the use case here is not really the simple 'is None' + 'is not > None'. > Sure, that's why I also proposed to manually check a non-too-small samples of the None-testing occurences found by Guido . You did it on

Re: [Python-ideas] A better (simpler) approach to PEP 505

Le 25/07/2018 à 08:49, Grégory Lielens a écrit : BTW, I did (very quickly, so it's rough, my regexps are not really catching everything) the same or our code base: "is None"+ "is not None": 5600 AttributeError: 160 3 args getattr: 60 hasattr: 1800 So very similar to your patternexcept for

Re: [Python-ideas] A better (simpler) approach to PEP 505

BTW, I did (very quickly, so it's rough, my regexps are not really catching everything) the same or our code base: "is None"+ "is not None": 5600 AttributeError: 160 3 args getattr: 60 hasattr: 1800 So very similar to your patternexcept for hasattr, which is much more common in my case...

Re: [Python-ideas] A better (simpler) approach to PEP 505

Interesting, looking into, let's say, 100 of those is [not] None, randomly chosen, should give an very good idea of typical use for your code base. I am curious about why you don't like solutions involving exceptions? Performance? Catching too much, like typing errors? Less easy to distinguish

Re: [Python-ideas] A better (simpler) approach to PEP 505

On Tue, Jul 24, 2018 at 1:57 AM Stefan Behnel wrote: > > David Mertz schrieb am 23.07.2018 um 16:12: > > The need addressed by PEP 505 is real; it's also MUCH more niche and > > uncommon than something that would merit new syntax. Moreover, the actual > > legitimate purpose served by the PEP 505

Re: [Python-ideas] A better (simpler) approach to PEP 505

On Tuesday, July 24, 2018 at 2:39:19 AM UTC+2, Steven D'Aprano wrote: > PEP 505 has a section explaining why catching AttributeError > is undesirable. I find the reasons it gives are compelling. > > Can you explain why you reject the PEP's arguments against catching > AttributeError? > >

Re: [Python-ideas] A better (simpler) approach to PEP 505

On Mon, Jul 23, 2018 at 01:55:48PM -0400, David Mertz wrote: > On Mon, Jul 23, 2018 at 1:28 PM Steven D'Aprano wrote: > > > There's the first bug right there. foo.bar.blim ought to raise > > AttributeError, since there is no blim attribute defined on foo.bar. > > > > Note my observation that

Re: [Python-ideas] A better (simpler) approach to PEP 505

On Mon, Jul 23, 2018 at 10:53:11AM -0700, Grégory Lielens wrote: > The proto here swallow and short circuit on attribute error. Changing > to do it on Noneness is easy, and you can choose between the two > behavior: it's a strength compared to the operator approach. Being able to choose

Re: [Python-ideas] A better (simpler) approach to PEP 505

David Mertz schrieb am 23.07.2018 um 16:12: > The need addressed by PEP 505 is real; it's also MUCH more niche and > uncommon than something that would merit new syntax. Moreover, the actual > legitimate purpose served by the PEP 505 syntax is easily served by > existing Python simply by using a

Re: [Python-ideas] A better (simpler) approach to PEP 505

I agree a class can provide a very good alternative to PEP505.  I built one a while ago, and still use it https://github.com/klahnakoski/mo-dots for most my data transformation code. The library only boxes dicts and lists, which removes the need for .unbox() in many of my use cases. My point is,

Re: [Python-ideas] A better (simpler) approach to PEP 505

Short circuit is indeed the main difference. Makes me re-think about the None trigger subclasses of invalid operations exceptions. Like None.a trigger a NoneAttributeError(AttributeError), and so on... I think it solves many issues without much problems nor syntax changes, but probably I miss

Re: [Python-ideas] A better (simpler) approach to PEP 505

Le 23/07/2018 à 17:12, David Mertz a écrit : > The need addressed by PEP 505 is real; it's also MUCH more niche and > uncommon than something that would merit new syntax. Moreover, the > actual legitimate purpose served by the PEP 505 syntax is easily served > by existing Python simply by

Re: [Python-ideas] A better (simpler) approach to PEP 505

On 23/07/18 19:21, David Mertz wrote: On Mon, Jul 23, 2018 at 2:12 PM Rhodri James wrote: How are you supposed to do method calling, the equivalent of "foo?.bar()" ? "NoneAware(foo).bar.unbox()()" looks downright weird. Is there more magic in NoneAware to cover this case? (Not that I think

Re: [Python-ideas] A better (simpler) approach to PEP 505

On Mon, Jul 23, 2018 at 2:12 PM Rhodri James wrote: > > How are you supposed to do method calling, the equivalent of > "foo?.bar()" ? "NoneAware(foo).bar.unbox()()" looks downright weird. > Is there more magic in NoneAware to cover this case? (Not that I think > we should be encouraging people

Re: [Python-ideas] A better (simpler) approach to PEP 505

On Mon, Jul 23, 2018 at 2:12 PM Rhodri James wrote: > How are you supposed to do method calling, the equivalent of > "foo?.bar()" ? "NoneAware(foo).bar.unbox()()" looks downright weird. > Is there more magic in NoneAware to cover this case? (Not that I think > we should be encouraging people

Re: [Python-ideas] A better (simpler) approach to PEP 505

On 23/07/18 16:12, David Mertz wrote: Here is a way of solving the "deep attribute access to messy data" problem Before we go too far, and /pace/ Steve's work, how real is this problem? I get that there is a use in accessing JSON trees, but this feels awfully like a rather specific issue

Re: [Python-ideas] A better (simpler) approach to PEP 505

On Mon, Jul 23, 2018 at 1:28 PM Steven D'Aprano wrote: > There's the first bug right there. foo.bar.blim ought to raise > AttributeError, since there is no blim attribute defined on foo.bar. > Note my observation that this is deliberately different semantics. I want to solve the underlying

Re: [Python-ideas] A better (simpler) approach to PEP 505

The proto here swallow and short circuit on attribute error. Changing to do it on Noneness is easy, and you can choose between the two behavior: it's a strength compared to the operator approach. It's working in current python, another strength. I think short-circuit behavior is similar: once

Re: [Python-ideas] A better (simpler) approach to PEP 505

On Mon, Jul 23, 2018 at 11:12:45AM -0400, David Mertz wrote: > Here is a way of solving the "deep attribute access to messy data" problem > that is: > > (1) Much more explicit > (2) Requires no change in syntax > (3) Will not be a bug magnet That's one opinion. > (4) Inasmuch as there are

Re: [Python-ideas] A better (simpler) approach to PEP 505

On Mon, Jul 23, 2018 at 11:34 AM Robert Vanden Eynde wrote: > The default could be at the end with an argument to unboxing : > > favorite = NoneAware(cfg).user.profile.food.unbox("Spam") > That's what PyMaybe does: https://pymaybe.readthedocs.io/en/latest/readme.html#examples-use-cases

Re: [Python-ideas] A better (simpler) approach to PEP 505

Btw. I *do* realize that the semantics of my suggested NoneAware class is different from the coalescing syntax. I just look at whether attribute access succeeds or fails in that code, not whether the starting value is specifically None (nor any particular sentinel). I believe that that behavior

Re: [Python-ideas] A better (simpler) approach to PEP 505

On Mon, Jul 23, 2018 at 12:47 PM Antoine Pitrou wrote: > > favorite = cfg?.user?.profile?.food ?? "Spam" > > favorite = NoneAware(cfg, "Spam").user.profile.food.unbox() > > You could use .__call__() instead of .unbox(). Also you can make > unboxing unnecessary in most cases by having your

Re: [Python-ideas] A better (simpler) approach to PEP 505

On Mon, 23 Jul 2018 11:12:45 -0400 David Mertz wrote: > > The particular names I use are nothing special, and better ones might be > found. I just called the class NoneAware and the "escape" method > `.unbox()` because that seemed intuitive at first brush. > > I don't disagree that needing to

Re: [Python-ideas] A better (simpler) approach to PEP 505

Your wrapper class can also, I think: Swallow exceptions, especially AttributeError Specify the sentinel, if it is not None Work for getitem Mixing is indeed more difficult, and there is probably performance impact. Still, it's general and does not need to touch the implementation of the

Re: [Python-ideas] A better (simpler) approach to PEP 505

Le 23/07/2018 à 18:00, David Mertz a écrit : On Mon, Jul 23, 2018 at 11:26 AM Paul Moore > wrote: * Library solution works with all versions of Python * The need for unbox is a little ugly, but arguably less so than ?. (conceded that's a subjective view)

Re: [Python-ideas] A better (simpler) approach to PEP 505

On Mon, Jul 23, 2018 at 11:26 AM Paul Moore wrote: > * Library solution works with all versions of Python > * The need for unbox is a little ugly, but arguably less so than ?. > (conceded that's a subjective view) > * Mixing ?. and . is terser than unboxing and reboxing - but are there > any

Re: [Python-ideas] A better (simpler) approach to PEP 505

Hi David and Paul Thank you both for your contributions, and for starting a new thread. David, you wrote > The need addressed by PEP 505 is real; I completely agree. My view is that with PEP 505 as it it, the problem is better than the solution. But all the same, something can be done to

Re: [Python-ideas] A better (simpler) approach to PEP 505

The default could be at the end with an argument to unboxing : favorite = NoneAware(cfg).user.profile.food.unbox("Spam") Le lun. 23 juil. 2018 à 17:26, Paul Moore a écrit : > On 23 July 2018 at 16:12, David Mertz wrote: > > The need addressed by PEP 505 is real; it's also MUCH more niche and

Re: [Python-ideas] A better (simpler) approach to PEP 505

On 23 July 2018 at 16:12, David Mertz wrote: > The need addressed by PEP 505 is real; it's also MUCH more niche and > uncommon than something that would merit new syntax. Moreover, the actual > legitimate purpose served by the PEP 505 syntax is easily served by existing > Python simply by using