Guido van Rossum wrote:
> Python's philosophy about (built-in) data types, inherited from ABC,
> is to offer a few powerful clearly distinct choices rather than lots
> of alternatives with overlapping usages. This reduces the time it
> takes to choose a data type and reduces the risk of picking the wrong
> type. (You seem to be indicating that this is indeed what's happening
> to you in Lisp. :-)
Speaking about the new dequeue type, I have the impression that
this reasoning applies there a bit, too?
Dequeues of course have applications, and I saw them used,
especially by newcomers to the language. So I like their
functionality.
But actually, I'm not so convinced if we need to introduce
a new datatype. How about an extension to normal lists
that does a little tracking of use-cases and decides about
changing its implementation upon the presence of inserts/deletes
at the lower end of the list?
I'm btw. not sure if this raises an implicit/explicitiness issue.
My question is if it is necessary to put the burden about explicitly
choosing a specialized two-ended list on the programmer, or if it
is simple enough to make lists just do the right thing, if lists
are used in a dequeue-style manner. Or is this maybe too much magic
happening?
merry christmas -- chris
--
Christian Tismer :^) <mailto:tismer at stackless.com>
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
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