Guido van Rossum wrote:
> - There's near-universal dislike for the two-arg form, so let's drop
> that part of the proposal.
This is a strong consensus, definitely, so we can conclude that this
point has been decided. I will remove it from the PEP.
Guido also wrote:
> - There's a lot of support for the basic idea, and only a few
> naysayers, so let's keep looking for a syntax that works.
If we can take that as a decision, then the various proposals for the
syntax break down as follows.
By raw numbers, the most popular choice is
self.(method_name) = self.metadata.(method_name)
but many of the "I like that" messages were in the context of the idea
as a whole, so can't really be counted as explicit votes for "obj.(foo)"
as such.
Next, and Guido's preferred choice, is
self.[method_name] = self.metadata.[method_name]
(I haven't been following long enough to know whether "Guido likes it"
overrides everything else (the "D" of BDFL), or is more of a casting
vote in the event of a tie.)
With regard to the potential overlookability of the dot, Guido says:
> I recommend that you do some experiments with the readability of the
> .[...] notation, e.g. write a program that randomly generates x.[foo]
> and x[foo], and see how fast you can spot the difference. I bet that
> you won't have any trouble.
I agree --- just as it's important to have a font that makes it easy to
distinguish "I" from "l" and "1", "0" from "O", "(" from "{", etc., I
would say it's important to program using a font which makes it easy to
tell whether there's a "." in your code. I can imagine that a
proportional font where "." might be a single pixel wouldn't help,
though. (Gently wandering off-topic, but: do people use proportional
fonts for coding? Doesn't it cause general awkwardness for
indentation, especially relevant for python?)
Also mentioned was
self.{method_name} = self.metadata.{method_name}
which could not be confused either with function call or indexing but
perhaps would preclude braces from any potential future use.
Exploring other ideas, the "arrow" notation
self->method_name = self.metadata->method_name
has support, and is clearly different, but I personally would be misled
to think, from the meaning in C, that it ought to be the left-hand
operand which is dereferenced somehow. Guido has the same opinion, and
is "strongly -1" on this.
The "star" form has the "dereference" meaning from C, and is certainly
visually distinctive:
self.*method_name = self.metadata.*method_name
and explicit parentheses could be put in as a syntax requirement, or by
individual coder preference, or for more complex attribute calculations:
self.*(method_name) = self.metadata.*(method_name)
self.*('foo_%d' % n) = self.metadata.*('foo_%d' % n)
The downside is that it could be considered "visually distinctive" to
the point of being line noise.
Could we cut down the choice to
self.[method_name] = self.metadata.[method_name]
if the danger of overlooking the dot were deemed small enough, or
self.*(method_name) = self.metadata.*(method_name)
if the consensus was that something more noticeable was needed?
(Or there's always the late arrival
> > In C, "x->y" dereferences x, while in Python, "x->y" would
dereference y.
>
> Then the syntax should obviously be "x<-y".
> [insert in-Soviet-Russia-variables-dereference-you joke here]
from Benji York.)
Ben.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
