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

Soni L. fakedme+py at gmail.com
Mon Jan 23 09:12:24 EST 2017



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



More information about the Python-ideas mailing list