[Python-3000] Iterators for dict keys, values, and items == annoying :)

[Benji York]

Alex Martelli wrote:
> If the framework consuming X requested adaptation-to-X on all objects
> it's passed,

That's not generally the way Zope 3 does it (and doesn't sound like a 
good idea to me).

There are three ways (as I see it) adaptation is used in Z3.  First, the 
traditional idea of an "adapter", in which something has the right 
state, but the wrong interface.  That form of adaptation is used when 
plugging different components together (whether they are Z3 or come from 
other projects).  In that way of using adaptation a 
function/method/whatever wants things that act in a particular way (duck 
typing).  If I, as the user of the interface, have something I want to 
pass in that doesn't match I it to the appropriate interface the burden 
is on me to create something that matches expectations.  People do that 
all the time today without an interface/adaption framework, they just 
write code that takes one thing and builds another.

Greg Ewing wrote:
> This is the part that bothers me, I think. It
> seems like all these adaptation requests would
> be a huge burden on the framework developer.

Not in the above scenario, when using adapters like that the burden is 
on the user.  That might sound like a bad thing, but if they're 
exclusively using your library, they already have objects of the 
necessary type, if not they have an adaptation framework to help them do 
something they'd have to do anyway.

The second way adaptation is used is as a general lookup facility.  Say 
that I have a user object and I want to know their security information. 
  Instead of building an API for looking up security descriptions from a 
user name that I have to pull out of the user object, I could instead 
register and adapter from IUser to ISecurityInfo, now I don't need any 
new APIs, I just so sec_info = ISecurityInfo(the_user).  This form of 
adaptation is good for the "I have something and want more information 
about it" use case.  It also adds some flexibility, the workings of the 
adapter can change without having to change all the client code as you'd 
have to do if you changed (for example) the parameters an API expected.

The third way it's used is to make systems pluggable.  You mentioned 
PyGUI, so say you had a schema describing a data entry form.  You could 
use adaptation to decide which GUI widget would be used for each field. 
  Looping over the form fields and adapting each to IWidget and getting 
back a TextField for a string, CheckBox for a boolean, etc.  Then if the 
user has a nice TextField object with spell checking, they could just 
plug in a different adapter and all their fields would get the new 
widget without PyGUI having to support a plug-in framework.

> In PyGUI, for example, I currently have about
> 2 or 3 dozen classes. Should I be defining and
> registering a formal protocol for every one of
> those?

Unless PyGUI wants to use the interfaces for something, probably not. 
Another theme of Zope 3 is to use other project's code instead of 
reinventing the wheel.  If we want to use a third-party class with 
adaptation, we can (externally to the class) assert that it conforms to 
a particular interface.

I don't intend to bore people with a study of adaptation in Zope 3, but 
instead am attempting to echo Alex's realization that once you have the 
simple tools of adaptation in mind (much like other practices like OO or 
data-driven programming) you start to recognize places where they help 
you solve problems in better ways.
--
Benji York