[Python-ideas] Adding __getter__ to compliment __iter__.

[Ron Adam]

On 07/22/2013 08:06 PM, Stephen J. Turnbull wrote:
> Ron Adam writes:
>
>   > I think the meaning or context I'm trying to get is ...
>   >
>   >       send y to x   ==   x <-- y
>
> That's a notation, not a "meaning".

Yes, And you understood the meaning I was referring to from the notation. ;-)


> R uses the very similar '<-', for
> one example.  But in R it means assignment.  Other notations used to
> "send" one object to another, with semantics to "not be so strictly
> defined," include what in Python is attribute access x.y, function
> call x(y), mapping x[y], and extended assignment x+=y.  Syntactically
> these are all the same: noncommutative operators on the set of
> objects, which expresses the directionality of abstract "send".[1]
>
>   > >   >      >>> ("One " << "Two " << "Three!")
>   > >   >      'One Two Three!'
>   >
>   > > That's not a comprehension.  A comprehension aggregates (and possibly
>   > > transforms and filters) the elements of a container.  Here the strings
>   > > are elements listed explicitly; it's just an ordinary expression as
>   > > far as anybody who doesn't know how magic "<<" is would know.
>   >
>   > I agree, it would need something to signify it isn't just an ordinary
>   > expression.
>
> But it *is* just an ordinary expression.  Why does it need to be
> anything else?

What I wrote is an ordinary expression.  But what I was thinking of, was 
more than that.

Consider a syntax that would have the effect of overriding methods on 
objects temporarily within the expressions boundaries.  It might look 
something like the above expression, but it would need something more to 
convey that there was something different about it.

This was just one possible alternative way to implement the (second 
version) of a suggestion like the one the subject of this thread describes. 
  But it's all just too abstract at the moment.  So I'm going to give it a 
break and maybe come back t it later if I can find a more practical and 
useful idea in all of this.


The rest of your replay was was very interesting, thanks.

Cheers,
    Ron


> BTW, we already have a way to create generators that send a sequence
> of objects to a particular object:
>
>      z = start_object                      # eg, "" or []
>      g = (z.receive(x) for x in iterable)
>
> Consider:
>
>      MacPorts 08:22$ python3.3
>      >>> z = []
>      >>> g = (z.append(c) for c in "abcdefghij")
>      >>> for x in g: pass
>      ...
>      >>> z
>      ['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j']
>      >>>
>
> Note that x is a pure dummy; the loop could also be expressed
>
>      while True: next(g)
>
> But this is an exercise in futility, as the whole point of a generator
> is that it generates.  Here we just throw that generated object away,
> and the idea is better expressed explicitly:
>
>      z = []
>      for c in "abcdefghij":
>          z.append(c)
>
> (BTW, the generated object in this example is always None.)
>
> Footnotes:
> [1]  Actually, in most languages attribute access doesn't send one
> object to another, it invokes a binding in a hierarchical namespace.
> But consider `get' in Lisp.  Also these are "partial" operators: there
> are object pairs that raise an error rather than producing a result.
>
> I'm using this language only to focus on the *syntactic* similarity.
> Using it to discuss semantics or implementation would be extremely
> confusing.
>