Skip tests on network error

[gliptak]

No description provided.

[cpcloud]

it might be best if use a try:... suite whereever you perform io (and nowhere else) rather than just wrapping everything into a huge try: clause. it's going to be a huge pain to track down which of these is throwing the io error down the line. as a rule try (no pun intended) keeping try: clauses as small as possible so that disambiguating errors is easier. also no need to put any of the post io code in the try:... suite since if you're there there wasn't a raise

[jreback]

closing in favor of #3914

[gliptak]

@jreback while I understand that the decorator is a better approach, this pull request also split up tests into smaller functions, which make identifying errors easier ... I think this is a small value add regardless.

[jreback]

@gliptak np.....

cc @jtratner

shall we merge this first? then #3914 which might need a rebase after?

[jtratner]

I'm going to be home and able to check in about 30mins, do you mind waiting
so I can check? I think my PR covers nearly all of this already (including
switching out imports etc)
On Jun 18, 2013 7:38 PM, "jreback" notifications@github.com wrote:

@gliptak https://github.com/gliptak np.....

cc @jtratner https://github.com/jtratner

shall we merge this first? then #3914https://github.com/pydata/pandas/issues/3914which might need a rebase after?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/3893#issuecomment-19650825
.

[jtratner]

In particular - the network and with connectivity decorators make it
unnecessary to catch IOErrors in test.
On Jun 18, 2013 7:40 PM, "Jeffrey Tratner" jeffrey.tratner@gmail.com
wrote:

I'm going to be home and able to check in about 30mins, do you mind
waiting so I can check? I think my PR covers nearly all of this already
(including switching out imports etc)
On Jun 18, 2013 7:38 PM, "jreback" notifications@github.com wrote:

@gliptak https://github.com/gliptak np.....

cc @jtratner https://github.com/jtratner

shall we merge this first? then #3914https://github.com/pydata/pandas/issues/3914which might need a rebase after?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/3893#issuecomment-19650825
.

[jreback]

also pls look at #3916, prob related

[jtratner]

Uh but you shouldn't merge my other PR. Have to make one edit like I said
earlier.
On Jun 18, 2013 7:41 PM, "Jeffrey Tratner" jtratner@gmail.com wrote:

In particular - the network and with connectivity decorators make it
unnecessary to catch IOErrors in test.
On Jun 18, 2013 7:40 PM, "Jeffrey Tratner" jeffrey.tratner@gmail.com
wrote:

I'm going to be home and able to check in about 30mins, do you mind
waiting so I can check? I think my PR covers nearly all of this already
(including switching out imports etc)
On Jun 18, 2013 7:38 PM, "jreback" notifications@github.com wrote:

@gliptak https://github.com/gliptak np.....

cc @jtratner https://github.com/jtratner

shall we merge this first? then #3914https://github.com/pydata/pandas/issues/3914which might need a rebase after?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/3893#issuecomment-19650825
.

[jreback]

no merging until positive confirmation from both of you (kind of like it takes 2 keys to blow up the world)

[gliptak]

@jreback Maybe you can merge this pull request (as it "compiles" alone), than retrofit #3914 to HEAD? There are also @network functions in #3822.

[jtratner]

The problem is that all of the try: catch URLErrror...check google.com idiom is handled transparently by the new network and with_connectivity_check decorators. So if we merge the other commit first, you can replace all of the try/catch statements with a:

@with_connectivity_check("http://www.google.com")

at the top.

[gliptak]

@jtratner Jeff, do you see this pull request working as is (without implementing your improvements)?

[jtratner]

@gliptak one of us will have to edit a pull request to make the final merge happen, haha. The only thing is that you have more domain experience with this module than I do, so it would be great if you could decide which tests should check connectivity ahead of time (@with_check_connectivity(check_before_test=True)/afterwards(@with_check_connectivity) and which tests should just ignore connectivity errors altogether (@network)). I tried to do this, but it was rather arbitrary.

[jtratner]

@jreback why don't you just merge this first and then I'll edit the other one.

[jreback]

@gliptak thank you

[gliptak]

@jreback no problem
@jtratner please let me know if you are expecting changes from me

[jtratner]

It's all good, ended up being a breeze to merge.
On Jun 19, 2013 7:17 PM, "gliptak" notifications@github.com wrote:

@jreback https://github.com/jreback no problem
@jtratner https://github.com/jtratner please let me know if you are
expecting changes from me

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/3893#issuecomment-19721651
.