[Email-SIG] More API thoughts (policy objects)

[Barry Warsaw]

This looks pretty good David.  Nice to see you run with it.

(Small nit: there are a few typos here and there.)

On Mar 05, 2010, at 11:27 PM, R. David Murray wrote:

>Since the registry is going to be in the policy object, that led me
>to write the policy object docs.  After several iterations over both
>documents, I have something that I think at least hangs together, and
>which I think is fairly decent from a usability standpoint (I hope...that
>opinion is based on thought experiments, not real code, after all!).

I've read the document through a few times, and while I'm sure my lack of
sleep is a contributing factor (the other part being my denseness ;), I'm not
quite getting how the Policy and PolicySet classes work together, nor how the
policy_overlay argument comes into play.

>One potentially controversial bit of this design is that I'm planning
>to have the header factory pull together three independent classes
>and dynamically build a composite class out of them to instantiate an
>object from.  This is not something I've ever done before in code, so I'm
>not sure it will even work.  But it seems to make sense as a design,
>so I've speced it that way.  I'll be curious if anyone has any insights,
>opinions, or better ways of accomplishing the same goal.
>
>This design arose from the fact that in my overall design the Bytes and
>String classes share a common base class and that most of the code is
>common between the two.  When thinking about the registry of structured
>headers, it felt rather yucky to have either two registries (bytes and
>string) or a registry with (bytes class, string class) tuples.  Add to
>this the fact that it would be really nice for an application to have a
>way to substitute in its own base class without having to build a whole
>new subclass tree, and I decided to give dynamic class building a try.
>So the design I've speced has a header factory method looking up the
>base class, the string or byte class, and the specific header class in
>the registry, and then composing the three of them in order to return
>a header instance.
>
>Am I crazy?

Not necessarily!  It's an interesting take on the design problem that makes
some sense.  The other way to handle it is through composition and delegation,
but honestly IMO Python does not have a great delegation story (no,
__getattr*__ does not cut it ;).  It's also pretty easy to do in Python, if I
understand what you're trying to get at:

Python 3.1.2rc1+ (release31-maint:78807, Mar  8 2010, 22:02:30) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class Foo: pass
... 
>>> class Bar: pass
... 
>>> class Baz: pass
... 
>>> Qux = type('Qux', (Foo, Bar, Baz), {})
>>> type(Qux)
<class 'type'>
>>> Qux()
<__main__.Qux object at 0x7f0f7e62a750>
>>> Qux.__bases__
(<class '__main__.Foo'>, <class '__main__.Bar'>, <class '__main__.Baz'>)


A few other thoughts.

* Do we need raise_on_defect, handle_defect() and register_defect().  Seems a
  bit of overkill; what's the use case?

* Why does header_indent default to 8 spaces?  Shouldn't it be a tab or single
  space?

* Do you think newline should be renamed end_of_line, linesep, or end?  The
  latter two are evocative of os.linesep and print(..., end='\n', ...).
  "newline" specifically is actually misleading.

That's it for now.  Cool stuff!
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/email-sig/attachments/20100308/6757ad75/attachment.pgp>