Re: snmpmodule and making a pretend dictionary object...

anthony baxter (anthony@aaii.oz.au)
Mon, 08 Aug 1994 11:07:17 +1000

Guido.van.Rossum@cwi.nl wrote:
> > First question: is this going to break things (having length returning 1)?
> > Or should I just set the length function to raise a TypeError?
> I would raise an exception (I guess TypeError is the most applicable
> one indeed). A consequence is that testing an snmp session object's
> truth value (e.g. "if sess: ...") will raise an exception as well
> since for mapping objects, this is done by testing that the length is
> > 0. I don't see a good reason for testing a session object's truth

Good - that (the if not working) is the sort of thing I was worried about -
wanted to make sure it wasnt going to have some other unforseen effects,
in this case I dont really care if you can't test its truth value.

> Well, your example already shows a weakness of this scheme: neither
> "mib-2" nor "0" are valid Python identifiers, so they can't be used as
> attribute names. I've a feeling that using subscription is more
[..]
> assume that the subscript version would pass the entire string to the
> server at once, right?

Yup. well, that's that idea dead.

> No, that's fine. Objects are never restricted to have *only* a
> standard set of methods -- though in some cases they must have *at
> least* a standard set.

Groovy.

> Small nit: although the source code is currently confused about these
> things, there's a difference between "dictionaries" and "mappings",
> and your session object would be a mapping, but not a dictionary. A
D'oh! Of course, sloppy thinking on my part.

> "mapping" is anything that supports subscription (x[k]), subscript
> assignment (x[k] = v, optional) and length (len(x)), and which is not
> a sequence (sequences support slicing and have a key space which is
> [0, 1, ..., len(x)-1]). Mappings (but not sequences) also

len(x) is kindof meaningless in this case, but the subscript and subscript
assignment are fine.

> conventionally support the keys(), values() and items() methods, but
> nothing in the interpreter relies on this, and it's fine not to
> support them if there's no easy way to determine the total set
> of key/value pairs. If you do support keys(), len(x) should be equal
> to x.keys().

The trouble is, of course, without walking down a machine's entire tree
of available variables (sloooow), you cant know what keys(), values(),
items() or len() are going to be. Oh well, cant win 'em all.

> (BTW, can't you implement this as a Python class?)

In theory, yes. In practice, the thought of writing a complete SNMP/ASN.1
parser gives me a case of the screaming heebies. The module links with
the CMU SNMP library.

Hopefully this should be ready for a preliminary release later this week,
in the meantime, a teaser:

(snmpwalk.py)

#!/usr/local/bin/python
import snmp
a=snmp.open("alamein","public",1)
(next,value) = a.getnext(".iso")
while next:
print next + " = " + value
(next,value) = a.getnext(next)

(note the above could have also been written using a.thepowerfulgetnext(),
for those who have read MTR's Simple Book :)

Thanks,
Anthony