Re: Method Chaining

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, Joo

Re: Method Chaining

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: wit

Re: Method Chaining

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

Re: Method Chaining

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?

Re: Method Chaining

On 18 June 2016 at 23:47, Ethan Furman 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 d

Re: Method Chaining

Rustom Mody writes: > On Saturday, June 18, 2016 at 5:34:30 PM UTC+5:30, Pete Forman wrote: >> Rustom Mody writes: >> [snip] >> >> One subtle difference between your two citations is that VB uses a >> leading dot. Might that lessening of ambiguity enable a future Python to >> allow this? >> >> c

Re: Method Chaining

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

Re: Method Chaining

Joonas Liik writes: > On 18 June 2016 at 15:04, Pete Forman wrote: >> Rustom Mody writes: >> >>> On Friday, June 17, 2016 at 2:58:19 PM UTC+5:30, Steven D'Aprano wrote: On Fri, 17 Jun 2016 06:13 pm, Ned Batchelder wrote: > To me, it's a toss-up. The chained version is nice in tha

Re: Method Chaining

On Saturday, June 18, 2016 at 5:34:30 PM UTC+5:30, Pete Forman wrote: > Rustom Mody writes: > > > On Friday, June 17, 2016 at 2:58:19 PM UTC+5:30, Steven D'Aprano wrote: > >> On Fri, 17 Jun 2016 06:13 pm, Ned Batchelder wrote: > >> > >> > To me, it's a toss-up. The chained version is nice in that

Re: Method Chaining

On 18 June 2016 at 15:04, Pete Forman wrote: > Rustom Mody writes: > >> On Friday, June 17, 2016 at 2:58:19 PM UTC+5:30, Steven D'Aprano wrote: >>> On Fri, 17 Jun 2016 06:13 pm, Ned Batchelder wrote: >>> >>> > To me, it's a toss-up. The chained version is nice in that it >>> > removes the repetit

Re: Method Chaining

Rustom Mody writes: > On Friday, June 17, 2016 at 2:58:19 PM UTC+5:30, Steven D'Aprano wrote: >> On Fri, 17 Jun 2016 06:13 pm, Ned Batchelder wrote: >> >> > To me, it's a toss-up. The chained version is nice in that it >> > removes the repetition of "g". But the unchained version is more >> > exp

Re: Method Chaining

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

Re: Method Chaining

On Fri, Jun 17, 2016, 6:44 PM Michael Selik wrote: > > > On Fri, Jun 17, 2016, 6:42 PM Lawrence D’Oliveiro > wrote: > >> On Saturday, June 18, 2016 at 1:35:06 AM UTC+12, Michael Selik wrote: >> >> > The chained version looks like each method is returning a modified >> > copy. >> >> As opposed to

Re: Method Chaining

On Fri, Jun 17, 2016, 6:42 PM Lawrence D’Oliveiro wrote: > On Saturday, June 18, 2016 at 1:35:06 AM UTC+12, Michael Selik wrote: > > > The chained version looks like each method is returning a modified > > copy. > > As opposed to a modified original? > Correct. Read the rationale for list.sort r

Re: Method Chaining

On Saturday, June 18, 2016 at 1:35:06 AM UTC+12, Michael Selik wrote: > The chained version looks like each method is returning a modified > copy. As opposed to a modified original? -- https://mail.python.org/mailman/listinfo/python-list

Re: Method Chaining

On Saturday, June 18, 2016 at 4:48:30 AM UTC+12, Rustom Mody wrote: > One thing about python OOP that irritates me is the 'self.' clutter. > With a Pascal/VB style with-statement its naturally taken care of I used to use “with”-statements back in my Pascal days. Then I had this nasty bug where a

Re: Method Chaining

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”.

Re: Method Chaining

On Friday, June 17, 2016 at 2:58:19 PM UTC+5:30, Steven D'Aprano wrote: > On Fri, 17 Jun 2016 06:13 pm, Ned Batchelder wrote: > > > To me, it's a toss-up. The chained version is nice in that it removes the > > repetition of "g". But the unchained version is more explicit, and avoids > > the awkw

Re: Method Chaining

On Fri, Jun 17, 2016 at 5:31 AM Steven D'Aprano wrote: > (g.move_to((p1 + p2a) / 2) > .line_to(p1 + (p2 - p1) * frac) > .line_to((p1 + p1a) / 2) > .stroke() > ) > > the parens and indentation more clearly mark this chunk of code as a > unit. I prefer reserving indentation for where they

Re: Method Chaining

On Fri, 17 Jun 2016 06:13 pm, Ned Batchelder wrote: > To me, it's a toss-up. The chained version is nice in that it removes the > repetition of "g". But the unchained version is more explicit, and avoids > the awkward parenthesis. > > I think I would lean toward the unchained version. Clearly

Re: Method Chaining

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. What if it had been the_context.move_to((p1 + p2a) / 2) the_context.line_to(p1 + (p2 - p1) * frac) the_context.line_to((p1 + p1a) /

Re: Method Chaining

Lawrence D’Oliveiro writes: > 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. > > What if it had been > > the_context.move_to((p1 + p2a) / 2) > the_context.line_to(p1 + (p2 - p1) * fr

Re: Method Chaining

On Friday, June 17, 2016 at 12:37:14 AM UTC-4, Lawrence D’Oliveiro wrote: > On Friday, June 17, 2016 at 4:24:24 PM UTC+12, Michael Selik wrote: > > On Thu, Jun 16, 2016 at 10:53 PM Lawrence D’Oliveiro wrote: > > > > > Example from , > > > c

Re: Method Chaining

On Friday, June 17, 2016 at 4:24:24 PM UTC+12, Michael Selik wrote: > On Thu, Jun 16, 2016 at 10:53 PM Lawrence D’Oliveiro wrote: > > > Example from , > > concisely expressing a complex drawing sequence: > > > > (g > > .move_to(

Re: Method Chaining

On Thu, Jun 16, 2016 at 10:53 PM Lawrence D’Oliveiro wrote: > Example from , > concisely expressing a complex drawing sequence: > > (g > .move_to((p1 + p2a) / 2) > .line_to(p1 + (p2 - p1) * frac) > .line_to((p1

Method Chaining

Some kinds of objects often receive a whole lot of method calls in sequence. In these situations, it is handy if each method call ends with “return self”, so that you can chain the calls together. This is particularly common with graphics APIs, for instance. Example from

Re: Method Chaining

might find this simple adaptor useful: http://code.activestate.com/recipes/578770-method-chaining/ -- Steven -- https://mail.python.org/mailman/listinfo/python-list

Re: Method chaining

On 24/11/2013 14:27, Steven D'Aprano wrote: On Sat, 23 Nov 2013 19:53:32 +, Rotwang wrote: On 22/11/2013 11:26, Steven D'Aprano wrote: A frequently missed feature is the ability to chain method calls: [...] chained([]).append(1).append(2).append(3).reverse().append(4) => returns [3, 2, 1

Re: Method chaining

On Sat, 23 Nov 2013 19:53:32 +, Rotwang wrote: > On 22/11/2013 11:26, Steven D'Aprano wrote: >> A frequently missed feature is the ability to chain method calls: [...] >> chained([]).append(1).append(2).append(3).reverse().append(4) => >> returns [3, 2, 1, 4] > > That's pretty cool. However,

Re: Method chaining

On 24/11/2013 00:28, Rotwang wrote: [...] This solves some of the problems in my earlier effort. It keeps a copy of the original object, Sorry, I meant that it keeps a reference to the original object. -- https://mail.python.org/mailman/listinfo/python-list

Re: Method chaining

On 23/11/2013 19:53, Rotwang wrote: [...] That's pretty cool. However, I can imagine it would be nice for the chained object to still be an instance of its original type. How about something like this: [crap code] The above code isn't very good - it will only work on types whose constructor wi

Re: Method chaining

lass needs to be designed with method chaining in mind before it will work, and most Python classes follow the lead of built-ins like list and have mutator methods return None rather than self. Here's a proof-of-concept recipe to adapt any object so that it can be used for chaining method call

Re: Method chaining

OK, that one is disgusting... Anyway, I'd like to see a sequence of method names taken from actual code that profits from this chaining pattern. Actually, wx.lib.agw uses this a lot. Especially for AuiPaneInfo: http://www.wxpython.org/docs/api/wx.aui.AuiPaneInfo-class.html All right, this

Re: Method chaining

Wolfgang Maier biologie.uni-freiburg.de> writes: > > Steven D'Aprano pearwood.info> writes: > > > # With chaining > > thing = func(MyClass().spam().eggs().cheese(), > > MyClass().aardvark(), > > OtherClass().fe().fi().fo().fum(), > > ) > > do_stuff_with(

Re: Method chaining

Steven D'Aprano pearwood.info> writes: > # With chaining > thing = func(MyClass().spam().eggs().cheese(), > MyClass().aardvark(), > OtherClass().fe().fi().fo().fum(), > ) > do_stuff_with(thing) > > versus: > > # Without chaining > temp1 = MyClass() > temp

Re: Method chaining

es. >> Chained method calls is idiomatic in some languages. > > Languages with mutable objects? Yes. It's a "Design Pattern" applicable to any language with mutator methods. Here are three examples in C#, Java and Ruby: http://mrbool.com/fluent-interface-and-met

Re: Method chaining

Op 22-11-13 16:20, Peter Otten schreef: > Steven D'Aprano wrote: > >> On Fri, 22 Nov 2013 13:08:03 +0100, Peter Otten wrote: >> >>> These things are nice to write as long as you omit the gory details, but >>> personally I don't want to see the style it favours in my or other >>> people's code. >>

Re: Method chaining

e-effects, rather than it being a series of distinct objects. But in > my opinion that flaw is a very minor one. > > The nice thing about using an explicit method chaining call rather than > building your class to support it by default is that the initial call to > the adaptor sign

Re: Method chaining

On Fri, 22 Nov 2013 07:34:53 -0500, Terry Reedy wrote: > On 11/22/2013 6:26 AM, Steven D'Aprano wrote: >> A frequently missed feature is the ability to chain method calls: >> >> x = [] >> x.append(1).append(2).append(3).reverse().append(4) => x now equals [3, >> 2, 1, 4] >> >> >> This doesn't work

Re: Method chaining

ach method call is being used only for its side-effects, rather than it being a series of distinct objects. But in my opinion that flaw is a very minor one. The nice thing about using an explicit method chaining call rather than building your class to support it by default is that the initial call

Re: Method chaining

On 11/22/2013 6:26 AM, Steven D'Aprano wrote: A frequently missed feature is the ability to chain method calls: x = [] x.append(1).append(2).append(3).reverse().append(4) => x now equals [3, 2, 1, 4] This doesn't work with lists, as the methods return None True for the 7 pure mutation method

Re: Method chaining

er than > self. The class needs to be designed with method chaining in mind before > it will work, and most Python classes follow the lead of built-ins like > list and have mutator methods return None rather than self. > > Here's a proof-of-concept recipe to adapt any

Re: Method chaining

On Fri, Nov 22, 2013 at 10:26 PM, Steven D'Aprano wrote: > if callable(obj): > def selfie(*args, **kw): > # Call the method just for side-effects, return self. > _ = obj(*args, **kw) > return self > return selfie >

Method chaining

A frequently missed feature is the ability to chain method calls: x = [] x.append(1).append(2).append(3).reverse().append(4) => x now equals [3, 2, 1, 4] This doesn't work with lists, as the methods return None rather than self. The class needs to be designed with method chaining in min

Re: Method chaining on decorator got SyntaxError

alex23 wrote: > Makoto Kuwata wrote: >> I'm sad about this restriction because: >> >>     @recipe.product('*.html').ingreds('$(1).rst') >>     def file_html(c): >>         # do something >> >> is enough simple and more readable than: >> >>     @recipe.product('*.html') >>     @recipe.ingreds('$(

Re: Method chaining on decorator got SyntaxError

Makoto Kuwata wrote: > I'm sad about this restriction because: > >     @recipe.product('*.html').ingreds('$(1).rst') >     def file_html(c): >         # do something > > is enough simple and more readable than: > >     @recipe.product('*.html') >     @recipe.ingreds('$(1).rst') >     def file_html

Re: Method chaining on decorator got SyntaxError

On Thu, Feb 17, 2011 at 11:40 AM, MRAB wrote: > On 17/02/2011 01:55, Makoto Kuwata wrote: >> >> Thank you MRAB, >> >> On Thu, Feb 17, 2011 at 8:49 AM, MRAB  wrote: >>> >>> You may want to read the discussion at: >>> >>> >>> https://groups.google.com/group/python-ideas/browse_thread/thread/1eebf486

Re: Method chaining on decorator got SyntaxError

On 17/02/2011 01:55, Makoto Kuwata wrote: Thank you MRAB, On Thu, Feb 17, 2011 at 8:49 AM, MRAB wrote: You may want to read the discussion at: https://groups.google.com/group/python-ideas/browse_thread/thread/1eebf486969c39a1/?hl=en -- I can't figure out what is the point or conclusion of t

Re: Method chaining on decorator got SyntaxError

Thank you MRAB, On Thu, Feb 17, 2011 at 8:49 AM, MRAB wrote: > You may want to read the discussion at: > > https://groups.google.com/group/python-ideas/browse_thread/thread/1eebf486969c39a1/?hl=en > -- I can't figure out what is the point or conclusion of that discussion. Is there any technical

Re: Method chaining on decorator got SyntaxError

On 16/02/2011 23:25, Makoto Kuwata wrote: Hi, I have a question about decorator. I tried the following example and got Syntax Error. class deco(object): def __init__(self, name): self._name = name def foo(self, value): self._foo = value

Method chaining on decorator got SyntaxError

Hi, I have a question about decorator. I tried the following example and got Syntax Error. class deco(object): def __init__(self, name): self._name = name def foo(self, value): self._foo = value return self def __call__(self, func):