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

Re: Method Chaining

On Fri, 17 Jun 2016 12:02 pm, Lawrence D’Oliveiro wrote: > 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 gra

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

On 22/11/2013 11:26, 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 rather than self. The class needs to be

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

On Fri, 22 Nov 2013 16:20:03 +0100, Peter Otten wrote: > 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 >>> p

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

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. > > There's not really a lot of difference That

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

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. There's not really a lot of difference between: obj = MyClass() obj.spam

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

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 rather than > self. The class needs to be des

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 >

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