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?
Builders for network connections where you don't wanna start with a
fresh builder every time.
That's not a rhetorical question -- I'm genuinely surprised that you're
not only using the builder design pattern (there are usually better
solutions in Python) but more so that you're making the builder itself
immutable.
In any case, it seems that this is such a narrow and unusual use-case
that it wouldn't be wise to give it special syntax. Especially when
there are other, potentially far more useful, uses for the .= syntax,
e.g. Julia's syntactic loop fusion:
http://julialang.org/blog/2017/01/moredots
It is far more useful only because it's not just a syntax sugar. It's
more like a completely new, standalone operator.
Which, IMO, makes it more confusing.
I propose `x .= y` -> `x = x . y`, for any `y`.
You propose `x .= y` -> `operate_on(x).with(lambda: y)`
This feels like you're arguing for loops are more useful than
multiplication, and thus we shouldn't have multiplication.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
