How do we feel about the pragma/pylint overrides?

@daspecster

How do we feel about the pragma/pylint overrides?

I have very little respect the opinions involved in numerical limits in pylintrc_default / pylintrc_testing, especially where we dial up and down the numbers over time. @dhermes has a different opinion about the numerical limits.

In testcase methods, too-many-lines is completely bogus: adding an assertion to a testcase which pushes it over some arbitrary limit does not magically make the method "wrong" -- it clearly improves it.

For functions like _log_entry_mapping_to_pb, too-many-branches is equally wrong: chopping that function up in to pieces to satisfy that opinion would make it harder to read and understand.

For the import issues: if we ever get to the point that grpico and friends are universally installable / importable, we can likely remove those.

Is this meant to be used with _LoggingAPI in /gcloud/logging/connection.py?

I guess I'm trying to understand how people would use these together in practice?

@daspecster

Is this meant to be used with _LoggingAPI in /gcloud/logging/connection.py?

I guess I'm trying to understand how people would use these together in practice?

The class in this PR is the GAX -protobuf-over-gRPC alternative to that class, which is the JSON-over-HTTP version providing the same API. Only one of the two will be used in any given instance, based on a) importability of the gRPC-related modules, and b) an environment variable switch. That bit will get wired in in a subsequent PR, after implementing GAX versions of the _SinksAPI and _MetricsAPI helpers.

Thanks! LGTM!