>
> I attended a talk at PYCON UK that talked to the point of using object
> composition
> rather then rich interfaces. I cannot recall the term that was used to
> cover this idea.
>
>
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.
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.
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
with open('dump.txt') as f:
for line in f:...
with
import gzip
with gzip.open('dump.gz', 'rt') as f:
for line in f:...
and it just worked through the magic of file-like objects and context
managers.
Nick
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
