[Python-ideas] Adding __getter__ to compliment __iter__.

[Ron Adam]

On 07/18/2013 12:11 AM, Joshua Landau wrote:
> 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.

You got the most of it.  I really shouldn't write proposals while I'm dead 
tired.  ;-)

I did reply to Steven and explained it in more detail.

Basically the idea is to get a getter obj from a container and be able to 
use it to send things into that container just like we use iter objects to 
get thing out.

They are both generators.

Cheers,
    Ron



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