A few thoughts, some minor, some not...

**First Thought**

Just about any time I see a `def get_`, I starting thinking "Would this work well as a property?"

I think the answer here is no due to the args (more on this in another thought), but I think just renaming the method to "stats" instead of "get_stats" would be a tiny bit better-looking.

**Second Thought**

Raising an exception if the requested stat isn't in a dict is reimplementing `dict`'s existing KeyError behavior with a less-specific exception. The message is more specific to this case, but exception type checking is vastly preferred to exception message inspection since exception type checking feature is built in to python. Furthermore, no matter how friendly the exception's message is, the path to resolution is still to manually inspect `stats_available` to find a key name that will not trigger an exception.

There's value in keeping things pythonic by failing with the normal KeyError, as well as [EAFP] instead of [LBYL].

**Third Thought**

`self.stats_available` is interesting, but the work with lambdas being done results in a somewhat odd calling format. Since work is already being done to publicize the available stats in `get_stats` (or `stats`... :D), this seems like a good place to mark `stats_available` as a private attribute to help callers know if they should be working with `stats_available` or `get_stats`.

**Fourth Thought**

I think the two arguments are representing two facets of the same data, and also adding a confusing use-case. For example, it's not clear without digging into the `get_stats` source what's going to happen in this case:
```python
mgmt_system.get_stats(['num_vm', 'num_cluster'], True)
```

I think taking advantage of argument packing might simplify the interface a bit, and allow returning all stats by default if no stats are specifically requested.

**Fifth thought**

If you're looking to iterate over a dictionary's keys, they are the iterable property of dictionaries. It's rare to have a case where calling the `dict.keys` is appropriate, often just iterating over the dictionary is enough.

As an example, here's a silly way to shallow-copy a dictionary:
```python
d = {'a': 1, 'b': 2}
new_d = {k: d[k] for k in d}
assert d == new_d
```

(The less silly way, of course, is `new_d = d.copy()`)

**Example combining the thoughts**

`stat_list` becomes `requested_stats` to prevent type confusion because its functional equivalent in these examples is now a tuple.

```python
def stats(self, *requested_stats):
    if not requested_stats:
        requested_stats = self._stats_available
    return {stat: self._stats_available[stat] for stat in requested_stats}
```

Alternate version, slightly less readable but slightly more beautiful without the conditional:
```python
def stats(self, *requested_stats):
    # Both of these examples should probably have a comment here, along the lines of...
    # Return all available stats if no specific stats are requested
    requested_stats = requested_stats or self._stats_available
    return {stat: self._stats_available[stat] for stat in requested_stats}
```
Normal disclaimers about how I'm just making this stuff up and it's probably broken apply.

[EAFP]: http://docs.python.org/2/glossary.html#term-eafp
[LBYL]: http://docs.python.org/2/glossary.html#term-lbyl