[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.python

Why does list have no 'get' method?

Denis Bilenko

2/7/2008 5:32:00 AM

Why does list have no 'get' method with exactly the same semantics as
dict's get,
that is "return an element if there is one, but do NOT raise
an exception if there is not.":

def get(self, item, default = None):
try:
return self[item]
except IndexError:
return default

It is often desirable, for example, when one uses the easiest
command-line options parsing - based on absolute positions:

With such a method instead of this (snippet from BaseHTTPServer.py)

if sys.argv[1:]:
port = int(sys.argv[1])
else:
port = 8000

we could write

port = sys.argv.get(1) or 8000

which is both more condense and more clear.

The change is unlikely to break anyone's code.
(nobody uses getattr(obj, 'get') to distinguish between lists and dicts, right?)
32 Answers

Paul Rubin

2/7/2008 6:39:00 AM

0

"Denis Bilenko" <denis.bilenko@gmail.com> writes:
> port = sys.argv.get(1) or 8000

I like the suggestion, except it should be

port = int(sys.argv.get(1, '8000'))

one could imagine your example going wrong in a protocol where 0 is
a valid port number.

Raymond Hettinger

2/7/2008 7:40:00 AM

0

[Denis Bilenko]
> Why does list have no 'get' method with exactly the same semantics as
> dict's get,
> that is "return an element if there is one, but do NOT raise
> an exception if there is not.":
. . .
> It is often desirable, for example, when one uses the easiest
> command-line options parsing - based on absolute positions:
>
> With such a method instead of this (snippet from BaseHTTPServer.py)
>
>     if sys.argv[1:]:
>         port = int(sys.argv[1])
>     else:
>         port = 8000
>
> we could write
>
>     port = sys.argv.get(1) or 8000

At first blush that example would make it seem like a good idea, but I
don't see how the example could extend past the first index. If the
port argument is optional, how would you know the index position of
optional arguments to follow?

With a dictionary, one could plausibly write:

host = d.get('host', 'http://exampl...)
port = d.get('port', 8080)
path = d.get('path', '/')

But would this make sense with a list:

host = s.get(0, 'http://exampl...)
port = d.get(1, 8080)
path = d.get(2, '/')

If positions 0 and 1 are optional, how do you expect to know whether
"path" is going to be at position 2? This problem doesn't exist with
dictionaries because the presence or absence of optional entries does
not affect the key reference to other entries. Accordingly, I
wouldn't expect that dict.get() would have a parallel list.get() with
plausible use cases.

Raymond

Bearophile

2/7/2008 8:21:00 AM

0

Paul Rubin:
> I like the suggestion, except it should be
> port = int(sys.argv.get(1, '8000'))
> one could imagine your example going wrong in a protocol where 0 is
> a valid port number.

I think a high-level language like Python must have boolean operators
(or and not) that behave in a much more clean way, with a simpler
semantics. That is they have to return only true or false. Otherwise
they are just a source of bugs and confusion. This is a change fit for
Python 3.
That trick with or/and may look good for Perl, but it's unfit for a
language that tries to be clear, readable from people that don't know
it much, and good to learn to program. Python has now the if-then
expression too that is more clear.

Bye,
bearophile

Stefan Behnel

2/7/2008 8:44:00 AM

0

bearophileHUGS@lycos.com wrote:
> Paul Rubin:
>> I like the suggestion, except it should be
>> port = int(sys.argv.get(1, '8000'))
>> one could imagine your example going wrong in a protocol where 0 is
>> a valid port number.
>
> I think a high-level language like Python must have boolean operators
> (or and not) that behave in a much more clean way, with a simpler
> semantics. That is they have to return only true or false. Otherwise
> they are just a source of bugs and confusion. This is a change fit for
> Python 3.

Conditional expressions have clear semantics.

Stefan

Steven D'Aprano

2/7/2008 9:07:00 AM

0

On Thu, 07 Feb 2008 00:20:52 -0800, bearophileHUGS wrote:

> I think a high-level language like Python must have boolean operators
> (or and not) that behave in a much more clean way, with a simpler
> semantics. That is they have to return only true or false. Otherwise
> they are just a source of bugs and confusion.

Well, that's one opinion.

Boolean operators can be complicated to understand if you write
complicated expressions, or if you don't understand what they do. But
otherwise, they're no more complicated than arithmetic expressions.

[...]
> That trick with or/and may look good for Perl, but it's unfit for a
> language that tries to be clear, readable from people that don't know it
> much, and good to learn to program. Python has now the if-then
> expression too that is more clear.

Suppose I have two lists, and want to process the first one if it is not
empty, otherwise process the second. I'd write it like this:

process(mylist or yourlist)

You're suggesting I should write it like this:

process(mylist if mylist else yourlist)


With the greatest respect, I think that if you think the second example
"is more clear", you're completely bonkers. *grins*


--
Steven

Bearophile

2/7/2008 10:02:00 AM

0

Steven D'Aprano:
> With the greatest respect, I think that if you think the second example
> "is more clear", you're completely bonkers. *grins*

No one is completely normal, I presume :-)
I'd like to know what others think about it, about this anti-feature.
What I can say is that other computer languages too think that boolean
operations must return boolean values only, so I am not alone in my
folly :-)

Bye,
bearophile

Arnaud Delobelle

2/7/2008 10:35:00 AM

0

On Feb 7, 8:20 am, bearophileH...@lycos.com wrote:
> Paul Rubin:
>
> > I like the suggestion, except it should be
> >      port = int(sys.argv.get(1, '8000'))
> > one could imagine your example going wrong in a protocol where 0 is
> > a valid port number.
>
> I think a high-level language like Python must have boolean operators
> (or and not) that behave in a much more clean way, with a simpler
> semantics. That is they have to return only true or false. Otherwise
> they are just a source of bugs and confusion. This is a change fit for
> Python 3.
> That trick with or/and may look good for Perl, but it's unfit for a
> language that tries to be clear, readable from people that don't know
> it much, and good to learn to program. Python has now the if-then
> expression too that is more clear.
>
> Bye,
> bearophile

Personally, between

* foo if foo else bar
* foo or bar

I prefer the second. Maybe it could be spelt

* foo else bar ?

Moreover between the following two:

* foores = foo()
foobar = foores if foores else bar

* foobar = foo() or bar

I also prefer the second. Maybe it could be spelt

* foo() else bar ?

I have not thought of parsing issues :)

--
Arnaud

Thomas Bellman

2/7/2008 11:07:00 AM

0

Bruno Desthuilliers <bruno.42.desthuilliers@wtf.websiteburo.oops.com> wrote:

> Not quite. In C and a couple other langages, int 0 is false, anything
> else is true.

Not just int, but all kinds of integers, as well as all kinds of
floating point types and all kinds of pointers, with the value 0
are considered false. And structs and unions can't be used in a
boolean context at all, and are thus neither true nor false.

> In Lisp (and IIRC), an empty list is false, anything else
> is true.

There seems to be a language name missing from the parenthesis.
Were you perhaps thinking of Scheme? If so, then no, in Scheme
only #f is false, and the empty list () is considered true.


--
Thomas Bellman, Lysator Computer Club, Linköping University, Sweden
"When C++ is your hammer, everything ! bellman @ lysator.liu.se
looks like a thumb." ! Make Love -- Nicht Wahr!

Bruno Desthuilliers

2/7/2008 12:33:00 PM

0

bearophileHUGS@lycos.com a écrit :
> Steven D'Aprano:
>> With the greatest respect, I think that if you think the second example
>> "is more clear", you're completely bonkers. *grins*
>
> No one is completely normal, I presume :-)
> I'd like to know what others think about it, about this anti-feature.

s/anti//

> What I can say is that other computer languages too think that boolean
> operations must return boolean values only,

Not quite. In C and a couple other langages, int 0 is false, anything
else is true. In Lisp (and IIRC), an empty list is false, anything else
is true. I'm sure someone else could come with more than a couple other
non-cryptic langages that just don't have a proper boolean type.

Using "emptyness" as a false value in boolean expressions is not that
uncommon, and it has proven so far to be a working solution. Also,
returning the tested object instead of a bool just makes sens to me.
FWIW, booleans are a late addition to Python, and quite a couple persons
where worried that it would only lead to confusion.

Steve Holden

2/7/2008 1:44:00 PM

0

bearophileHUGS@lycos.com wrote:
> Steven D'Aprano:
>> With the greatest respect, I think that if you think the second example
>> "is more clear", you're completely bonkers. *grins*
>
It's amusing how often "with the greatest respect" is used to preface a
statement that clearly implies very little respect at all. Though, for
what it's worth, I agree with Steven here.

> No one is completely normal, I presume :-)
> I'd like to know what others think about it, about this anti-feature.
> What I can say is that other computer languages too think that boolean
> operations must return boolean values only, so I am not alone in my
> folly :-)
>
Other languages do indeed refuse the temptation to short-circuit, but
that doesn't mean that Python is wrong to do so. It's a design choice,
and while you are free to disagree with it I imagine you would be
pissing in the wind in attempting to get a change like that into Python 3.

Most people like the semantics of "and" and "or" as they are.

no-more-normal-than-anyone-else-ly y'rs - steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.hold...