Add 'Client.list_entries'.

[tseaver]

No description provided.

[tseaver]

@dhermes PTAL. I will rebase #1574 and assign to you after this one lands.

[dhermes]

Sorry I've gotta stop midway through the review, have to go teach

[tseaver]

@dhermes this one should be good to go.

[tseaver]

@dhermes In 4f38261, _rfc3339_to_datetime uses a regex to identify/parse the nanosecond-precision timestamps emitted by the logging API: if the regex doesn't match, it re-raises the original exception emitted by strptime. PTAL

[dhermes]

Since when do we love using regex everywhere? My question about a guarantee about the number of digits after the decimal point is still unanswered. Do you know if it will always be 9? Do trailing 0's get chopped?

The goal of my feedback was to avoid having to catch the ValueError and that fix doesn't really capture it

[tseaver]

Since when do we love using regex everywhere?

The regex gives us a way to parse the new format which is a) faster, b) easier to understand, c) less error prone than the manual parsing I initially added.

My question about a guarantee about the number of digits after the decimal point is still unanswered.

The docs promise "nanosecond precision", which requires 9 digits, even with trailing zeroes.

The goal of my feedback was to avoid having to catch the ValueError and that fix doesn't really capture it

We cannot do anything sensible with hypothetical malformed values from the backend, and the previous code didn't try to prevent them (in fact, this code comes from me exposing them when talking to the logging API). If we come across another timestamp format when mapping a new API, then we will have to adjust this helper again: I see that as a better alternative than trying to smother ValueErrors here.

[tseaver]

I have what might be a better idea: rather than overloading the existing _rfc3339_to_datetime to handle the new nanosecond format, I could just add a separate helper (_rfc3339_nanos_to_datetime), which would be used only for parsing timestamps specified as being nanosecond-precision.

[tseaver]

@dhermes PTAL again. I think splitting the two branches into separate functions worked out well.

I'll be glad to squash everything down before merging.

[dhermes]

LGTM. Squashing commits would be nice if it isn't too much

[tseaver]

Squashed. I will merge after Travis.