[Python-ideas] Dart-like method cascading operator in Python
Haoyi Li
haoyi.sg at gmail.com
Thu Nov 21 18:48:56 CET 2013
> Is it really that hard to name a plot "p"? Is typing "p.", or reading it,
more work than ".."?
Yes, reading `..` can be *considerably* less work than reading `p.`.
- With `..` you know exactly where the thing is coming from (the preceding
lines) whereas with `p.`, `p` could come from anywhere
- when you're eyes are tired you better look closely to make sure you
didn't accidentally write `b` which may mean something else in this scope
and cause your program to silently malfunction.
- You also better make sure you didn't have a variable somewhere else
called `p` for Pressure in one of your equations which you just stomped
over, or `p` for Momentum, or Price, or Probability. It's not inconceivable
that you'd want to plot these things!
Generally, having fewer things in the local namespace is good hygiene, and
helps prevent name collisions. This is separate from the issue of the
proposed syntax (which I don't really like) and whether it's useful enough
to warrant special syntax (not sure)
On Thu, Nov 21, 2013 at 9:26 AM, Andrew Barnert <abarnert at yahoo.com> wrote:
> On Nov 21, 2013, at 5:34, Masklinn <masklinn at masklinn.net> wrote:
>
> On 2013-11-21, at 13:40 , Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> On 21 November 2013 20:55, Perešíni Peter <ppershing at gmail.com> wrote:
>
> gnuplot.newPlot()
>
> ..set("xrange [0:5]")
>
> ..set("yrange [0:20]")
>
> ..newPlot()
>
> ..addSeries("Linear", [1,2,3])
>
> ..addSeries("Quadratic", [1,4,6])
>
> ..run()
>
>
> If you just want structural grouping of some code, you can already
>
> define an appropriate context manager:
>
>
> @contextlib.contextmanager
>
> def value(x)
>
> yield x
>
>
> with value(gnuplot.newPlot()) as p:
>
> p.set("xrange [0:5]")
>
> p.set("yrange [0:20]")
>
> with value(p.newPlot()) as n:
>
> n.addSeries("Linear", [1,2,3])
>
> n.addSeries("Quadratic", [1,4,6])
>
> p.run()
>
>
> It doesn’t define a new scope
>
>
> And it requires naming things.
>
>
> Is it really that hard to name a plot "p"? Is typing "p.", or reading it,
> more work than ".."?
>
> The FAQ already suggests the "just give it a short name" answer (
> http://docs.python.org/3.3/faq/design.html#why-doesn-t-python-have-a-with-statement-for-attribute-assignments).
> Nick's suggestion does that plus an indent for readability. Do we actually
> need more than that?
>
> An other drawback is that it is a statement, where the cascading
> operator yields an expression (at least in Smalltalk it did) (well of
> course more or less everything was an expression in smalltalk so that
> helped).
>
>
> Cascading has to be a statement. It has statements inside it. It uses
> indentation. If it's an expression it will have all of the same ambiguity
> problems that a naive multiline lambda proposal does, and break the
> simplicity of the language.
>
> (That also means it can't be an operator. It has to be special syntax,
> like =.)
>
> So if this is any part of the argument for the proposal, I'm -1.
>
>
> I really liked message cascading when I played with it in Smalltalk, but:
>
> 1. I find Dart’s cascading syntax rather noisy, and examples on The
> Internets seem to show it regularly used in single-line expression
> which I find a detriment to readability:
>
> document.body.children.add(new
> ButtonElement()..id='awesome'..text='Click Me!’;);
>
> 2. Unless I missed it, the original suggestion failed to specify what
> the overall expression returns. In Smalltalk, it returns the value of
> the last message of the cascade, and Smalltalk has a `yourself` message
> which returns, well, its self. IIRC, Python has no such message “built
> in”.
>
> 3. It encourages and facilitates APIs based on object mutation and
> incompletely initialised objects, the former being a slight dislike and
> the latter being something I loathe.
>
> 4. I doubt OP’s (a) would be fixed, it’s not an issue of attribute deref,
> so
> a cascading operator would have the exact same behaviour.
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20131121/926e8fb1/attachment-0001.html>
More information about the Python-ideas
mailing list