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 between None and attr missing? Less easy to combine None-aware and classic attr lookup on the same expression? Something else?___ 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] Python docs page: In what ways is None special
Here's another way that None is special. === >>> NoneType = type(None) >>> >>> class myNoneType(NoneType): pass ... Traceback (most recent call last): File "", line 1, in TypeError: type 'NoneType' is not an acceptable base type === For more information see https://stackoverflow.com/questions/10061752/which-classes-cannot-be-subclassed Related are https://stackoverflow.com/questions/2172189/why-i-cant-extend-bool-in-python/2172204#2172204 https://stackoverflow.com/questions/2825364/final-classes-in-python-3-x-something-guido-isnt-telling-me -- 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] PEP 505: None-aware operators
On Tue, Jul 24, 2018, 9:09 AM Chris Angelico wrote: > >>> x = Foo(cfg).user.profile > >>> x.food > > Remember, these lines could be a very long way apart. You could pass > 'x' to a function unrelated to the line of code that created it. And > 'x.food' still has to have the magic. You can't mandate that the call > to Coalesce be on the same line as the attribute access - Python > doesn't work that way. > > So your perfectly ordinary dot operator now does magic in addition to > normal attribute access. See why it's a dangerous thing? > Yes, of course. That's why I would recommend best practice is to unbox or otherwise use the conditional value as close to the magic code as feasible. Likewise, as I noted a little while ago, 'x.food' could equally well be a property that executed arbitrarily slow, magical, obscure, or even malicious operations. Equally, 'x + y' could do absolutely anything if we define .__add__() or .__radd__() methods. Everything in Python is magical in that sense, but we should deliberately keep the magic constrained to the amount needed. > ___ 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 *definitely* don't think a little tool I wrote in a couple hours last night belongs in the standard library (with most of the heavy lifting actually done by wrapt—which is really well designed, and is also not in the standard library). I also don't think PyMaybe belongs there, even though it's a couple years old. Now, perhaps, if 'coalescing' is widely used for a year or two. And bugs are fixed. And the API is tweaked based on experience with it's use. And so on... At that point, *maybe* something derived from it might be appropriate. On Tue, Jul 24, 2018, 9:08 AM Rhodri James wrote: > On 24/07/18 14:02, David Mertz wrote: > > On Tue, Jul 24, 2018, 7:38 AM Rhodri James wrote: > >> I'm still of the opinion that both approaches are trying to solve a > >> problem that's too niche to merit them, BTW. > >> > > > > That doesn't make sense to me. You think my little library shouldn't be > > allowed on PyPI? I don't force the couple classes on anyone, but if they > > happen to help someone (or PyMaybe, or some other library, does) they > don't > > change anything about Python itself. Syntax is a very different matter. > > I have no objection to anyone putting anything on PyPI. Putting it (or > an equivalent) in the standard library is much more problematical, and > you were talking about that. I think your little library is a much > richer source of bugs than you think it is, and dealing with messy data > access isn't a good enough reason to put that much temptation in front > of naive users. > > -- > Rhodri James *-* Kynesim Ltd > ___ 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 Tue, Jul 24, 2018 at 11:02 PM, David Mertz wrote: > On Tue, Jul 24, 2018, 7:38 AM Rhodri James wrote: >> >> On 24/07/18 12:02, David Mertz wrote: >> > Every use I've suggested for the magic proxy is similar to: >> > >> >NullCoalesce(cfg).user.profile.food >> > >> > Yes, the class is magic. That much more so in the library I published >> > last >> > night that utilizes wrapt.ObjectProxy. But it's also pretty explicit in >> > that an actual*word* announces that funny stuff is going to happen on >> > the >> > same line. >> >> Foo(cfg).user.profile.food >> >> Is that explicit that funny stuff is going to happen on the same line? I >> wouldn't generally assume so, I'd just assume the coder created a throwaway >> object to get at an attribute. > > > Foo isn't a very indicative name. NoneCoalesce (or NullCoalesce, or > GreedyAccess) is. But if I had any doubt, I could read the docstring for Foo > to find out how magical it was, and in what way. I definitely know > *something* is happening by creating that new instance in the line. > Okay. Check this out, then: >>> x = Foo(cfg).user.profile >>> x.food Remember, these lines could be a very long way apart. You could pass 'x' to a function unrelated to the line of code that created it. And 'x.food' still has to have the magic. You can't mandate that the call to Coalesce be on the same line as the attribute access - Python doesn't work that way. So your perfectly ordinary dot operator now does magic in addition to normal attribute access. See why it's a dangerous thing? 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 24/07/18 14:02, David Mertz wrote: On Tue, Jul 24, 2018, 7:38 AM Rhodri James wrote: I'm still of the opinion that both approaches are trying to solve a problem that's too niche to merit them, BTW. That doesn't make sense to me. You think my little library shouldn't be allowed on PyPI? I don't force the couple classes on anyone, but if they happen to help someone (or PyMaybe, or some other library, does) they don't change anything about Python itself. Syntax is a very different matter. I have no objection to anyone putting anything on PyPI. Putting it (or an equivalent) in the standard library is much more problematical, and you were talking about that. I think your little library is a much richer source of bugs than you think it is, and dealing with messy data access isn't a good enough reason to put that much temptation in front of naive users. -- Rhodri James *-* Kynesim Ltd ___ 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 Tue, Jul 24, 2018, 7:38 AM Rhodri James wrote: > On 24/07/18 12:02, David Mertz wrote: > > Every use I've suggested for the magic proxy is similar to: > > > >NullCoalesce(cfg).user.profile.food > > > > Yes, the class is magic. That much more so in the library I published > last > > night that utilizes wrapt.ObjectProxy. But it's also pretty explicit in > > that an actual*word* announces that funny stuff is going to happen on > the > > same line. > > Foo(cfg).user.profile.food > > Is that explicit that funny stuff is going to happen on the same line? I > wouldn't generally assume so, I'd just assume the coder created a throwaway > object to get at an attribute. Foo isn't a very indicative name. NoneCoalesce (or NullCoalesce, or GreedyAccess) is. But if I had any doubt, I could read the docstring for Foo to find out how magical it was, and in what way. I definitely know *something* is happening by creating that new instance in the line. I'm still of the opinion that both approaches are trying to solve a > problem that's too niche to merit them, BTW. > That doesn't make sense to me. You think my little library shouldn't be allowed on PyPI? I don't force the couple classes on anyone, but if they happen to help someone (or PyMaybe, or some other library, does) they don't change anything about Python itself. Syntax is a very different matter. > ___ 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 24/07/18 13:07, Richard Damon wrote: The fact that you changed NullCoalesce into Foo to show lack of explicitness seems a straw-man. Words are FULL of meaning, while symbols are less so. The biggest issue I see with the use of ? here is that ? does have some meaning, it says we are going to be (or have) asked a question, it doesn’t tell us what the question is. Most of the other symbols used have a long history of meaning (yes = has the problem that historically it has had two possible meanings). To me, ? gives no indication that it is going to ask about Nullness. Oh, I don't disagree with you about ? not giving any much indication that it's about Nullness except for the (relatively short) history of using it to mean exactly that in C# etc. However I don't think that a class of whatever name doing something magic is any better. -- Rhodri James *-* Kynesim Ltd ___ 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] 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 syntax is easily served by > > existing Python simply by using a wrapper class. > > The discussion so far made it clear to me that > > a) there is a use case for this feature, although I never needed it myself > b) throwing new syntax at it is not the right solution > > Especially since there seem to be slightly diverging ideas about the exact > details in behaviour. Since this can be done in form of a library, people > should just drop it into a couple of competing libraries and let users > choose what they like better in their specific situation. And since we > already have a PEP now, let's continue to use it as a basis for discussion > about how these libraries should best behave in general and what mistakes > they should avoid. > > Stefan +1 There is still no proof that such a programming pattern would be widely used or is desirable in practice. A library on PYPI could help clarifying that (and the PEP should mention it). -- 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] Idea: Deferred Default Arguments?
I agree this is a problem, which I have seen solved by removing the method signature, which is unfortunate: > def flexible_method(**kwargs): > # Read the code to find out the expected parameters I have an @override decorator to handle this type of pattern. It will perform the null-coalescing with properties found in a special "kwargs" parameter. "kwargs" is assigned a dict that has a copy of the method arguments. The value of a callee's argument is, in order, * a not None value provided by the caller or * a not None value found in the kwargs dict or * the default value provided by the method declaration or * None I was not clear on where you wanted to define your defaults. Either like this: > @override > def subfunction_1(a=None, b=None, c=None, kwargs=None): > return a+b*c > > @override > def subfunction_2(d=None, e=None, f=None, kwargs=None): > return d*e+f > > @orverride > def main_function(a=2, b=3, c=4, d=5, e=6, f=7, kwargs=None): > return subfunction_1(a, b, c) + subfunction_2(d, e, f) > return subfunction_1(kwargs) + subfunction_2(kwargs) # IF YOU WANT TO BE LAZY or like this: > @override > def subfunction_1(a=2, b=3, c=4, kwargs=None): > return a+b*c > > @override > def subfunction_2(d=5, e=6, f=7, kwargs=None): > return d*e+f > > @orverride > def main_function(a=None, b=None, c=None, d=None, e=None, f=None, kwargs=None): > return subfunction_1(a, b, c) + subfunction_2(d, e, f) > return subfunction_1(kwargs) + subfunction_2(kwargs) # IF YOU WANT TO BE LAZY both are identical except for where you declare the default values. https://github.com/klahnakoski/mo-kwargs ___ 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
Both approaches should not be exposed as core language, but as facilitating tools to be used if, in your application, you have to traverse deep semi-regular attributes hierarchies. The operator approach, by definition, is part of the core, so -1 The wrapper does not need to be included in python, so the discussion is meaningless: people define the tools they want and use them as they please. Personally, I think it would be nice to have that in the standard distrib, especially wrapt or something as powerful. But I don't really care in fact, what good is that now I know about it so I can use it...___ 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 Jul 24, 2018, at 7:37 AM, Rhodri James wrote: > >> On 24/07/18 12:02, David Mertz wrote: >> Every use I've suggested for the magic proxy is similar to: >> NullCoalesce(cfg).user.profile.food >> Yes, the class is magic. That much more so in the library I published last >> night that utilizes wrapt.ObjectProxy. But it's also pretty explicit in >> that an actual*word* announces that funny stuff is going to happen on the >> same line. > > Foo(cfg).user.profile.food > > Is that explicit that funny stuff is going to happen on the same line? I > wouldn't generally assume so, I'd just assume the coder created a throwaway > object to get at an attribute. You have to know that "NullCoalesce" does > magic before it is at all explicit that funny stuff will happen. Thinking > about it, NullCoalesce() may be *less* explicit than ?. because at least that > doesn't look like ordinary attribute reference. > > I'm still of the opinion that both approaches are trying to solve a problem > that's too niche to merit them, BTW. > > -- > Rhodri James *-* Kynesim Ltd The fact that you changed NullCoalesce into Foo to show lack of explicitness seems a straw-man. Words are FULL of meaning, while symbols are less so. The biggest issue I see with the use of ? here is that ? does have some meaning, it says we are going to be (or have) asked a question, it doesn’t tell us what the question is. Most of the other symbols used have a long history of meaning (yes = has the problem that historically it has had two possible meanings). To me, ? gives no indication that it is going to ask about Nullness. ?. has some indication that we are doing an attribute access that is in some way conditional, but a?.b could mean that we are conditional on a not being null, or it could be asking to suppress any and all error in getting b, even if a is an int and thus doesn’t have a b. The words carry a lot more meaning. ___ 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 24/07/18 12:56, Grégory Lielens wrote: On Tuesday, July 24, 2018 at 1:38:42 PM UTC+2, Rhodri James wrote: -snip- I'm still of the opinion that both approaches are trying to solve a problem that's too niche to merit them, BTW. That's also my impression. Hence the second approach: it does not require any change to python, it's just a tool for that niche, so imho it's the right approach. OK, I'm confused. Either you agree with me, and think the second approach is also wrong, or you think the second approach is right and disagree with me. Which is it? -- Rhodri James *-* Kynesim Ltd ___ 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 Tuesday, July 24, 2018 at 1:38:42 PM UTC+2, Rhodri James wrote: > > -snip- > I'm still of the opinion that both approaches are trying to solve a > problem that's too niche to merit them, BTW. That's also my impression. Hence the second approach: it does not require any change to python, it's just a tool for that niche, so imho it's the right approach. Such a wrapper can even be provided by the lib that produced such nested attributes in the first place. The operator are a tool which seems designed to the same niche issue, but is exposed as a core language feature. It may be interesting if it provides a lot of side benefits, so the tool is so braodly useful it outgrowned it's niche origin. At this point, I do not think it does. ___ 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 24/07/18 12:02, David Mertz wrote: Every use I've suggested for the magic proxy is similar to: NullCoalesce(cfg).user.profile.food Yes, the class is magic. That much more so in the library I published last night that utilizes wrapt.ObjectProxy. But it's also pretty explicit in that an actual*word* announces that funny stuff is going to happen on the same line. Foo(cfg).user.profile.food Is that explicit that funny stuff is going to happen on the same line? I wouldn't generally assume so, I'd just assume the coder created a throwaway object to get at an attribute. You have to know that "NullCoalesce" does magic before it is at all explicit that funny stuff will happen. Thinking about it, NullCoalesce() may be *less* explicit than ?. because at least that doesn't look like ordinary attribute reference. I'm still of the opinion that both approaches are trying to solve a problem that's too niche to merit them, BTW. -- Rhodri James *-* Kynesim Ltd ___ 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] Fwd: A better (simpler) approach to PEP 505
I started a new thread where I show a small library I made yesterday that ALSO matches 505 semantics, as well as more general AttributeError swallowing. It has two classes with sightly different behavior. So we don't need syntax for either semantics. On Tue, Jul 24, 2018, 3:29 AM Grégory Lielens wrote: > > > 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? >> >> > > Yes, and people have done it multiple time already. I will try to make it > as explicit as possible, with a terminology that some may find useful... > when u have a object hierarchy linked through attributes, which -seems- > the use pattern of ?. , the hierarchy is either > - 1) fully regular (each attribute contains the same type of objects (same > type=with the same attributes), then normal . access is what you want > - 2) regular-or-None (contain same type of objects, or None). That's what > ?. is for, and ?. is only for that. > - 3) its partially regular (does not contain the same type of objects, > some objects have more attributes than other, e.g. partial objects). > - 4) its irregular (objects may be of completely different type (int, > str,... and do not specailly share attributes). > > ?. is intended for 2). > 2) and 3) can be dealed with swallowing AttributeError > 4) can also be traversed swallowing AttributeError, but it's probably a > very bad idea in almost all cases. > > I've encountered all cases, from time to time, but none is really typical > of most of my code. Which is more common? not sure, I would say 3). > What is sure is that 2) do not stand as hugely more common than the > others, so introducing a special syntax for 2) do not please me, so +0... > Now as I find ?. unpleasant to parse (personal opinion), and having grown > to share the general operaror / line noise allergy mainstream in the python > community, i am a firm -1 on this: too small a niche, do not bring much > compared to current approach, and visual line noise. > firm -1 on ?? too, it's less polemic, less visually displeasing, but even > less usefull I think: it does not gain that much compared to a more general > ternary. > > As the pymaybe/this thread cover 2) and 3), and do it without any change > to python, I find it better. No change > lib change > backward compatible > object change - like dict becoming ordered, or None triggering > NoneAttributeError(AttributeError) > syntax change (expecially a bunch of > linenoisy operators). > > Now I will stop for a while here, arguments have become circular, > proponents and opponents have exposed their view, but mostly proponents > have provided very few additional information for a while, especially about > real use cases, despite a few requests. > We still do not know what motivated the proposal..We had to guess (JSON). > Even the PEP do not say, it provide a set of real world example from the > standard library, which is admirable but different. And personaly, while am > very thankful for providing those concrete examples, I find them > unconvicing: the code before is usually fine and improved little by the new > operators. Sometimes it's worse: only slightly shorter and less clear. > ___ > 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 Tue, Jul 24, 2018, 5:50 AM Steven D'Aprano wrote: > But what certainly *is* implicity is David Mertz' suggestion for a > magical None-aware proxy: > > x.attribute > > The only way to tell whether that was an ordinary attribute lookup or a > none-aware lookup would be to carefully inspect x and find out whether it > was an instance of the None-aware proxy class or not. > Every use I've suggested for the magic proxy is similar to: NullCoalesce(cfg).user.profile.food Yes, the class is magic. That much more so in the library I published last night that utilizes wrapt.ObjectProxy. But it's also pretty explicit in that an actual *word* announces that funny stuff is going to happen on the same line. Of course the this could be abused with: cfg = NoneCoalesce(cfg) ... 1000 lines ... do_something(cfg) But then, I could also write a property that actually started a computation of the millionth digit of pi while launching a DDoS attack on python.org when a user accessed 'x.attribute'. NoneCoalesce or GreedyAccess are magic, but in their intended use, they are as little magical as possible to deal with messy nested data. ___ 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 Tue, Jul 24, 2018 at 11:50 AM Steven D'Aprano wrote: > > On Tue, Jul 24, 2018 at 12:05:14AM +0200, Giampaolo Rodola' wrote: > > > This: > > > > v = a?.b > > > > ...*implicitly* checks if value is not None [and continues execution]. > > Do you agree that: > > obj.attribute > x + 1 > func(arg) > > explicitly looks up an attribute on obj, explicitly adds 1 to x, and > explicitly calls func with a single argument? I don't think that we have > to write COBOL-esque code to be explicit: > > GET ATTRIBUTE "attribute" FROM obj > ADD 1 TO x > CALL FUNCTION func WITH ARGUMENT arg > > I don't accept that the use of punctuation makes something implicit. But > if you want to argue that anything with punctuation is "implicit", then > okay, Python has lots of implicit punctuation. > By definition, ?. checks for None before doing the attribute lookup. > That is completely explicit, regardless of how it is spelled: > > obj?.attribute You totally missed my point about explicitness. Nevermind. > > This > > > > v = a > > if a.b is not None: > > v = a.b > > > > ...*explicitly* checks if value is not None and continues execution. > > If you are trying to match the behaviour of a?.b above, it is also > completely buggy and doesn't do what is intended. > > # Equivalent of a?.b > v = a > if v is not None: > v = v.b > > > > If for some reason '?'[ is also going to swallow LookupError > > What makes you think that ?[...] will swallow LookupError? > > Please don't argue against misfeatures that the PEP doesn't propose. > Nothing in PEP 505 swallows any exceptions. Swallowing exceptions is > explicitly rejected, and swallowing LookupError isn't part of the > proposal. I know it's not in the PEP. I merely mentioned that as PEP author was questioning that possibility in previous messages. It was an example (for you) on how *that* would make things even less explicit. > [...] > > One may argue that silently returning None instead of raising > > AttributeError is also less explicit. > > And again, you are arguing against a misfeature which PEP 505 does not > propose. The ?. operator will not suppress AttributeErrors. > > # Wrong! No! This is not what the PEP proposes! > obj = 1.234 > assert obj?.hexx is None That is not what I meant at all! I seriously question whether you really don't understand or you're just pretending. What I meat in here was 'a?.b?.c?' returning None in case 'b' is None. > [...] > > > It isn't a first. Many existing operators use two adjacent symbols not > > > interrupted by a space: > > > > > > e.g. == <= >= != ** // << >> += -= *= etc. > > > > You say 'a == b'. You can't say 'a ?. b' (not that it matters, it > > would be less intuitive anyway). You can't because '.?' is the only > > couple of contiguous symbols requiring "something" before and after > > with no spaces in between, and that's a first in the language. > > Why do you think spaces aren't allowed? The PEP explicitly says that > the new operators can be used wherever the regular operators can be > used. > [...] > That tells me that ?. will be legal anywhere . is legal, so if x . y is > legal (and it is) so will x ?. y be legal. Yes, I forgot 'a . b' was legal - my bad. > [...] > > The difference is that 'a.b.c.d' will result in AttributeError as soon > > as something is None while 'a?.b?.c?.d' will return None instead. > > Correct. Because sometimes you want an AttributeError, and sometimes you > want None. > > You are criticising the operator for doing what it is designed and > intended to do. You might as well criticise getattr(obj, 'spam', None) > for returning None. > > If you want an AttributeError, then don't use ?. and use ordinary . > instead. Again, you missed my point. > > > Likewise the logical operators "or" and "and" are designed to > > > short-circuit. If ?? and friends are a mistake because they > > > short-circuit, why aren't "or" and "and" mistakes? > > > I'm not asking this as a rhetorical question. If you think there is a > > > reason why it is okay for or/and to short-circuit, but it is bad for ?? > > > and friends to short-circuit, then please explain why they are > > > different. I will be very happy to listen to your arguments. > > > > The argument about this is that '?.' short-circuits execution > > *silently*. > > Other short-circuit operators also short-circuit execution silently. > That's what they are designed to do. > > # This isn't what actually happens. > py> x = 0 > py> result = x and 1/x > __main__:1: UserWarning: > Short-cut operation occurred, the right hand operand was not > evaluated!!! Do not panic, this is the expected behaviour!!! > py> print(result) > 0 > > > > Instead of AttributeError you get None. You may chain ?. > > in order to lazily traverse a long tree, > > Correct, that is what it is designed to do. > > > > inadvertently assign None to > > a variable, continue code
Re: [Python-ideas] PEP 505: None-aware operators
On Tue, Jul 24, 2018 at 12:05:14AM +0200, Giampaolo Rodola' wrote:
> This:
>
> v = a?.b
>
> ...*implicitly* checks if value is not None [and continues execution].
Do you agree that:
obj.attribute
x + 1
func(arg)
explicitly looks up an attribute on obj, explicitly adds 1 to x, and
explicitly calls func with a single argument? I don't think that we have
to write COBOL-esque code to be explicit:
GET ATTRIBUTE "attribute" FROM obj
ADD 1 TO x
CALL FUNCTION func WITH ARGUMENT arg
I don't accept that the use of punctuation makes something implicit. But
if you want to argue that anything with punctuation is "implicit", then
okay, Python has lots of implicit punctuation.
By definition, ?. checks for None before doing the attribute lookup.
That is completely explicit, regardless of how it is spelled:
obj?.attribute
NULL-AWARE GET ATTRIBUTE "attribute" FROM obj
null_aware_getattr(obj, "attribute")
getattr_if_not_none(obj, "attribute")
But what certainly *is* implicity is David Mertz' suggestion for a
magical None-aware proxy:
x.attribute
The only way to tell whether that was an ordinary attribute lookup or a
none-aware lookup would be to carefully inspect x and find out whether
it was an instance of the None-aware proxy class or not.
> This
>
> v = a
> if a.b is not None:
> v = a.b
>
> ...*explicitly* checks if value is not None and continues execution.
If you are trying to match the behaviour of a?.b above, it is also
completely buggy and doesn't do what is intended.
# Equivalent of a?.b
v = a
if v is not None:
v = v.b
> If for some reason '?'[ is also going to swallow LookupError
What makes you think that ?[...] will swallow LookupError?
Please don't argue against misfeatures that the PEP doesn't propose.
Nothing in PEP 505 swallows any exceptions. Swallowing exceptions is
explicitly rejected, and swallowing LookupError isn't part of the
proposal.
[...]
> One may argue that silently returning None instead of raising
> AttributeError is also less explicit.
And again, you are arguing against a misfeature which PEP 505 does not
propose. The ?. operator will not suppress AttributeErrors.
# Wrong! No! This is not what the PEP proposes!
obj = 1.234
assert obj?.hexx is None
[...]
> > It isn't a first. Many existing operators use two adjacent symbols not
> > interrupted by a space:
> >
> > e.g. == <= >= != ** // << >> += -= *= etc.
>
> You say 'a == b'. You can't say 'a ?. b' (not that it matters, it
> would be less intuitive anyway). You can't because '.?' is the only
> couple of contiguous symbols requiring "something" before and after
> with no spaces in between, and that's a first in the language.
Why do you think spaces aren't allowed? The PEP explicitly says that
the new operators can be used wherever the regular operators can be
used:
"The maybe-dot and maybe-subscript operators are added as
trailers for atoms, so that they may be used in all the same
locations as the regular operators"
and explicitly shows the grammar changes required:
trailer: ('(' [arglist] ')' |
'[' subscriptlist ']' |
'?[' subscriptlist ']' |
'.' NAME |
'?.' NAME)
That tells me that ?. will be legal anywhere . is legal, so if x . y is
legal (and it is) so will x ?. y be legal.
[...]
> The difference is that 'a.b.c.d' will result in AttributeError as soon
> as something is None while 'a?.b?.c?.d' will return None instead.
Correct. Because sometimes you want an AttributeError, and sometimes you
want None.
You are criticising the operator for doing what it is designed and
intended to do. You might as well criticise getattr(obj, 'spam', None)
for returning None.
If you want an AttributeError, then don't use ?. and use ordinary .
instead.
> > Likewise the logical operators "or" and "and" are designed to
> > short-circuit. If ?? and friends are a mistake because they
> > short-circuit, why aren't "or" and "and" mistakes?
> > I'm not asking this as a rhetorical question. If you think there is a
> > reason why it is okay for or/and to short-circuit, but it is bad for ??
> > and friends to short-circuit, then please explain why they are
> > different. I will be very happy to listen to your arguments.
>
> The argument about this is that '?.' short-circuits execution
> *silently*.
Other short-circuit operators also short-circuit execution silently.
That's what they are designed to do.
# This isn't what actually happens.
py> x = 0
py> result = x and 1/x
__main__:1: UserWarning:
Short-cut operation occurred, the right hand operand was not
evaluated!!! Do not panic, this is the expected behaviour!!!
py> print(result)
0
> Instead of AttributeError you get None. You may chain ?.
> in order to lazily traverse a long tree,
Correct, that is what it is designed to do.
>
Re: [Python-ideas] PEP 505: None-aware operators
On Tue, Jul 24, 2018 at 2:22 AM MRAB wrote:
> >> > It
> >> > does so by introducing a brand new operator ("?") which can be spelled
> >> > in two forms ("a?.b" and "a?[b]") by using two adjacent symbols not
> >> > interrupted by any space, which is an absolute first in the Python
> >> > syntax
> >>
> >> It isn't a first. Many existing operators use two adjacent symbols not
> >> interrupted by a space:
> >>
> >> e.g. == <= >= != ** // << >> += -= *= etc.
> >
> > You say 'a == b'. You can't say 'a ?. b' (not that it matters, it
> > would be less intuitive anyway). You can't because '.?' is the only
> > couple of contiguous symbols requiring "something" before and after
> > with no spaces in between, and that's a first in the language.
>
> You _can_ say 'a ?. b', just as you _can_ say 'a . b'.
You're right. It's so uncommon I forgot this style was valid. Anyway,
as I said 'a ?. b' would be even worse the same way 'a . b' is worse
than 'a.b'. The recommended and broadly used spelling would be 'a?.b'.
--
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] PEP 505: None-aware operators
On 24 July 2018 at 08:38, Grégory Lielens wrote:
>
>
> On Tuesday, July 24, 2018 at 9:28:02 AM UTC+2, Brice Parent wrote:
>>
>> Le 24/07/2018 à 00:39, Chris Angelico a écrit :
>> > On Tue, Jul 24, 2018 at 8:22 AM, Thomas Jollans wrote:
>> ...
>> > What about:
>> >
>> > 5 < x < 10
>> >
>> > Can you add parentheses to that to "make precedence and evaluation order
>> > clear"?
>> Correct me if I'm wrong, but to my knowledge, this is just a shorthand
>> to `5 < x and x < 10`.
>
>
> I learned something here:
-5<-2<-1<=-1>-3
> True
>
> I wonder how this works, especially as < and friends have magical __
> methods... How is it expanded in tne AST?
>>> import ast
>>> m = ast.parse('-5<-2<-1<=-1>-3')
>>> ast.dump(m)
'Module(body=[Expr(value=Compare(left=UnaryOp(op=USub(),
operand=Num(n=5)), ops=[Lt(), Lt(), LtE(), Gt()],
comparators=[UnaryOp(op=USub(), operand=Num(n=2)), UnaryOp(op=USub(),
operand=Num(n=1)), UnaryOp(op=USub(), operand=Num(n=1)),
UnaryOp(op=USub(), operand=Num(n=3))]))])'
Looks like there's a Compare node that takes a list of operators - and
indeed the docs say (at
https://docs.python.org/3.7/library/ast.html#abstract-grammar)
Compare(expr left, cmpop* ops, expr* comparators)
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/
Re: [Python-ideas] PEP 505: None-aware operators
On Tuesday, July 24, 2018 at 9:28:02 AM UTC+2, Brice Parent wrote: > > Le 24/07/2018 à 00:39, Chris Angelico a écrit : > > On Tue, Jul 24, 2018 at 8:22 AM, Thomas Jollans > wrote: > ... > > What about: > > > > 5 < x < 10 > > > > Can you add parentheses to that to "make precedence and evaluation order > clear"? > Correct me if I'm wrong, but to my knowledge, this is just a shorthand > to `5 < x and x < 10`. I learned something here: >>> -5<-2<-1<=-1>-3 True I wonder how this works, especially as < and friends have magical __ methods... How is it expanded in tne AST? ___ 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 Tue, Jul 24, 2018 at 5:26 PM, Brice Parent wrote: > Le 24/07/2018 à 00:39, Chris Angelico a écrit : >> >> On Tue, Jul 24, 2018 at 8:22 AM, Thomas Jollans wrote: > > ... >> >> What about: >> >> 5 < x < 10 >> >> Can you add parentheses to that to "make precedence and evaluation order >> clear"? > > Correct me if I'm wrong, but to my knowledge, this is just a shorthand to `5 > < x and x < 10`. Not quite; the chained form will evaluate 'x' only once. It's broadly the same, but not identical. 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] 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? > > Yes, and people have done it multiple time already. I will try to make it as explicit as possible, with a terminology that some may find useful... when u have a object hierarchy linked through attributes, which -seems- the use pattern of ?. , the hierarchy is either - 1) fully regular (each attribute contains the same type of objects (same type=with the same attributes), then normal . access is what you want - 2) regular-or-None (contain same type of objects, or None). That's what ?. is for, and ?. is only for that. - 3) its partially regular (does not contain the same type of objects, some objects have more attributes than other, e.g. partial objects). - 4) its irregular (objects may be of completely different type (int, str,... and do not specailly share attributes). ?. is intended for 2). 2) and 3) can be dealed with swallowing AttributeError 4) can also be traversed swallowing AttributeError, but it's probably a very bad idea in almost all cases. I've encountered all cases, from time to time, but none is really typical of most of my code. Which is more common? not sure, I would say 3). What is sure is that 2) do not stand as hugely more common than the others, so introducing a special syntax for 2) do not please me, so +0... Now as I find ?. unpleasant to parse (personal opinion), and having grown to share the general operaror / line noise allergy mainstream in the python community, i am a firm -1 on this: too small a niche, do not bring much compared to current approach, and visual line noise. firm -1 on ?? too, it's less polemic, less visually displeasing, but even less usefull I think: it does not gain that much compared to a more general ternary. As the pymaybe/this thread cover 2) and 3), and do it without any change to python, I find it better. No change > lib change > backward compatible object change - like dict becoming ordered, or None triggering NoneAttributeError(AttributeError) > syntax change (expecially a bunch of linenoisy operators). Now I will stop for a while here, arguments have become circular, proponents and opponents have exposed their view, but mostly proponents have provided very few additional information for a while, especially about real use cases, despite a few requests. We still do not know what motivated the proposal..We had to guess (JSON). Even the PEP do not say, it provide a set of real world example from the standard library, which is admirable but different. And personaly, while am very thankful for providing those concrete examples, I find them unconvicing: the code before is usually fine and improved little by the new operators. Sometimes it's worse: only slightly shorter and less clear. ___ 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
Le 24/07/2018 à 00:39, Chris Angelico a écrit : On Tue, Jul 24, 2018 at 8:22 AM, Thomas Jollans wrote: ... What about: 5 < x < 10 Can you add parentheses to that to "make precedence and evaluation order clear"? Correct me if I'm wrong, but to my knowledge, this is just a shorthand to `5 < x and x < 10`. Making the precedence and evaluation order clear doesn't necessarily rely on adding parenthesis, it may rely on expanding the expression (you may add parenthesis after that, if you think it's needed). ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
