Excerpting... On Tue, 2006-03-28 at 14:07 +0000, Gareth McCaughan wrote: > * Simple API: > > API complexity is measured in brain cells, not in methods. > > * Ease of making mistakes: > > The Python API is absolutely stuffed with places where you can go wrong > by forgetting about subtle refcounting issues. Sure, it's nice to minimize > that pain, but it's never going to be possible to write much code that > uses the C API without being alert to such issues. > * Duck typing: > > Yup, supporting duck typing is good. That's why we have an abstract API. > There are concrete APIs for all sorts of particular kinds of Python object; > it seems pretty clear to me that this isn't a mistake, and that sets should > be one such type. Clients get to choose how to trade off the benefits in > efficiency, conciseness and clarity from using the concrete API against > the benefits in generality from using the abstract one. > * Efficiency: > > Anyone measured this? The mere fact that the overhead of (say) emptying > a set using PyObject_CallMethod is O(1) doesn't mean it's insignificant. > For many applications the size of your sets is O(1) too. (Often with > quite a small implicit constant, too.) My sentiments exactly Gareth. Thanks for putting it so much more eloquently than I have. :) -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 309 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail/python-dev/attachments/20060328/85fa6019/attachment.pgp
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4