Chris Angelico wrote:
> It may be true, but it isn't better IMO - especially not for the
> abstract. It's unnecessarily pedantic. The current wording isn't
> ambiguous, because infinite recursion makes no sense.
Thank you for this. Please take a look and compare
https://www.python.org/dev/peps/p
On Thu, Aug 2, 2018 at 12:04 AM, Jonathan Fine wrote:
> Hi Steve
>
> Thank you for your reply.
>
> We're discussing the abstract to PEP 505, which writes
> ===
> The "None-aware attribute access" operator ?. ("maybe dot") evaluates
> the complete expression if the left hand side evaluates to a va
Hi Steve
Thank you for your reply.
We're discussing the abstract to PEP 505, which writes
===
The "None-aware attribute access" operator ?. ("maybe dot") evaluates
the complete expression if the left hand side evaluates to a value
that is not None
===
I gave (42).str as an example. I wrote
> I
On Wed, Aug 01, 2018 at 11:03:05AM +0100, Jonathan Fine wrote:
[...]
> After my last post, you wrote
> > None.?__str__
> > produces None, even though None has a __str__ attribute.
>
> This surprises me. But I think it follows from the rules in
> https://www.python.org/dev/peps/pep-0505/#the-maybe
Hi Stephan
You wrote
> Let me stand up and claim that if a chain consists *only* of None-coalescing
> operations, then breaking up the chain by adding parentheses does not
> matter, ever.
You missed a post I made, 17 minutes before yours. I then believed
that PEP 505 specified.
#1. (None ?. dne
On Wed, Aug 1, 2018 at 7:09 PM, Jonathan Fine wrote:
> Hi Chris
>
> We're discussing.
>> 10) a ?. b ?. c
>> 11) (a ?. b) ?. c
>
> I asked
>> So, are there any values of 'a' for which #10 and #11 don't give the
>> same result?
>
> You replied
>> I'm not prepared to put my neck out and say "They are
Op wo 1 aug. 2018 11:10 schreef Jonathan Fine :
>
>
> You're right to be cautious. My understanding of PEP 505 is that
> #13. a ?. b ?. __str__
> #14. (a ?. b) ?. __str__
> are not equivalent. The first is None, and the other is None.__str__.
> That looks like a gotcha.
>
No.
None.?__str__
prod
Op wo 1 aug. 2018 10:50 schreef Chris Angelico :
> On Wed, Aug 1, 2018 at 6:45 PM, Jonathan Fine wrote:
> > Hi Chris
> >
> > Thank you for your reply. I think we're making good progress.
> >
> > You wrote
> >
> >>> 10) a ?. b ?. c
> >>> 11) (a ?. b) ?. c
> >>
> >> I would parse those differently,
Hi Chris
We're discussing.
> 10) a ?. b ?. c
> 11) (a ?. b) ?. c
I asked
> So, are there any values of 'a' for which #10 and #11 don't give the
> same result?
You replied
> I'm not prepared to put my neck out and say "They are absolutely
> identical" and have people jump on me with some technica
On Wed, Aug 1, 2018 at 6:45 PM, Jonathan Fine wrote:
> Hi Chris
>
> Thank you for your reply. I think we're making good progress.
>
> You wrote
>
>>> 10) a ?. b ?. c
>>> 11) (a ?. b) ?. c
>>
>> I would parse those differently, but you may be right that they'll
>> always have the same final result.
Hi Chris
Thank you for your reply. I think we're making good progress.
You wrote
>> 10) a ?. b ?. c
>> 11) (a ?. b) ?. c
>
> I would parse those differently, but you may be right that they'll
> always have the same final result.
I'd like to get some certainty on this. I'm not aware of any value
On Wed, Aug 1, 2018 at 6:00 PM, Jonathan Fine wrote:
> Hi Chris
>
> You wrote:
>
>> Oh. The equivalent ones are #1 and #2, and #7 and #8, where this
>> proposal doesn't change anything. Otherwise, they're not equivalent.
>
> Are you sure. I'd also expect #10 and #11 to be equivalent.
>
> By the wa
Hi Chris
You wrote:
> Oh. The equivalent ones are #1 and #2, and #7 and #8, where this
> proposal doesn't change anything. Otherwise, they're not equivalent.
Are you sure. I'd also expect #10 and #11 to be equivalent.
By the way, there's a typo in my examples: 11) (a .? b) ?. c
--
Jonathan
__
On Wed, Aug 1, 2018 at 5:40 PM, Jonathan Fine wrote:
> Hi Chris
>
> Thank you for your prompt reply. You wrote
>
>> Incorrect. The short-circuiting behaviour ends at any sort of
>> grouping. It's like how "a < b < c" is not equivalent to "(a < b) <
>> c", nor to "a < (b < c)".
>
> You've told me t
Hi Chris
Thank you for your prompt reply. You wrote
> Incorrect. The short-circuiting behaviour ends at any sort of
> grouping. It's like how "a < b < c" is not equivalent to "(a < b) <
> c", nor to "a < (b < c)".
You've told me that my answer B is wrong. But you've not provided your
correct ans
On Wed, Aug 1, 2018 at 5:29 PM, Jonathan Fine wrote:
> Hi All
>
> I have two further questions. I'm keen to clarify what is the
> behaviour specified by PEP 505. I'm not, at this time, interested in
> why and how PEP 505 specifies behaviour. I just wish, through explicit
> examples, to clarify the
Hi All
I have two further questions. I'm keen to clarify what is the
behaviour specified by PEP 505. I'm not, at this time, interested in
why and how PEP 505 specifies behaviour. I just wish, through explicit
examples, to clarify the behaviour that is specified.
Here 'a' is an identifier. Conside
17 matches
Mail list logo