Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #110043 > unrolled thread

Method Chaining

Back to article view | Back to comp.lang.python

Contents

  Method Chaining Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-16 19:02 -0700
    Re: Method Chaining Steven D'Aprano <steve@pearwood.info> - 2016-06-17 12:39 +1000
    Re: Method Chaining Michael Selik <michael.selik@gmail.com> - 2016-06-17 04:23 +0000
      Re: Method Chaining Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-16 21:37 -0700
        Re: Method Chaining Ned Batchelder <ned@nedbatchelder.com> - 2016-06-17 01:13 -0700
          Re: Method Chaining Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-17 01:38 -0700
            Re: Method Chaining Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-06-17 11:45 +0300
          Re: Method Chaining Steven D'Aprano <steve@pearwood.info> - 2016-06-17 19:28 +1000
            Re: Method Chaining Michael Selik <michael.selik@gmail.com> - 2016-06-17 13:34 +0000
              Re: Method Chaining Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-17 15:26 -0700
                Re: Method Chaining Michael Selik <michael.selik@gmail.com> - 2016-06-17 22:45 +0000
                Re: Method Chaining Michael Selik <michael.selik@gmail.com> - 2016-06-17 23:10 +0000
            Re: Method Chaining Rustom Mody <rustompmody@gmail.com> - 2016-06-17 09:48 -0700
              Re: Method Chaining Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-17 15:25 -0700
              Re: Method Chaining Pete Forman <petef4+usenet@gmail.com> - 2016-06-18 13:04 +0100
                Re: Method Chaining Joonas Liik <liik.joonas@gmail.com> - 2016-06-18 17:05 +0300
                  Re: Method Chaining Pete Forman <petef4+usenet@gmail.com> - 2016-06-18 16:42 +0100
                Re: Method Chaining Rustom Mody <rustompmody@gmail.com> - 2016-06-18 08:35 -0700
                  Re: Method Chaining Pete Forman <petef4+usenet@gmail.com> - 2016-06-19 11:16 +0100
                Re: Method Chaining Ethan Furman <ethan@stoneleaf.us> - 2016-06-18 13:47 -0700
                Re: Method Chaining Joonas Liik <liik.joonas@gmail.com> - 2016-06-19 14:56 +0300
                Re: Method Chaining Ethan Furman <ethan@stoneleaf.us> - 2016-06-19 08:01 -0700
                Re: Method Chaining Michael Torrie <torriem@gmail.com> - 2016-06-19 09:14 -0600
                Re: Method Chaining Ethan Furman <ethan@stoneleaf.us> - 2016-06-19 08:56 -0700
                  Re: Method Chaining Rustom Mody <rustompmody@gmail.com> - 2016-06-19 09:03 -0700
          Re: Method Chaining Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-17 15:22 -0700
            Re: Method Chaining Ned Batchelder <ned@nedbatchelder.com> - 2016-06-17 17:02 -0700

Page 2 of 2 — ← Prev page 1 [2]

#110138

On 18 June 2016 at 23:47, Ethan Furman <ethan@stoneleaf.us> wrote:
> On 06/18/2016 07:05 AM, Joonas Liik wrote:
>>
>> On 18 June 2016 at 15:04, Pete Forman wrote:
>
>
>>> with obj:
>>>      .a = 1                # equivalent to obj.a = 1
>>>      .total = .total + 1   # obj.total = obj.total + 1
>>
>>
>> the leading dot does not resolve the ambiguity that arises from:
>>
>> with ob_a:
>>      with ob_b:
>>          .attr_c = 42 # which object are we modifying right now?
>
>
> The innermost one.  Why would it be anything else?
>
> --
> ~Ethan~
>
> --
> https://mail.python.org/mailman/listinfo/python-list

What if ob_b does not have attribute attr_c but ob_a does?

This may be simple for a computer to solve - try looking it up on ob_b
and fall back to ob_a if ob_b has no such attr..  but it is hard(er)
to reason about for a human. You need to know about the inner
structure of ob_b. not an issue for the person who writes it at first
(unless 2 months have passed ) but a real pain if you are seeing that
bit of code for the first time or are not intimately familiar with
what ob_b is.

Not unsolvable ofc, but makes it easier for obscure bugs to hide.

[toc] | [prev] | [next] | [standalone]

#110142

On 06/19/2016 04:56 AM, Joonas Liik wrote:
> On 18 June 2016 at 23:47, Ethan Furman wrote:
>> On 06/18/2016 07:05 AM, Joonas Liik wrote:

>>> the leading dot does not resolve the ambiguity that arises from:
>>>
>>> with ob_a:
>>>       with ob_b:
>>>           .attr_c = 42 # which object are we modifying right now?
>>
>>
>> The innermost one.  Why would it be anything else?
>
> What if ob_b does not have attribute attr_c but ob_a does?

Good question.  I would say that _only_ the innermost with object is 
searched, and if it doesn't have the requested attribute an 
AttributeError is raised.  Otherwise, as you say, it could be a 
nightmare to maintain.

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#110143

On 06/19/2016 09:01 AM, Ethan Furman wrote:
> On 06/19/2016 04:56 AM, Joonas Liik wrote:
>> On 18 June 2016 at 23:47, Ethan Furman wrote:
>>> On 06/18/2016 07:05 AM, Joonas Liik wrote:
> 
>>>> the leading dot does not resolve the ambiguity that arises from:
>>>>
>>>> with ob_a:
>>>>       with ob_b:
>>>>           .attr_c = 42 # which object are we modifying right now?
>>>
>>>
>>> The innermost one.  Why would it be anything else?
>>
>> What if ob_b does not have attribute attr_c but ob_a does?
> 
> Good question.  I would say that _only_ the innermost with object is 
> searched, and if it doesn't have the requested attribute an 
> AttributeError is raised.  Otherwise, as you say, it could be a 
> nightmare to maintain.

But that wouldn't work either because it would make it impossible to
*set* attributes on an object.

If ob_a had attr_c but object ob_b did not, should it set the attribute
on ob_b or overwrite the attribute on ob_a?

Python's dynamic nature just doesn't lend itself to this kind of ambiguity.

[toc] | [prev] | [next] | [standalone]

#110145

On 06/19/2016 08:14 AM, Michael Torrie wrote:
> On 06/19/2016 09:01 AM, Ethan Furman wrote:
>> On 06/19/2016 04:56 AM, Joonas Liik wrote:
>>> On 18 June 2016 at 23:47, Ethan Furman wrote:
>>>> On 06/18/2016 07:05 AM, Joonas Liik wrote:

>>>>> the leading dot does not resolve the ambiguity that arises from:
>>>>>
>>>>> with ob_a:
>>>>>        with ob_b:
>>>>>            .attr_c = 42 # which object are we modifying right now?
>>>>
>>>>
>>>> The innermost one.  Why would it be anything else?
>>>
>>> What if ob_b does not have attribute attr_c but ob_a does?
>>
>> Good question.  I would say that _only_ the innermost with object is
>> searched, and if it doesn't have the requested attribute an
>> AttributeError is raised.  Otherwise, as you say, it could be a
>> nightmare to maintain.
>
> But that wouldn't work either because it would make it impossible to
> *set* attributes on an object.

Sure it would, just like any 'this_thing.whatever = 9' works just fine 
if 'this_thing' doesn't already a `whatever` attribute.

The only thing that would change is being able to omit the 'this_thing' 
portion; if you want to access an earlier 'with' obj, then you must be 
explicit:

   with ob_a:
      with ob_b:
         ob_a.whatever = 9
         .something_else = 10

> Python's dynamic nature just doesn't lend itself to this kind of ambiguity.

This is no more ambiguous than any other nested structure and, in some 
cases, even simpler.

--
~Ethan

[toc] | [prev] | [next] | [standalone]

#110146

On Sunday, June 19, 2016 at 9:26:54 PM UTC+5:30, Ethan Furman wrote:
> On 06/19/2016 08:14 AM, Michael Torrie wrote:
> > On 06/19/2016 09:01 AM, Ethan Furman wrote:
> >> On 06/19/2016 04:56 AM, Joonas Liik wrote:
> >>> On 18 June 2016 at 23:47, Ethan Furman wrote:
> >>>> On 06/18/2016 07:05 AM, Joonas Liik wrote:
> 
> >>>>> the leading dot does not resolve the ambiguity that arises from:
> >>>>>
> >>>>> with ob_a:
> >>>>>        with ob_b:
> >>>>>            .attr_c = 42 # which object are we modifying right now?
> >>>>
> >>>>
> >>>> The innermost one.  Why would it be anything else?
> >>>
> >>> What if ob_b does not have attribute attr_c but ob_a does?
> >>
> >> Good question.  I would say that _only_ the innermost with object is
> >> searched, and if it doesn't have the requested attribute an
> >> AttributeError is raised.  Otherwise, as you say, it could be a
> >> nightmare to maintain.
> >
> > But that wouldn't work either because it would make it impossible to
> > *set* attributes on an object.
> 
> Sure it would, just like any 'this_thing.whatever = 9' works just fine 
> if 'this_thing' doesn't already a `whatever` attribute.
> 
> The only thing that would change is being able to omit the 'this_thing' 
> portion; if you want to access an earlier 'with' obj, then you must be 
> explicit:
> 
>    with ob_a:
>       with ob_b:
>          ob_a.whatever = 9
>          .something_else = 10
> 
> > Python's dynamic nature just doesn't lend itself to this kind of ambiguity.
> 
> This is no more ambiguous than any other nested structure and, in some 
> cases, even simpler.

Yes to be clear the idea is mostly syntactic:
with ob_a :
 .some ...
 .other ... (maybe set or get ie lhs or rhs)

desugars to
ob_a.some ...
ob_a.other ...

And for an outer with the reach does not include and inner with
Just as in C if you have a nested switch the scope of the case-labels of the
outer excludes the inner

[toc] | [prev] | [next] | [standalone]

#110060

On Friday, June 17, 2016 at 8:13:50 PM UTC+12, Ned Batchelder wrote:

> But the unchained version is more explicit, and avoids
> the awkward parenthesis.

You think of parentheses as “awkward”? Because elsewhere I see people recommending you put them in even if you don’t need them, for “clarity”.

[toc] | [prev] | [next] | [standalone]

#110070

On Friday, June 17, 2016 at 6:23:12 PM UTC-4, Lawrence D’Oliveiro wrote:
> On Friday, June 17, 2016 at 8:13:50 PM UTC+12, Ned Batchelder wrote:
> 
> > But the unchained version is more explicit, and avoids
> > the awkward parenthesis.
> 
> You think of parentheses as “awkward”? Because elsewhere I see people recommending you put them in even if you don’t need them, for “clarity”.

Parentheses are used for a number of different purposes. It won't be
possible to make a sweeping statement about them everywhere.

I use "extra" parentheses to make operator application order clearer
where it isn't obvious to me, for example.

--Ned.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web