Re: [Python-ideas] "Immutable Builder" Pattern and Operator

> On 22 Jan 2017, at 22:45, Soni L. 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

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

On 22 January 2017 at 22: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() > > Instead, you'd

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

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

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

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

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

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 g

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

On 23 January 2017 at 13:05, Soni L. 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 th

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

... 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, Son

Re: [Python-ideas] Python-ideas Digest, Vol 122, Issue 81

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

Re: [Python-ideas] Immutable Builder" Pattern and Operator

an 23, 2017 14:18, wrote: > Send Python-ideas mailing list submissions to > python-ideas@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

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

On Mon, Jan 23, 2017 at 12:49:19AM -0200, Soni L. wrote: [...] > You seem to be thinking of "immutable object builder". Not "the builder > itself is immutable and operations on it create new builders". Why would you make a builder class immutable? That's not a rhetorical question -- I'm genuinel

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

On 23/01/17 11:54 AM, Steven D'Aprano wrote: On Mon, Jan 23, 2017 at 12:49:19AM -0200, Soni L. wrote: [...] You seem to be thinking of "immutable object builder". Not "the builder itself is immutable and operations on it create new builders". Why would you make a builder class immutable? Bu

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

On Mon, Jan 23, 2017, at 09:12, Soni L. wrote: > Builders for network connections where you don't wanna start with a > fresh builder every time. Maybe you need a builder builder. Or, more seriously, a way to differentiate the things in the 'builder' from the things that are going to be different

Re: [Python-ideas] Immutable Builder" Pattern and Operator

On 23 January 2017 at 13:47, Hervé "Kyle" MUTOMBO wrote: > 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 se

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

On Sunday, January 22, 2017, Wes Turner wrote: > > > On Sunday, January 22, 2017, Soni L. > wrote: > >> >> >> On 22/01/17 10:03 PM, Wes Turner wrote: >> >> >> >> On Sunday, January 22, 2017, Wes Turner wrote: >> >>> Have you looked at pyrsistent for >>> immutable/functional/persistent/copy-on-

[Python-ideas] "Immutable Builder" Pattern and Operator

[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

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

On 01/23/2017 05:33 AM, Soni L. wrote: 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`.

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

On 23/01/17 01:52 PM, Gerald Britton wrote: [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

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

On Mon, Jan 23, 2017 at 8:07 AM, Soni L. wrote: > > > 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 > > whi

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

On Jan 23, 2017 11:07 AM, "Soni L." wrote: On 23/01/17 01:52 PM, Gerald Britton wrote: [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 .= __c

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

On 23/01/17 02:56 PM, Gerald Britton wrote: On Jan 23, 2017 11:07 AM, "Soni L." > wrote: On 23/01/17 01:52 PM, Gerald Britton wrote: [snip] >I propose `x .= y` -> `x = x . y`, for any `y`. [snip] I think you mean "a

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

On Jan 23, 2017 1:12 PM, "Britton, Gerald" wrote: On 23/01/17 02:56 PM, Gerald Britton wrote: > > >* On Jan 23, 2017 11:07 AM, "Soni L." * >* >>

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

On 23/01/17 04:27 PM, Gerald Britton wrote: On Jan 23, 2017 1:12 PM, "Britton, Gerald" > wrote: On 23/01/17 02:56 PM, Gerald Britton wrote: >// >// >/On Jan 23, 2017 11:07 AM, "Soni L." https://mail.python.org/mailman/listinfo/python-ideas> /

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

On 2017-01-23 12:54 PM, Soni L. wrote: > On 23/01/17 02:56 PM, Gerald Britton wrote: >> On Jan 23, 2017 11:07 AM, "Soni L." > > wrote: >> >> On 23/01/17 01:52 PM, Gerald Britton wrote: >>> >>> [snip] >>> >>> >>> >>> >I propose `x .= y`

[Python-ideas] globals should accept parenteses for extending beyond 1 line

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

Re: [Python-ideas] globals should accept parenteses for extending beyond 1 line

You can just write global foo, bar global baz, bletch On Mon, Jan 23, 2017 at 10:43 AM, João Matos wrote: > 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

Re: [Python-ideas] globals should accept parenteses for extending beyond 1 line

Hello, To me that makes no sense. If for the import statement the rule is to use the parentheses and not repeating the import statement, why should it be different with global? Best regards, JM On 23-01-2017 19:14, Guido van Rossum wrote: You can just write global foo, bar global baz,

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

On 1/23/17 1:27 PM, Gerald Britton wrote: > > > On Jan 23, 2017 1:12 PM, "Britton, Gerald" > wrote: > > > > > You're mixing up value immutability with name immutability. The name > > isn't immutable, but: > > > Er...No. I'm not confused at all, unless yo

Re: [Python-ideas] globals should accept parenteses for extending beyond 1 line

On 1/23/2017 1:43 PM, João Matos wrote: 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 wha

Re: [Python-ideas] globals should accept parenteses for extending beyond 1 line

Hello, You are correct, my mistake. I should have written global and not globals. The purpose of using parentheses on the import statement is not (in my view) for operational efficiency but for appearance/cleaness. The same applies to using it to global. One does not need to have 10 global va

Re: [Python-ideas] globals should accept parenteses for extending beyond 1 line

For what it's worth, I normally just do: global a global b But I've never needed more than two. I think if you need more, then there is a serious style issue. That it looks syntactically ugly is a feature. Perhaps we should deprecate the comma in global ;-) . Stephan Op 23 jan. 2017 8:38 p.m.

Re: [Python-ideas] globals should accept parenteses for extending beyond 1 line

Actually multi-line import doesn't work: File ".\Untitled.py", line 1 import (tokenize, ^ SyntaxError: invalid syntax I think you're getting this mixed up with parentheses being allowed in `from ... import (...)` syntax. So unless there is another single-word keyword that allows mu

Re: [Python-ideas] globals should accept parenteses for extending beyond 1 line

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? On Mon, Jan 23, 2017 at 1:53 PM, Brett Cannon wrote: > Actually mu

Re: [Python-ideas] globals should accept parenteses for extending beyond 1 line

On Tue, Jan 24, 2017 at 6:37 AM, João Matos wrote: > One does not need to have 10 global vars. It may have to do with var name > length and the 79 max line length. > > This is an example from my one of my programs: > global existing_graph, expected_duration_in_sec, file_size, \ > file_mtime, n

Re: [Python-ideas] globals should accept parenteses for extending beyond 1 line

Hello, I understand. Python sources are very large. Any pointers to which file defines the global statement syntax? Best regards, JM On 23-01-2017 19:53, Brett Cannon wrote: Actually multi-line import doesn't work: File ".\Untitled.py", line 1 import (tokenize, ^ SyntaxErro

Re: [Python-ideas] globals should accept parenteses for extending beyond 1 line

Hello, The subject of this topic is a suggestion about the language and not the programming paradigm/style. Why should I repeat global if I can use the line separation character \ (like I mentioned on my 1st email) or parentheses as I suggested? "global existing_graph, expected_duration # "

Re: [Python-ideas] globals should accept parenteses for extending beyond 1 line

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,

Re: [Python-ideas] globals should accept parenteses for extending beyond 1 line

On 01/23/2017 01:18 PM, João Matos wrote: Why should I repeat global if I can use the line separation character \ (like I mentioned on my 1st email) or parentheses as I suggested? Because prefixing each line with global is more readable than either \ or ( )? At least to me. ;) -- ~Ethan~

Re: [Python-ideas] globals should accept parenteses for extending beyond 1 line

On Mon, Jan 23, 2017 at 09:18:54PM +, João Matos wrote: > Why should I repeat global if I can use the line separation character \ > (like I mentioned on my 1st email) or parentheses as I suggested? That's the wrong question. The right question is, why should the Python language be made larg