On Oct 9, 2:31 am, Steve Holden <[EMAIL PROTECTED]> wrote:
> Keep right on guessing.
I hope I'm not offending one whom I consider to be much more skilled
and versed than I am, not only in python, but in programming in
general; but I must say: it seems you are being rather obtuse here. I
think I laid out the principal clearly enough, and I know you have the
mental capacity to extrapolate from the principal to general use cases.
But even so, here is a simple use case from the standard library
(python 2.5 release source):
In Libs/site.py, lines 302-306:
try:
for i in range(lineno, lineno + self.MAXLINES):
print self.__lines[i]
except IndexError:
break
With my proposal, that could be written as:
for i in range(lineno, lineno + self.MAXLINES):
if self.__lines.has_index(i):
print self.__lines[i]
else:
break
Granted, in this particular case the amount of code is not reduced, but
(and I would hope you'd agree) the control flow is certainly easier to
follow.
> OK, so now we appear to be arguing about whether a feature should go
> into Python because *you* find it to be easier to read and write. But I
> don't see a groundswell of support from other readers saying "Wow, I've
> always wanted to do it like that".
*Someone* (other than me!) obviously found it nice to have the dict
convenience methods. As for garnishing support, I almost see that as
more of a cultural, rather than pragmatic issue. I.e., if it's not
there already, then it shouldn't be there: "what is is what should be".
Of course, consistently following that naive presumption would totally
stiffle *any* extension to python. However, (I think) I do understand
the psychology of the matter, and don't fault those who cannot see past
what already is (not meaning to implicate you or Fredrick or anyone
else -- the comment is innocent).
> In fact d.has_key(k) is a historical spelling, retained only for
> backwards compatibility, of k in dict. As to the d.get(k, default)
> method I really don't see a compelling use case despite your
> protestations, and I don't seem to be alone. Please feel free to start
> recruiting support.
As I stated to another poster; I'm not really concerned with
implementation details, only with the presence or absence of
convenience methods. You can write "if k in d" as easily as "if index <
len(seq)". But semantically, they are similar enough, in my (admittedly
lowly) estimation, to desevere similar convenience methods.
> The fact that nobody has listed the good reasons why I shouldn't try to
> make a computer from mouldy cheese doesn't make this a good idea.
Heh. True. I didn't mean to imply that I was arguing from the negative.
I was only tring to shift the perspective to include the reasons for
the dict convenience methods. If C is good for A, and A is sufficiently
similar to B, then C is good for B. But if C is just crud, then forget
it all around. ;)
On Oct 9, 12:24 pm, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> But how do you handle the case of:
>
> l = []
> i = 10
>
> l[i] = l.get(i, 0) + 1
You don't; you just let the IndexError fall through. Same as a KeyError
for d[k]. My propopsal is in regard to convencience methods, not to
direct access.
Ps. Sorry if this comes through twice, Google is being wierd right now.
Regards,
Jordan
--
http://mail.python.org/mailman/listinfo/python-list
