[Python-ideas] Adding __getter__ to compliment __iter__.

[Joshua Landau]

I believe that I understand what you are saying better than Steven
D'Aprano does, so I thought I'd try and explain it. If I am wrong, at
least you know what my misconceptions are then.

On 17 July 2013 21:51, Ron Adam <ron3200 at gmail.com> wrote:
> I played around with trying to find something that would work like the
> example Nick put up and found out that the different python types are not
> similar enough in how they do things to make a function that takes a method
> or other operator work well.
>
> What happens is you either end up with widely varying results depending on
> how the methods are implemented on each type, or an error because only a few
> methods are very common on all types.  Mostly introspection methods.

"Appending items to generic sequences is hard."

> I believe this to be stronger underlying reason why functions like reduce
> and map were removed.
...
> It's too late to change how a lot of those methods work and I'm not sure it
> will still work very well.

"???"

> One of the most consistent protocols python has is the iterator and
> generator protocols.  The reason they work so well is that they need to
> interface with for-loops and nearly all containers support that.

"The iterator protocol is really good at what it does -- perhaps we
could make item-appending repurpose that idea."

> And is why chain is the recommended method of joining multiple containers.

"Chain is good for joining containers because that's exactly what it
does -- use the iterator protocol."

> This really only addresses getting stuff OUT of containers.

??? (I think I know what you are saying, I don't get how that's true for chain)

> What I'm thinking of is the inverse operation of an iter.  Lets call it a
> "getter".
>
> You would get a getter the same way you get an iter.
>
>     g = getter(obj)
>
> But instead of __next__ or send() methods, it would have an iter_send(), or
> isend() method.  The isend method would takes an iter object, or an object
> that iter() can be called on.

"There should be a generic interface to extending and appending that
uses something similar to the iterator protocol."

> The getter would return either the object it came from, or a new object
> depending on weather or not it was created from a mutable or immutable obj
...

"This would return the original type when the original type was
mutable, so that you extend the original object. For immutable types
it should return a new mutable object that "contains" the original
immutable object's items."

> The point, is to have something that works on many types and is as
> consistent in how it's defined as the iter protocol.  Having a strict and
> clear definition is a very important!

"$ditto"

> The internal implementation of a getter could do a direct copy to make it
> faster, like slicing does, but that would be a private implementation
> detail.

"For immutables, this can copy if it wishes, but does not have to."

> They don't replace generator expressions or comprehensions.  Those generally
> will do something with each item.

???

> Functions like extend() and concat() could be implemented with
> *getter-iters*, and work with a larger variety of objects with much less
> work and special handling.

"This would be useful for implementing extend and concat functions."

> Expecting many holes to be punched in this idea ...
>    But hope not too many.  ;-)


AFAICT, this is just like a mutable chain, but that can affect the
original items.

I'm out of power, so I have to go, but this has basically led me to
think: "Hey, why doesn't itertools.chain have .append() and .extend()
-- I would use those loads!" Sorry that it's not actually a comment on
your proposal.