On Sat, 27 Aug 2005 08:54:12 +0200, Martin v. Löwis <[EMAIL PROTECTED]>
wrote:
> with choice 1a): dict.get returns None if the key is not found, even
> though None could also be the value for the key.
that's a bug! i had to *test* it to find out it's true! i've been writing
code for *years* all in the understanding that dict.get(x) acts precisely
like dict['x'] *except* you get a chance to define a default value. which,
for me, has become sort of a standard solution to the problem the last ten
or so postings were all about: when i write a function and realize that's
one of the cases where python philosophy strongly favors raising an
exception
because something e.g. could not be found where expected, i make it so that
a reasonable exception is raised *and* where meaningful i give consumers
a chance to pass in a default value to eschew exceptions. i believe
this is the way to go to resolve this .index/.find conflict. and, no,
returning -1 when a substring is not found and None when a key is not
found is *highly* problematic. i'd sure like to see cases like that to go.
i'm not sure why .rindex() should go (correct?), and how to do what it does
(reverse the string before doing .index()? is that what is done
internally?)
and of course, like always, there is the question why these are methods
at all and why there is a function len(str) but a method str.index(); one
could just as well have *either* str.length and str.index() *or*
length(str) and, say, a builtin
locate( x, element, start = 0 , stop = None, reversed = False, default =
Misfit )
(where Misfit indicates a 'meta-None', so None is still a valid default
value;
i also like to indicate 'up to the end' with stop=None) that does on
iterables
(or only on sequences) what the methods do now, but with this strange
pattern:
------------------------------------------------------------------
.index() .find() .get() .pop()
list + ?(3) +
tuple ?(3) ??(1)
str + + ?(3) ??(1)
dict x(2) x(2) + +
(1) one could argue this should return a copy of a tuple or str,
but doubtful. (2) index/find meaningless for dicts. (3) there
is no .get() for list, tuple, str, although it would make sense:
return the indexed element, or raise IndexError where not found
if no default return value given.
------------------------------------------------------------------
what bites me here is expecially that we have both index and find
for str *but a gaping hole* for tuples. assuming tuples are not slated
for removal, i suggest to move in a direction that makes things look
more like this:
------------------------------------------------------------------
.index() .get() .pop()
list + + +
tuple + +
str + +
dict + +
------------------------------------------------------------------
where .index() looks like locate, above:
------------------------------------------------------------------
{list,tuple,str}.index(
element, # element in the collection
start = 0, # where to start searching; default is zero
stop = None, # where to end; the default, None, indicates
# 'to the end'
reversed = False, # should we search from the back? *may* cause
# reversion of sequence, depending on impl.
default = _Misfit, # default value, when given, prevents
# IndexError from being raised
)
------------------------------------------------------------------
hope i didn't miss out crucial points here.
_wolf
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
