[Python-ideas] Adding __getter__ to compliment __iter__.

Ron Adam ron3200 at gmail.com
Thu Jul 18 16:13:35 CEST 2013


On 07/18/2013 07:54 AM, Steven D'Aprano wrote:
> On 18/07/13 16:26, Ron Adam wrote:
>
>> 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.
>
>
> I think your view of this is confused. The iterator protocol isn't about
> getting things out of something. It's about *iterating over collections*.
> Some iteratables consume their objects, "getting them out" as you put it,
> but others do not (e.g. range, sequences, dict views, etc).

I would have said *remove* or *delete* if I meant this.


> "Getting items out" is usually called pop, or popitem, or delete, or
> similar. The opposite of getting items out is pushing them in (extend, or
> append, or similar), but the opposite of iterating over a collection is not
> iterating over it.
>
> Your proposal is more about assembling collections than it is the opposite
> of iteration. I'm not sure that I like your proposal, but I'd dislike it a
> lot less if you treated it as an assembly protocol and dropped the
> "opposite of iteration" rationale. I don't think that rationale makes sense.

You are understanding what I meant, and yes it is better described as 
assembling, or as Nick says.  building.

What I was meaning by getting things out.. is that of getting references 
out.  Which is what iter() does.   In the title I described getters 
(assemblers) as a complementing iter(), which is a better view point.


> It seems to me that your proposal is about creating some sort of proxy to
> arbitrary collection types, with a standard "add elements to you"
> interface, in-place if possible. I don't think this is really worthwhile.
> When I was first starting off learning Python, I was disturbed that lists,
> tuples, and dicts (there were no sets back then) had no common API for
> adding elements, so I wrote a helper function that looked something like this:
>
> def add(obj, elements):
>      # This was Python 1.5, so no isinstance
>      if type(obj) == type([]):
>          # or extend
>          for item in element:
>              obj.append(element)
>      elif type(obj) == type({}):
>          obj.update(elements)
>      elif type(obj) == type(()):
>          for item in elements:
>              obj = obj + (element,)
>      return obj
>
> I soon discovered that I never used this function. Like a lot of my early
> code, it was more useful in theory than in practice. I rarely (never?)
> wanted to "add elements" to some arbitrary list, tuple or dict without
> knowing what it was before hand. And my add function was both *too* general
> (it applied to too many types, which I learned I didn't need) and *not
> general enough* (sometimes I wanted to insert at the start of a list, not
> append to the end; sometimes I wanted to replace dict items, sometimes I
> didn't). So it turned out to be useless. So I'm afraid that you will have
> an uphill battle convincing me that your suggested protocol is useful and
> not an over-generalization.


It's still early in the discussion, and you may be correct.

Cheers,
    Ron









More information about the Python-ideas mailing list