Mailman 3 January 2017 - Python-ideas

Re: [Python-ideas] Is it Python 3 yet?
by Paul Moore Jan. 28, 2017

Jan. 28, 2017

Resending because Google Groups handling of mailing lists is broken :-( Sorry to anyone who gets double posts. On 27 January 2017 at 08:39, Paul Moore <p.f.moore(a)gmail.com> wrote: > On 27 January 2017 at 06:22, Denis Akhiyarov <denis.akhiyarov(a)gmail.com> wrote: >> The problem is not in Python packages, but when gluing Python with other Windows apps or libraries. > > I would argue that anyone doing that is capable of looking for the > version they need. The … [View More]

6 6

globals should accept parenteses for extending beyond 1 line
by João Matos Jan. 27, 2017

Jan. 27, 2017

Hello, I would like to suggest that globals should follow the existing rule (followed by the import statement, the if statement and in other places) for extending beyond 1 line using parentheses. Like this: globals (var_1, var_2, var_3) instead of what must be done now, which is: globals var_1, var_2 \ var_3 Best regards, JM

12 17

Re: [Python-ideas] Python-ideas Digest, Vol 122, Issue 100
by Lesego Moloko Jan. 26, 2017

Jan. 26, 2017

W Sent from Lesego's iPhone > On 26 Jan 2017, at 18:28, python-ideas-requests > @python.org wrote: > > Send Python-ideas mailing list submissions to > python-ideas(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/python-ideas > or, via email, send a message with subject or body 'help' to > python-ideas-request(a)python.org > > You can reach the person managing the list at > … [View More] python-ideas-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Python-ideas digest..." > > > Today's Topics: > > 1. Re: globals should accept parenteses for extending beyond 1 > line (Nick Coghlan) > 2. Is it Python 3 yet? (Victor Stinner) > 3. Re: Is it Python 3 yet? (Paul Moore) > 4. Re: Is it Python 3 yet? (Ryan Birmingham) > 5. Re: Is it Python 3 yet? (Nick Timkovich) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 26 Jan 2017 17:02:55 +0100 > From: Nick Coghlan <ncoghlan(a)gmail.com> > To: MRAB <python(a)mrabarnett.plus.com> > Cc: "python-ideas(a)python.org" <python-ideas(a)python.org> > Subject: Re: [Python-ideas] globals should accept parenteses for > extending beyond 1 line > Message-ID: > <CADiSq7f9s6fUm53T+ip5eCbhdeqrvWG+iHw0X7T4QEpAsr5tTA(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > >> On 23 January 2017 at 22:29, MRAB <python(a)mrabarnett.plus.com> wrote: >>> On 2017-01-23 20:09, Nick Timkovich wrote: >>> >>> Related and probably more common is the need for the line-continuation >>> operator for long/multiple context managers with "with". I assume that's >>> come up before, but was it also just a low priority rather than any >>> technical reason? >>> >> It has come up before, and there is a technical reason, namely the syntactic >> ambiguity when parsing. Not impossible to fix, but probably not worth the >> added complexity. > > Right, it's the fact parentheses are already allowed there, but mean > something quite different: > >>>> with (1, 2, 3): pass > ... > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > AttributeError: __enter__ > > These days, I'd personally be in favour of changing the parsing of > parentheses in that situation, as if we were going to add meaningful > context management behaviour to tuples we would have done it by now, > and having the name bindings next to their expressions is easier to > read than having them all at the end: > > with (cm1() as a, > cm2() as b, > cm3() as c): > ... > > Relative to tuples-as-context-managers, such an approach would also > avoid reintroducing the old resource management problems that saw > contextlib.nested removed and replaced with contextlib.ExitStack. > > Cheers, > Nick. > > -- > Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia > > > ------------------------------ > > Message: 2 > Date: Thu, 26 Jan 2017 17:11:17 +0100 > From: Victor Stinner <victor.stinner(a)gmail.com> > To: python-ideas <python-ideas(a)python.org> > Subject: [Python-ideas] Is it Python 3 yet? > Message-ID: > <CAMpsgwbOmZHYtV87OxABeb=e6ujUy0tOtiQEg7T=OwOg7peFsA(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi, > > The download button of https://www.python.org/ currently gives the > choice between Python 2.7 and 3.6. I read more and more articles > saying that we reached a point where Python 3 became more popular than > Python 2, Python 3 has now enough new features to convince developers, > etc. > > Is it time to "hide" Python 2.7 from the default choice and only show > Python 3.6 *by default*? > > For example, I expect a single big [DOWNLOAD] button which would start > the download of Python 3.6 for my platform. > > If we cannot agree on hiding Python 2 by default, maybe we can at > least replace the big [DOWNLOAD] button of Python 2 with a smaller > button or replace it with a link to a different download page? > > Latest news: Django 2.0 and Pyramid 2.0 will simply drop Python 2 support. > > Victor > > > ------------------------------ > > Message: 3 > Date: Thu, 26 Jan 2017 16:21:30 +0000 > From: Paul Moore <p.f.moore(a)gmail.com> > To: Victor Stinner <victor.stinner(a)gmail.com> > Cc: python-ideas <python-ideas(a)python.org> > Subject: Re: [Python-ideas] Is it Python 3 yet? > Message-ID: > <CACac1F_8sp0337BUFkSh-f=Aqvt01NkNTrinwCg=vERB-hO_7w(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > >> On 26 January 2017 at 16:11, Victor Stinner <victor.stinner(a)gmail.com> wrote: >> The download button of https://www.python.org/ currently gives the >> choice between Python 2.7 and 3.6. I read more and more articles >> saying that we reached a point where Python 3 became more popular than >> Python 2, Python 3 has now enough new features to convince developers, >> etc. >> >> Is it time to "hide" Python 2.7 from the default choice and only show >> Python 3.6 *by default*? >> >> For example, I expect a single big [DOWNLOAD] button which would start >> the download of Python 3.6 for my platform. > > +1 > > On a similar note, I always get caught out by the fact that the > Windows default download is the 32-bit version. Are we not yet at a > point where a sufficient majority of users have 64-bit machines, and > 32-bit should be seen as a "specialist" choice? > > Paul > > > ------------------------------ > > Message: 4 > Date: Thu, 26 Jan 2017 11:23:23 -0500 > From: Ryan Birmingham <rainventions(a)gmail.com> > To: Victor Stinner <victor.stinner(a)gmail.com> > Cc: python-ideas <python-ideas(a)python.org> > Subject: Re: [Python-ideas] Is it Python 3 yet? > Message-ID: > <CAJU2dcqizWz+A1-H3z=nEErTyZeLgFzrhmZMOgCLGjaFTCc_CQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > It's certainly an interesting transition period. > I'm not sure that the community is quite ready to just drop 2.7, but we > could take a hint from angular <https://angularjs.org/>'s solution to this > issue and use small descriptions to guide more people to 3.6 rather than > 2.7, then move to 2.7 being substantially smaller, then eventually to > dropping 2.7. > > -Ryan Birmingham > > On 26 January 2017 at 11:11, Victor Stinner <victor.stinner(a)gmail.com> > wrote: > >> Hi, >> >> The download button of https://www.python.org/ currently gives the >> choice between Python 2.7 and 3.6. I read more and more articles >> saying that we reached a point where Python 3 became more popular than >> Python 2, Python 3 has now enough new features to convince developers, >> etc. >> >> Is it time to "hide" Python 2.7 from the default choice and only show >> Python 3.6 *by default*? >> >> For example, I expect a single big [DOWNLOAD] button which would start >> the download of Python 3.6 for my platform. >> >> If we cannot agree on hiding Python 2 by default, maybe we can at >> least replace the big [DOWNLOAD] button of Python 2 with a smaller >> button or replace it with a link to a different download page? >> >> Latest news: Django 2.0 and Pyramid 2.0 will simply drop Python 2 support. >> >> Victor >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas(a)python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > [View Less]

1 0

pathlib suggestions
by Todd Jan. 26, 2017

Jan. 26, 2017

I have been using pathlib, and I have come up with a few suggestions on what would make the module more useful for me (and hopefully others): First, for me, extensions are primarily useful as a single unit. So, practically speaking, the extension of "spam.tar.gz" isn't ".gz", it is ".tar.gz". So it would be nice to have some properties to make it easier to deal with the "complete" extension like this. There is a "suffixes" property, but it returns a list, which you then have to recombine … [View More]

13 22

Re: [Python-ideas] "Immutable Builder" Pattern and Operator
by Gerald Britton Jan. 23, 2017

Jan. 23, 2017

On Jan 23, 2017 1:12 PM, "Britton, Gerald" <Gerald.Britton(a)td.com> wrote: On 23/01/17 02:56 PM, Gerald Britton wrote: > > >* On Jan 23, 2017 11:07 AM, "Soni L." <fakedme+py at gmail.com <https://mail.python.org/mailman/listinfo/python-ideas> * >* <mailto:fakedme% <fakedme%25>2Bpy at gmail.com <https://mail.python.org/mailman/listinfo/python-ideas>>> wrote:* > > > >* On 23/01/17 01:52 PM, Gerald Britton wrote:* >> … [View More]>> >> >>* [snip]* >> >>* >I propose `x .= y` -> `x = x . y`, for any `y`.* >> >>* [snip]* >> >>* I think you mean "any y that is a member of x"* >> > >* Since it desugars into `x = x.y`, you can literally use anything* >* for `y`.* > >* x .= __call__().whatever().unwrap() * 3* > >* is equivalent to* > >* x = x.__call__().whatever().unwrap() * 3* > >* and* > >* x .= 1* > >* is equivalent to* > >* x = x.1* > >* which is equivalent to* > >* SyntaxError: invalid syntax* > > >>* Also, note that this syntax means that x will be rebound to* >>* the result of calling x.y, whatever that is (frequently,* >>* None, for mutating methods)* >> >>* In general, you can't count on methods to return references* >>* to their instances, even though it's handy for fluent coding,* >>* so this side effect may be unexpected to some* >> > >* This is why it's for use with **immutable** objects.* > > >>* That's a problem with your original example:* >> >>* >long_name = mkbuilder()* >> >>* >long_name = long_name.seta(a)* >> >>* >long_name = long_name.setb(b)* >> >>* >y = long_name.build()* >> >>* What do the methods seta and setb return? If they don't* >>* return "self" you've got a problem. I think.* >> > >* They don't return self. Ever. The value bound to long_name is* >* immutable, like an integer. They return a new instance.* > > >* Then long_name isn't immutable. It changes with every line. That can * >* lead to nasty bugs if you count on its immutability.* > >* Easy to see. Just print long_name after each call.* You're mixing up value immutability with name immutability. The name isn't immutable, but: Er...No. I'm not confused at all, unless you define immutability in a new way.. you said that the "value bound to long_name is immutable." It's not. Your example below proves it. An immutable object is one whose state cannot be modified once set. That's not happening here. The state of the object bound to long_name, which is a pointer to an instance of you class, changes with each line. long_name = mkbuilder() x = long_name long_name .= seta("a") y = long_name long_name .= setb("b") z = long_name print(x) # a = None, b = None print(y) # a = "a", b = None print(z) # a = "a", b = "b" print(x is y) # False print(x is z) # False print(y is z) # False print(long_name is z) # True See also: long_name = 1 x = long_name long_name += 1 y = long_name long_name += 1 z = long_name print(x) # 1 print(y) # 2 print(z) # 3 print(x is y) # False print(x is z) # False print(y is z) # False print(long_name is z) # True > > > >>* FWIW why can't you just write:* >> >>* x.y* >> >>* or for your example:* >> >>* long_name.seta(a)* >> >>* ?* >> >> > >* See the IRC bot builder example, it should be more clear. (It's* >* about forking the builder.)* > > If you wish to unsubscribe from receiving commercial electronic messages from TD Bank Group, please click here <http://www.td.com/tdoptout> or go to the following web address: www.td.com/tdoptout Si vous souhaitez vous désabonner des messages électroniques de nature commerciale envoyés par Groupe Banque TD veuillez cliquer ici <http://www.td.com/tddesab> ou vous rendre à l'adresse www.td.com/tddesab NOTICE: Confidential message which may be privileged. Unauthorized use/disclosure prohibited. If received in error, please go to www.td.com/legal for instructions. AVIS : Message confidentiel dont le contenu peut être privilégié. Utilisation/divulgation interdites sans permission. Si reçu par erreur, prière d'aller au www.td.com/francais/avis_juridique pour des instructions. [View Less]

3 2

"Immutable Builder" Pattern and Operator
by Gerald Britton Jan. 23, 2017

Jan. 23, 2017

[snip] >I propose `x .= y` -> `x = x . y`, for any `y`. [snip] I think you mean "any y that is a member of x" Also, note that this syntax means that x will be rebound to the result of calling x.y, whatever that is (frequently, None, for mutating methods) In general, you can't count on methods to return references to their instances, even though it's handy for fluent coding, so this side effect may be unexpected to some That's a problem with your original example: >… [View More]

4 5

Re: [Python-ideas] "Immutable Builder" Pattern and Operator
by Soni L. Jan. 23, 2017

Jan. 23, 2017

... I need a better email client. *double-checks I got everything right this time...* On 23/01/17 11:30 AM, Soni L. wrote: > Sorry, I replied to this wrong. Not used to this mailing list. > > On 23/01/17 11:28 AM, Soni L. wrote: >> >> >> On 23/01/17 11:18 AM, M.-A. Lemburg wrote: >>> On 23.01.2017 14:05, Soni L. wrote: >>>> >>>> On 23/01/17 09:45 AM, Serhiy Storchaka wrote: >>>>> On 23.01.17 01:30, Soni L. wrote: >&… [View More]gt;>>>> On 22/01/17 08:54 PM, Serhiy Storchaka wrote: >>>>>>> On 23.01.17 00:45, Soni L. wrote: >>>>>>>> I've been thinking of an Immutable Builder pattern and an operator >>>>>>>> to go >>>>>>>> with it. Since the builder would be immutable, this wouldn't work: >>>>>>>> >>>>>>>> long_name = mkbuilder() >>>>>>>> long_name.seta(a) >>>>>>>> long_name.setb(b) >>>>>>>> y = long_name.build() >>>>>>> I think the more pythonic way is: >>>>>>> >>>>>>> y = build(a=a, b=b) >>>>>>> >>>>>>> A Builder pattern is less used in Python due to the support of >>>>>>> keyword >>>>>>> arguments. >>>>>> I guess you could do something like this, for an IRC bot builder: >>>>>> >>>>>> fnircbotbuilder = mkircbotbuilder(network="irc.freenode.net", >>>>>> port=6697, >>>>>> ssl=true) >>>>>> mainbot = mkircbotbuilder(parent=fnircbotbuilder, # ??? >>>>>> channels=["#bots"]).build() >>>>>> fndccbotbuilder = mkircbotbuilder(parent=fnircbotbuilder, dcc=true, >>>>>> channeldcc=true) >>>>>> dccbot = mkircbotbuilder(parent=fndccbotbuilder, >>>>>> channels=["#ctcp-s"]).build() >>>>>> otherircbotbuilder = mkircbotbuilder(parent=fndccbotbuilder, >>>>>> network="irc.subluminal.net") # because we want this whole network >>>>>> otherbot = mkircbotbuilder(parent=otherircbotbuilder, >>>>>> channels=["#programming"]).build() # to use DCC and channel DCC >>>>>> >>>>>> But this would be cleaner: >>>>>> >>>>>> botbuilder = >>>>>> mkircbotbuilder().network("irc.freenode.net").port(6697).ssl(true) >>>>>> mainbot = botbuilder.channels(["#bots"]).build() >>>>>> botbuilder .= dcc(true).channeldcc(true) >>>>>> dccbot = botbuilder.channels(["#ctcp-s"]).build() >>>>>> botbuilder .= network("irc.subluminal.net") >>>>>> otherbot = botbuilder.channels(["#programming"]).build() >>>>> In Python you can save common options in a dict and pass them as >>>>> var-keyword argument. Or use functools.partial. In any case you don't >>>>> need a builder class with the build method and a number of >>>>> configuring >>>>> methods. It can be just a function with optional keyword parameters. >>>>> >>>>> A Builder pattern is often used in languages that don't support >>>>> passing arguments by keyword and partial functions. Python rarely >>>>> needs the purposed class implementing a Builder pattern. Actually a >>>>> Builder pattern is built-in in the language as a part of syntax. >>>>> >>>> Yeah but the dotequals operator has many other benefits: >>>> >>>> long_name .= __call__ # cast to callable >>>> long_name .= wrapped # unwrap >>>> etc >>>> >>>> And it also looks neat. >>> I don't see this an being a particular intuitive way of writing >>> such rather uncommon constructs. >>> >>> The syntax is not clear (what if you have an expression on the RHS) >>> and it doesn't save you much in writing (if long_name is too long >>> simply rebind it under a shorter name for the purpose of the code >>> block). >> >> It's literally sugar for repeating the name and moving the dot to the >> right. I think it's clearer than most other compound operators in >> that it doesn't affect precedence rules. >> >> `x += y`, for any code `y`, is equivalent to `x = x + (y)`, not `x = >> x + y`. >> >> `x .= y`, for any code `y`, is equivalent to `x = x . y`, not `x = x >> . (y)`. >> >>> >>> Also note that rebinding different objects to the same name >>> in the same block is often poor style and can easily lead to >>> hard to track bugs. >>> >> >> Rebinding different objects to the same name in rapid succession is >> fine. > [View Less]

2 1

"Immutable Builder" Pattern and Operator
by Soni L. Jan. 23, 2017

Jan. 23, 2017

I've been thinking of an Immutable Builder pattern and an operator to go with it. Since the builder would be immutable, this wouldn't work: long_name = mkbuilder() long_name.seta(a) long_name.setb(b) y = long_name.build() Instead, you'd need something more like this: long_name = mkbuilder() long_name = long_name.seta(a) long_name = long_name.setb(b) y = long_name.build() Or we could add an operator to simplify it: long_name = mkbuilder() long_name .= seta(a) long_name .= setb(b) y = … [View More]

10 18

Re: [Python-ideas] Immutable Builder" Pattern and Operator
by Hervé "Kyle" MUTOMBO Jan. 23, 2017

Jan. 23, 2017

Paul Moore is clearly right when He says that this "a .= 1+1" doesn't make sense. It means nothing understandable although in "a .= s(e)" can mean something. As a matter of fact "a .= EXPR" is bound to succeed only in a very small set of cases. On Jan 23, 2017 14:39, <python-ideas-request(a)python.org> wrote: Send Python-ideas mailing list submissions to python-ideas(a)python.org To subscribe or unsubscribe via the World Wide Web, visit https://mail.python.org/mailman/… [View More]listinfo/python-ideas or, via email, send a message with subject or body 'help' to python-ideas-request(a)python.org You can reach the person managing the list at python-ideas-owner(a)python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Python-ideas digest..." Today's Topics: 1. Re: "Immutable Builder" Pattern and Operator (Paul Moore) 2. Re: "Immutable Builder" Pattern and Operator (Soni L.) 3. Re: Python-ideas Digest, Vol 122, Issue 81 (Herv? Kyle MUTOMBO) ---------------------------------------------------------------------- Message: 1 Date: Mon, 23 Jan 2017 13:26:49 +0000 From: Paul Moore <p.f.moore(a)gmail.com> To: "Soni L." <fakedme+py(a)gmail.com> Cc: Python-Ideas <python-ideas(a)python.org> Subject: Re: [Python-ideas] "Immutable Builder" Pattern and Operator Message-ID: <CACac1F9qo=1Zr7-YW+rCYBCQMV7cu7BRC9WrCR3ZNMkJ+E8iQA(a)mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On 23 January 2017 at 13:05, Soni L. <fakedme+py(a)gmail.com> wrote: > Yeah but the dotequals operator has many other benefits: > > long_name .= __call__ # cast to callable > long_name .= wrapped # unwrap > etc Those don't seem particularly clear to me. > And it also looks neat. Well, we have to agree to differ on that one. Also, the semantics of the proposed operation are very odd. If I understand your proposal a .= b(c) doesn't evaluate b(c) (It can't, as b is a method of a and doesn't make sense on its own), but rather combines the LHS and RHS with a dot - so it's defined in terms of rewriting the input rather than as an operation on the subexpressions. There's no other operator in Python that I'm aware of that works like this. What grammar would you allow for the RHS? So far you've shown LHS .= METHOD(ARGS) LHS .= ATTRIBUTE Clearly, LHS .= EXPR makes no sense in general (consider a .= 1+1). On the other hand, what about LHS .= ATTRIBUTE[INDEX] ? I'm guessing you'd want that allowed? Frankly, I don't think the benefits are even close to justifying the complexity. Paul ------------------------------ Message: 2 Date: Mon, 23 Jan 2017 11:33:26 -0200 From: "Soni L." <fakedme+py(a)gmail.com> To: "M.-A. Lemburg" <mal(a)egenix.com> Cc: "python-ideas(a)python.org" <python-ideas(a)python.org> Subject: Re: [Python-ideas] "Immutable Builder" Pattern and Operator Message-ID: <e36e68d0-826f-db35-af31-11b330c57226(a)gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed ... I need a better email client. *double-checks I got everything right this time...* On 23/01/17 11:30 AM, Soni L. wrote: > Sorry, I replied to this wrong. Not used to this mailing list. > > On 23/01/17 11:28 AM, Soni L. wrote: >> >> >> On 23/01/17 11:18 AM, M.-A. Lemburg wrote: >>> On 23.01.2017 14:05, Soni L. wrote: >>>> >>>> On 23/01/17 09:45 AM, Serhiy Storchaka wrote: >>>>> On 23.01.17 01:30, Soni L. wrote: >>>>>> On 22/01/17 08:54 PM, Serhiy Storchaka wrote: >>>>>>> On 23.01.17 00:45, Soni L. wrote: >>>>>>>> I've been thinking of an Immutable Builder pattern and an operator >>>>>>>> to go >>>>>>>> with it. Since the builder would be immutable, this wouldn't work: >>>>>>>> >>>>>>>> long_name = mkbuilder() >>>>>>>> long_name.seta(a) >>>>>>>> long_name.setb(b) >>>>>>>> y = long_name.build() >>>>>>> I think the more pythonic way is: >>>>>>> >>>>>>> y = build(a=a, b=b) >>>>>>> >>>>>>> A Builder pattern is less used in Python due to the support of >>>>>>> keyword >>>>>>> arguments. >>>>>> I guess you could do something like this, for an IRC bot builder: >>>>>> >>>>>> fnircbotbuilder = mkircbotbuilder(network="irc.freenode.net", >>>>>> port=6697, >>>>>> ssl=true) >>>>>> mainbot = mkircbotbuilder(parent=fnircbotbuilder, # ??? >>>>>> channels=["#bots"]).build() >>>>>> fndccbotbuilder = mkircbotbuilder(parent=fnircbotbuilder, dcc=true, >>>>>> channeldcc=true) >>>>>> dccbot = mkircbotbuilder(parent=fndccbotbuilder, >>>>>> channels=["#ctcp-s"]).build() >>>>>> otherircbotbuilder = mkircbotbuilder(parent=fndccbotbuilder, >>>>>> network="irc.subluminal.net") # because we want this whole network >>>>>> otherbot = mkircbotbuilder(parent=otherircbotbuilder, >>>>>> channels=["#programming"]).build() # to use DCC and channel DCC >>>>>> >>>>>> But this would be cleaner: >>>>>> >>>>>> botbuilder = >>>>>> mkircbotbuilder().network("irc.freenode.net").port(6697).ssl(true) >>>>>> mainbot = botbuilder.channels(["#bots"]).build() >>>>>> botbuilder .= dcc(true).channeldcc(true) >>>>>> dccbot = botbuilder.channels(["#ctcp-s"]).build() >>>>>> botbuilder .= network("irc.subluminal.net") >>>>>> otherbot = botbuilder.channels(["#programming"]).build() >>>>> In Python you can save common options in a dict and pass them as >>>>> var-keyword argument. Or use functools.partial. In any case you don't >>>>> need a builder class with the build method and a number of >>>>> configuring >>>>> methods. It can be just a function with optional keyword parameters. >>>>> >>>>> A Builder pattern is often used in languages that don't support >>>>> passing arguments by keyword and partial functions. Python rarely >>>>> needs the purposed class implementing a Builder pattern. Actually a >>>>> Builder pattern is built-in in the language as a part of syntax. >>>>> >>>> Yeah but the dotequals operator has many other benefits: >>>> >>>> long_name .= __call__ # cast to callable >>>> long_name .= wrapped # unwrap >>>> etc >>>> >>>> And it also looks neat. >>> I don't see this an being a particular intuitive way of writing >>> such rather uncommon constructs. >>> >>> The syntax is not clear (what if you have an expression on the RHS) >>> and it doesn't save you much in writing (if long_name is too long >>> simply rebind it under a shorter name for the purpose of the code >>> block). >> >> It's literally sugar for repeating the name and moving the dot to the >> right. I think it's clearer than most other compound operators in >> that it doesn't affect precedence rules. >> >> `x += y`, for any code `y`, is equivalent to `x = x + (y)`, not `x = >> x + y`. >> >> `x .= y`, for any code `y`, is equivalent to `x = x . y`, not `x = x >> . (y)`. >> >>> >>> Also note that rebinding different objects to the same name >>> in the same block is often poor style and can easily lead to >>> hard to track bugs. >>> >> >> Rebinding different objects to the same name in rapid succession is >> fine. > ------------------------------ Message: 3 Date: Mon, 23 Jan 2017 14:38:40 +0100 From: Herv? "Kyle" MUTOMBO <hervinhioslash(a)gmail.com> To: python-ideas(a)python.org Subject: Re: [Python-ideas] Python-ideas Digest, Vol 122, Issue 81 Message-ID: <CAKX-YRBEy+jf713qP4GY+Q6HFwMGXxHNKNSLpVPf34T-z+Pecg(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Pleasing to see and somehow elegant. I believe .= is a good idea. On Jan 23, 2017 14:18, <python-ideas-request(a)python.org> wrote: > Send Python-ideas mailing list submissions to > python-ideas(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/python-ideas > or, via email, send a message with subject or body 'help' to > python-ideas-request(a)python.org > > You can reach the person managing the list at > python-ideas-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Python-ideas digest..." > > > Today's Topics: > > 1. Re: "Immutable Builder" Pattern and Operator (Cory Benfield) > 2. Re: "Immutable Builder" Pattern and Operator (Paul Moore) > 3. Re: "Immutable Builder" Pattern and Operator (Serhiy Storchaka) > 4. Re: "Immutable Builder" Pattern and Operator (Soni L.) > 5. Re: "Immutable Builder" Pattern and Operator (M.-A. Lemburg) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 23 Jan 2017 09:32:02 +0000 > From: Cory Benfield <cory(a)lukasa.co.uk> > To: "Soni L." <fakedme+py(a)gmail.com> > Cc: python-ideas(a)python.org > Subject: Re: [Python-ideas] "Immutable Builder" Pattern and Operator > Message-ID: <8671EBCA-148F-41C8-A592-46EF653B9CAE(a)lukasa.co.uk> > Content-Type: text/plain; charset="utf-8" > > > > On 22 Jan 2017, at 22:45, Soni L. <fakedme+py(a)gmail.com> wrote: > > > > > > This pattern is present in the cryptography module already with things > like their x509.CertificateBuilder: https://cryptography.io/en/ > latest/x509/reference/#cryptography.x509.CertificateBuilder < > https://cryptography.io/en/latest/x509/reference/#cryptography.x509. > CertificateBuilder>. > > My 2c, but I find that code perfectly readable and legible. I don?t think > a dot-equals operator would be needed. > > Cory > [View Less]

2 1

Re: [Python-ideas] Python-ideas Digest, Vol 122, Issue 81
by Hervé "Kyle" MUTOMBO Jan. 23, 2017

Jan. 23, 2017

Pleasing to see and somehow elegant. I believe .= is a good idea. On Jan 23, 2017 14:18, <python-ideas-request(a)python.org> wrote: > Send Python-ideas mailing list submissions to > python-ideas(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/python-ideas > or, via email, send a message with subject or body 'help' to > python-ideas-request(a)python.org > > You can … [View More]

1 0