list index()

[zzbbaadd]

While I agree that Bruno's response was perhaps needlessly snippy, your

original question was needlessly inflammatory, as if you somehow wanted
some "religious zealot" to act the way Bruno did. If we start labeling
people, this thread will earn you a label that rhymes with "roll".

That is correct. I did word it in a way that would hook the Bruno's of
the group. But I will probably have some more important questions so I
will word it differently in the future. Such as: I wish they were not
getting rid of dict.has_key() in Python 3, which I prefer to IN.

 

[zzbbaadd]

Neil, Steve,

Thanks for the responses on sets. I have not used them before and was
not even aware Python had them. I will try them out.

 

[Carsten Haese]

I wish they were not
getting rid of dict.has_key() in Python 3, which I prefer to IN.

That wish will only come true if you maintain your own fork of Python 3.
has_key() will go away, period. It has been made obsolete by "in", which
is faster and more concise.

 

[Dennis Lee Bieber]

In my case of have done os.listdir() on two directories. I want to see
what files are in directory A that are not in directory B.
I have used exceptions in other languages and only do so on logic that
should never happen. In this case it is known that some of the files
will not be in both lists. I just want to know which ones.

Sounds like something that could be solved using Set operations...

Convert both lists to sets, take set difference

aSet.difference(bSet)
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Steve Holden]

That is correct. I did word it in a way that would hook the Bruno's of
the group. But I will probably have some more important questions so I
will word it differently in the future. Such as: I wish they were not
getting rid of dict.has_key() in Python 3, which I prefer to IN.

Well, again Python gives you the flexibility to define your own dict
subclass that has a has_key() method with the obvious implementation.

But why would you want to ignore built-in support like "value in dict"?

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------

 

[zzbbaadd]

That wish will only come true if you maintain your own fork of Python 3.
has_key() will go away, period. It has been made obsolete by "in", which
is faster and more concise.

Is there really some reason "key" IN dict can be implemented faster
than dict.has_key("key")???

 

[Neil Cerutti]

Is there really some reason "key" IN dict can be implemented
faster than dict.has_key("key")???

Yes. Looking up the has_key method by name is the slower part.

 

[Chris Mellon]

Is there really some reason "key" IN dict can be implemented faster
than dict.has_key("key")???

Yes. As an exercise, I wont tell you the first most obvious reason -
see if you can figure it out. The dis module may help.

 

[Carsten Haese]

Is there really some reason "key" IN dict can be implemented faster
than dict.has_key("key")???

Yes, see e.g.
http://groups.google.com/group/comp.lang.python/msg/03e9b4276846b9c0

 

[MRAB]

And, as is so often the case, once the *real* problem is stated a more
elegant solution become available - in this case, using sets.

afiles = set(os.listdir(dira))
bfiles = set(os.listdir(dirb))

for f in (afiles - bfiles):
print "Not common:", f

You can also generate the files that are in one directory but ot the
other with

(afiles | bfiles) - (afiles & bfiles)

.... which can be written more concisely as:

afiles ^ bfiles

 

[MRAB]

It's letting you know that the item isn't in the list. There's no
sensible return value from an "index" function in that condition.

for str:

find( sub[, start[, end]])
Return the lowest index in the string where substring sub is
found, such that sub is contained in the range [start, end]. Optional
arguments start and end are interpreted as in slice notation. Return
-1 if sub is not found.

-1 is used in other languages as well.

In 0-based languages it's often -1 whereas in 1-based languages it's
often 0.

 

[Marc 'BlackJack' Rintsch]

It's letting you know that the item isn't in the list. There's no
sensible return value from an "index" function in that condition.

for str:

find( sub[, start[, end]])
Return the lowest index in the string where substring sub is
found, such that sub is contained in the range [start, end]. Optional
arguments start and end are interpreted as in slice notation. Return
-1 if sub is not found.

But that is a valid index into a string! So this may go unnoticed if one
doesn't check after every call to `str.find()`. And that method is going
away in Python 3.0.

Ciao,
Marc 'BlackJack' Rintsch

 

[Ben Finney]

It's letting you know that the item isn't in the list. There's no
sensible return value from an "index" function in that condition.

for str:
find( sub[, start[, end]])
[...]
Return -1 if sub is not found.

-1 is used in other languages as well.

It is no more sensible there than in the 'str.find' method, which is a
historical wart.

 

[Ben Finney]

In my case of have done os.listdir() on two directories. I want to see
what files are in directory A that are not in directory B.

You get that information unambiguously. It's an exceptional case,
since there's no index to return, so it throws an exception.

I have used exceptions in other languages and only do so on logic
that should never happen.

You're confusing "assert" ("this should always be true") with
"exception" ("this is an exception to the the normal flow of this
process").

An exception isn't "something that should never happen", it's
something that is entirely possible and needs to be handled somehow.

 

[zzbbaadd]

for str:
find( sub[, start[, end]])
[...]
Return -1 if sub is not found.

-1 is used in other languages as well.

It is no more sensible there than in the 'str.find' method, which is a
historical wart.

One man's sensible is another man's insensible. For instance, some
people feel -1 as a valid index into a list is sensible. Other's find
it insensible.

 

[zzbbaadd]

You get that information unambiguously. It's an exceptional case,
since there's no index to return, so it throws an exception.


You're confusing "assert" ("this should always be true") with
"exception" ("this is an exception to the the normal flow of this
process").

An exception isn't "something that should never happen", it's
something that is entirely possible and needs to be handled somehow.

I don't think that is the definition used across computer science.

It suddenly dawned on me that what would be best would be a contains()
(or IN syntax for those who can't afford to wait) for lists.

if mylist.contains("hello):

 

[Chris Mellon]

I don't think that is the definition used across computer science.

how its defined in Python is what is important in this context.

It suddenly dawned on me that what would be best would be a contains()
(or IN syntax for those who can't afford to wait) for lists.

if mylist.contains("hello):

Genius. Why didn't anyone think of that before?

 

[Lawrence D'Oliveiro]

But why would you want to ignore built-in support like "value in dict"?

Because a function can be passed as a value in its own right, a built-in
construct cannot.

 

[Carsten Haese]

It suddenly dawned on me that what would be best would be a contains()
(or IN syntax for those who can't afford to wait) for lists.

Either I'm misunderstanding what you mean or you need to get a clue
about what Python can already do before you go around making suggestions
for what Python needs. Lists have supported "in" tests since at least
version 1.5.2:

Python 1.5.2 (#1, Nov 6 1999, 14:53:40) [C] on sco_sv3
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam

if 3 in [1,2,3]: print "Yup, got it!"

....
Yup, got it!

This feature may be older than version 1.5.2, but this is the oldest
version that I still have running anywhere.

 

[Carsten Haese]

Because a function can be passed as a value in its own right, a built-in
construct cannot.

....and that's why we have operator.contains():
Help on built-in function contains in module operator:

contains(...)
contains(a, b) -- Same as b in a (note reversed operands).