Add google.api.core.helpers.general_helpers.wraps

[theacodes]

No description provided.

[theacodes]

@dhermes As an aside, how would you feel if I dropped the google.api.core.helpers package and just moved all the modules up one, e.g., google.api.core.general_helpers, google.api.core.grpc_helpers, etc.?

[lukesneeringer]

As an aside, how would you feel if I dropped the google.api.core.helpers package and just moved all the modules up one, e.g., google.api.core.general_helpers, google.api.core.grpc_helpers, etc.?

-0, but they arguably do not need to all end in _helpers. What about google.api.code.helpers.general? And the usage pattern could be...

fromgoogle.api.coreimporthelpers@helpers.general.wraps(thing)defother_thing

My concern is that there will be a lot of helpers things interspersed with other stuff. And while helpers.general looks kind of dumb, helpers.grpc makes total sense.

The general helpers could also just go into __init__.py. helpers.wraps is fine.

[dhermes]

@jonparrott I am big time 👍 on reducing the number of nested packages.

[dhermes]

LGTM, though I'd like to see a code snippet with the failure you intend to workaround here.

[theacodes]

@jonparrott I am big time 👍 on reducing the number of nested packages.

I'll send a separate PR to do that.

[jba]

Can someone merge this into the bigquery-b2 branch? I'm not sure how to do that.

[dhermes]

@jba I can do it. Will a rebase be OK?

[jba]

@tswast What's the right way to get this into bigquery-b2? Maybe just cherry-pick?

[tswast]

Probably best to rebase bigquery-b2 on master rather than cherry-pick. We'll have to rebase for the final push anyway.

[dhermes]

@tswast I agree. Do you need me to do that or you guys have it covered?

[tswast]

@dhermes@jba Rebase done.