<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>I attended a talk at PYCON UK that talked to the point of using object composition<br></div><div>rather then rich interfaces. I cannot recall the term that was used to cover this idea.</div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div> </div></div></blockquote><div><br></div><div>Separating things by concern/abstraction (the storage vs. the serialization) results in easier-to-learn code, *especially* incrementally, as you can (for example) plug reading from a file, a socket, a database into the same JSON, INI, XML... functions.</div><div><br></div><div>Learn N ways to read data, M ways to transform the data, and you can do N*M things with N+M knowledge. If the libraries start tightly coupling everything, you need to start going through N*M methods, then do it yourself anyways, because reader X doesn't support new-hotness-format Y directly.</div><div><br></div><div>Perhaps less code could result from making objects "quack" alike, so instead of you doing the plumbing, the libraries themselves would. I recently was satisfied by being able to exchange</div><div><br></div><div>  Â  with open('dump.txt') as f:</div><div>  Â  Â  Â  for line in f:...</div><div><br></div><div>with</div><div><br></div><div>  Â  import gzip</div><div><div>  Â  with gzip.open('dump.gz', 'rt') as f:</div><div>  Â  Â  Â  for line in f:...</div><div><br></div><div>and it just worked through the magic of file-like objects and context managers.</div><div><br></div></div><div>Nick</div><div><br></div></div></div></div>