> > We could argue about how intuitive or not these operators are, but they > are used in other languages, so they clearly aren't completely unintuitive.
Other languages are other languages. Other languages use the "<condition> ? <expr_a> : <expr_b>" form of the the ternary operator. That doesn't mean we should adopt that into Python. Being visually obtrusive would help a great deal. Unfortunately I don't > think it is visually obtrusive in the ?. and ?[] operators. My argument about visual obtrusiveness is in the context of me claiming that python attempts to mimic natural language to achieve readability, others countering that `person.name` is not how periods are used in natural languages, so using other symbols in unintuitive ways is perfectly fine. My point is that '.' is unobtrusive, so it's not *that* different from `person name' which isn't *that* different from `person's name`. The '?' symbol is most definitely more visually obtrusive than a simple '.' because it takes up more space. We could conceivably have a dunder method that None implemented as > returning the other argument and object implemented as returning itself. > I'm not really convinced that it's worth it, though. Yes, I thought of that and came to the same conclusion. It's my understanding that None may not be an actual object, but a special memory location. I'm not sure though and didn't look it up. Really? Quick straw poll: how often do people care how in-place operators > are implemented? The point I was trying to make is that it doesn't behave or compose like other expressions. As you said, "?" is not an operator, so "a?.b" clearly can't break down > into "a? .b". The problem is that '.' IS a stand-alone operator, so it's natural to visually parse `<expr>.b` as `<expr> .b`, but adding '?.' causes double takes, more mental load, general interruption of the flow of reading. It also sets up the later discussion of other possible uses of the '?' symbol that may or may not have more merit. Um. How is that supposed to parse? "person[0]" has already been evaluated > by the time the "?" operator gets anywhere near it. It parses by placing the '?' operator high in the order of operations; like I said. Do I really need to explain how order of operations works? Why not indeed. I haven't seen any convincing use cases (and nor has the > PEP, though I doubt Steve was looking for them), but they aren't inherently > any more weird than "?." and "?[]". It seems like a natural extension. It also seems like a lot to add for something as trivial as None handling. While my immediate reaction is "yuk" Is that more legit than my reaction to '?.' and '?[]'? At least in this case, the '?' comes at the end of a clause... your use of "?" does not conflict with any use in the PEP, so this is a red > herring. I suppose it doesn't *technically* conflict, but it would lead to some beautiful code, like: lambda data=a?.b?[0]?: data?.d On Fri, Jul 27, 2018 at 7:00 AM, Rhodri James <rho...@kynesim.co.uk> wrote: > On 26/07/18 22:28, Abe Dillon wrote: > >> The readability issue isn't just a matter of a new set of symbols to >> learn. >> It isn't even that the symbols are used in a non-intuitive way (though >> that >> doesn't help). >> > > We could argue about how intuitive or not these operators are, but they > are used in other languages, so they clearly aren't completely unintuitive. > > It's not even that the question mark, unlike the dot, is >> very visually obtrusive (which also doesn't help). >> > > Being visually obtrusive would help a great deal. Unfortunately I don't > think it is visually obtrusive in the ?. and ?[] operators. > > It also screws with the >> grammar in an unexpected way. I would be fine with something like: >> >> def func(data=None): >> data ?= [] >> ... >> >> If there were some corresponding dunder method to implement that behavior, >> but it's not clear to me that such a thing is possible. >> > > We could conceivably have a dunder method that None implemented as > returning the other argument and object implemented as returning itself. > I'm not really convinced that it's worth it, though. > > If it isn't, that >> would make `?=` (or '??=' though I don't see the need for double '?'s) >> > > Because it's the in-place version of "??", obviously. > > a >> special statement, a special case that someone who's familiar with how >> other in-place operators work, would be thrown for a loop. >> > > Really? Quick straw poll: how often do people care how in-place operators > are implemented? > > The other use >> cases look like they break down in a different manner than they actually >> do: >> >> person?.name >> >> looks like it would break down similar to >> >> person().name >> >> but it doesn't because '?' by itself is not an operator. >> similarly: >> >> person?[0] >> >> looks like it would break down similar to >> >> person()[0] >> >> but again, the operator is '?[...]' not '?' >> > > Sorry, not buying this one. As you said, "?" is not an operator, so > "a?.b" clearly can't break down into "a? .b". This all rather feels like > you are trying to find justifications for not liking these operators rather > just saying "I don't like them," and frankly I'd respect you more if you > just said "I don't like them." > > (For the record, I don't like most of them. There are clear use cases for > "??" and "??=", but the use cases I've seen for "?." and "?[]" aren't > convincing to me.) > > This also raises the question of other operators that could be made null >> aware. Why not: >> >> func?() >> >> ?-num >> >> ?~num >> >> num ?+ other >> >> Why not other reflective operators? >> >> num ?+= other >> > > Why not indeed. I haven't seen any convincing use cases (and nor has the > PEP, though I doubt Steve was looking for them), but they aren't inherently > any more weird than "?." and "?[]". > > I think this could be helped by simply making '?' an operator with a very >> high order of operations, so that pretty-much any expression on the LHS is >> guarded for 'NoneType' AttributeErrors: >> >> val = person[0]? >> val = person.name? >> > > Um. How is that supposed to parse? "person[0]" has already been > evaluated by the time the "?" operator gets anywhere near it. Unless you > are proposing some major surgery to the parser (which I'm pretty sure isn't > going to happen), this has no chance of getting through. Good thing too, > because it's a lot more surprising than the alternatives. > > I also disagree with the idea that None is special enough to warrant such >> special behavior. There are other special None-like objects (as David >> Mertz >> pointed out) like NaN and custom place-holders for cases where None is a >> valid argument. >> > > NaN isn't used like None, though, and custom sentinels aren't that common. > > Yet another possibility is to make '?' signify a parameter who's default >> value is an expression that should be evaluated when necessary: >> >> def func(data: List = []?): >> ... >> >> That gets closer to another often requested feature: delayed expression >> evaluation (as Steve D'Aprano pointed out). >> So there are other, possibly better uses for the '?' symbol. It's >> something >> that needs to be carefully considered. >> > > While my immediate reaction is "yuk", your use of "?" does not conflict > with any use in the PEP, so this is a red herring. > > -- > 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 mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
