Guido van Rossum wrote:
> On 3/23/06, Robert Brewer <[EMAIL PROTECTED]> wrote:
> > It is a hassle. I recently changed my ORM's API from
> > returning iterators to lists based on similar user
> > feedback (and I could have sworn I already made
> > this comment on this issue, but I can't find it
> > now). That experience hints to me that any
> > interface that prefers iterators over lists
> > is going to be resisted; builtins doubly so.
>
> Interesting. Was your feedback also based on use in interactive
> sessions only (like Jim's)?
Not at all; the interfaces I mentioned are never used interactively as
far as I know. I think the issue is one of wanting to write code quickly
and easily (whether done 'interactively' or not), and to therefore use
idioms that fit the domain best. In my cases (database search) the
results are almost always going to be 1) iterated over completely, and
2) more than once, whether that's an additional sort() operation, or a
DSU, or type coercion, reformatting, etc. In that domain, lists are the
natural fit. Having to wrap iterators with list() at that point is
boilerplate, for the mind as much as the fingers.
You've got two types of objects in the wild, the "list" set and the
"iterator" set, and they overlap by a large margin (because you can
perform many operations on either with no change in syntax). Say it's an
80% overlap. It might seem trivial, since the overlap is large, to
switch to preferring iterators over lists for return values. But you
still have to weigh the benefits of improvements for the
"iterator-specific" operations (10%) versus the burden of additional
syntax for the "list-specific" operations (10%).
+----------------------+
| list |
+----+----------------------+
iter| |----------------------|
| |------- shared -------|
+----+----------------------+
But in my experience, the remainders are not currently equal. I'd make a
wild-ass guess like "60% shared syntax, 30% lists, 10% iter". So I feel
like the "list operations" (like indexing, slicing, len, etc.) are going
to be penalized with additional boilerplate, in exchange for a very
small win (e.g., typing "keys" instead of "iterkeys").
I'd also opine that the standard library is not similar in this regard
to most application code, simply because most library and framework code
is going to try to be more generic, accepting both kinds of iterables
where possible (whereas application code tends to be more naive, and
therefore assume far more about data types).
> Would the same objection exist against APIs that return "views" as I
> described in a previous message (a la the Java collections package)?
If the vastly common case is to coerce an object into something else
before using it, I think that's a strong argument that the design is
flawed. For example, Python is better IMO for not having an Integer
class on top of an int primitive type (like Java has). If "views"
introduce a similar amount of conceptual and lexical overhead for the
common case, then I think the objection would remain.
Robert Brewer
System Architect
Amor Ministries
[EMAIL PROTECTED]
_______________________________________________
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
