TST: windows failures

[jreback]

======================================================================
FAIL: test_c_engine (pandas.io.tests.parser.test_unsupported.TestUnsupportedFeatures)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\conda\Documents\pandas3.5\pandas\io\tests\parser\test_unsupported.py", line 64, in test_c_engine
    read_table(StringIO(data), engine='c', sep='\xa7')
  File "C:\Users\conda\Documents\pandas3.5\pandas\util\testing.py", line 2437, in __exit__
    raise AssertionError("{0} not raised.".format(name))
AssertionError: ValueError not raised.

closed in #14140

======================================================================
FAIL: test_append_zero (pandas.sparse.tests.test_list.TestSparseList)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\conda\Documents\pandas3.5\pandas\sparse\tests\test_list.py", line 64, in test_append_zero
    tm.assert_sp_array_equal(sparr, SparseArray(arr, fill_value=0))
  File "C:\Users\conda\Documents\pandas3.5\pandas\util\testing.py", line 1392, in assert_sp_array_equal
    assert_numpy_array_equal(left.sp_values, right.sp_values)
  File "C:\Users\conda\Documents\pandas3.5\pandas\util\testing.py", line 1083, in assert_numpy_array_equal
    assert_attr_equal('dtype', left, right, obj=obj)
  File "C:\Users\conda\Documents\pandas3.5\pandas\util\testing.py", line 878, in assert_attr_equal
    left_attr, right_attr)
  File "C:\Users\conda\Documents\pandas3.5\pandas\util\testing.py", line 1018, in raise_assert_detail
    raise AssertionError(msg)
AssertionError: numpy array are different

Attribute "dtype" are different
[left]:  int64
[right]: int32

======================================================================
FAIL: test_dataframe_dummies_prefix_str (pandas.tests.test_reshape.TestGetDummies)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\conda\Documents\pandas3.5\pandas\tests\test_reshape.py", line 327, in test_dataframe_dummies_prefix_str
    assert_frame_equal(result, expected)
  File "C:\Users\conda\Documents\pandas3.5\pandas\util\testing.py", line 1313, in assert_frame_equal
    obj='DataFrame.iloc[:, {0}]'.format(i))
  File "C:\Users\conda\Documents\pandas3.5\pandas\util\testing.py", line 1154, in assert_series_equal
    assert_attr_equal('dtype', left, right)
  File "C:\Users\conda\Documents\pandas3.5\pandas\util\testing.py", line 878, in assert_attr_equal
    left_attr, right_attr)
  File "C:\Users\conda\Documents\pandas3.5\pandas\util\testing.py", line 1018, in raise_assert_detail
    raise AssertionError(msg)
AssertionError: Attributes are different

Attribute "dtype" are different
[left]:  int64
[right]: int32

======================================================================
FAIL: test_dataframe_dummies_prefix_str (pandas.tests.test_reshape.TestGetDummiesSparse)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\conda\Documents\pandas3.5\pandas\tests\test_reshape.py", line 327, in test_dataframe_dummies_prefix_str
    assert_frame_equal(result, expected)
  File "C:\Users\conda\Documents\pandas3.5\pandas\util\testing.py", line 1313, in assert_frame_equal
    obj='DataFrame.iloc[:, {0}]'.format(i))
  File "C:\Users\conda\Documents\pandas3.5\pandas\util\testing.py", line 1154, in assert_series_equal
    assert_attr_equal('dtype', left, right)
  File "C:\Users\conda\Documents\pandas3.5\pandas\util\testing.py", line 878, in assert_attr_equal
    left_attr, right_attr)
  File "C:\Users\conda\Documents\pandas3.5\pandas\util\testing.py", line 1018, in raise_assert_detail
    raise AssertionError(msg)
AssertionError: Attributes are different

Attribute "dtype" are different
[left]:  int64
[right]: int32

[jreback]

cc @gfyoung if you can get the first one, I can get the rest

[gfyoung]

@jreback : Okay, that sounds good.

[jorisvandenbossche]

@sinhrks maybe also already did something for the sparse ones?

@jreback What is the status actually with appveyor? Because I run them on master and it catched the sparse errors (but only after I merged the PR ..). Is it because it fails too often without good reason it is not activated in PRs?

[gfyoung]

@jorisvandenbossche : Did it fail on the read_table test ?

[jorisvandenbossche]

Apparantly not: https://ci.appveyor.com/project/jreback/pandas-465/build/1.0.962/job/ktes6kx97y0607ew

[gfyoung]

Okay, then I'm a little suspicious about this failure for read_table that @jreback is showing. Let me see what I get when I try to run locally.

[jreback]

I will fix the sparse ones. appveryor is very good at showing the errors. the parser error may not show on 2.7. appveyor will not run things after the first build (which is 2.7) fails. my output is from 3.5. (so could maybe only be there).

[jreback]

appveyor only runs on master (or you can setup it up yourself to run on your own PR's). but it won't run other's (I suppose we could change this, it is pretty fast now).

[gfyoung]

@jreback : If Appveyor is fast enough, I would vote for adding it to the PR checks.

[jreback]

@gfyoung yeah, if you can figure out the setting, lmk.

[gfyoung]

@jreback : What branches are you building currently? I thought it should be possible by default?

If we get stuck, we can cc numpy developers because they test on Appveyor for PR's.

[jreback]

I changed it to * on the config. So next PR give a check.

[jreback]

https://ci.appveyor.com/project/jreback/pandas-465/build/1.0.973

so passing on 2.7 / failing on 3.5 (for that single test).

[gfyoung]

@jreback : Doesn't seem like Appveyor is picking up #14147.

[jreback]

i don't think it works on PRs
you'll have to read the docs to enable
if u have an account then it should work

[gfyoung]

@jreback : Shouldn't have to. numpy doesn't require developers to have an Appveyor account, which leads me to believe it is a configuration option.

cc @njsmith : I'm not sure who has control of the Appveyor account on the numpy, but do you think you could provide some insight / help into this?

[jorisvandenbossche]

I think you can only have projects under your own personal account on appveyor and not for a github org? In that case, we maybe better make a 'pandas' account for appveyor. I can set this up.

[jreback]

https://travis-ci.org/pydata/pandas/jobs/157552565

replacates this failure on Travis (this is a proposed PR that can set some locales)

[gfyoung]

Ah...it could be a locale issue then because encoding = sys.systemencoding or 'utf-8'. The line of code in question is the following:

elif len(sep.encode(encoding)) > 1:

This check is specifically for the C engine, and I would like to provide a nice error / warning message should this check raise another Exception during theencodestep withengine=c'` that pre-empts the one I was going to use.

@jreback : What do you think is best? The awkward part is that the conditional is caught in the middle of an elif. I was thinking perhaps the following:

elif sep is not None:
   encodable = True
   try:
      if len(sep.encode(encoding)) > 1:
         encodable = False
   except UnicodeEncodeError:
      encodable = False
   if not encodable:
      ...

[gfyoung]

@jreback : My unsupported test is a flaky because of the locale dependency I realize (I can't replicate the error on Windows locally). Perhaps I should just remove the test?

[jreback]

This replicates on 3.5 windows for me:

======================================================================
FAIL: test_c_engine (pandas.io.tests.parser.test_unsupported.TestUnsupportedFeatures)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\conda\Documents\pandas3.5\pandas\io\tests\parser\test_unsupported.py", line 64, in test_c_engine
    read_table(StringIO(data), engine='c', sep='\xa7')
  File "C:\Users\conda\Documents\pandas3.5\pandas\util\testing.py", line 2450, in __exit__
    raise AssertionError("{0} not raised.".format(name))
AssertionError: ValueError not raised.

----------------------------------------------------------------------
Ran 10873 tests in 433.840s

FAILED (SKIP=168, failures=1)

In [2]: import pandas as pd

In [3]: pd.show_versions()

INSTALLED VERSIONS
------------------
commit: 59524af1e90d3dda2d885e711f7258704a020b6d
python: 3.5.1.final.0
python-bits: 64
OS: Windows
OS-release: 7
machine: AMD64
processor: Intel64 Family 6 Model 70 Stepping 1, GenuineIntel
byteorder: little
LC_ALL: None
LANG: None
LOCALE: None.None

pandas: 0.18.1+427.g59524af

I think the encoding is getting set to windows default

In [5]: sys.getdefaultencoding()
Out[5]: 'utf-8'

which seems ok (I though ascii) would trigger it.
I'd kind of like to keep this tests now that it shows on Travis as well (you can rebase off that xref PR, which shows on Travis to test if that helps).

[gfyoung]

Fair enough, but I think we should make a comment about the flakiness. BTW, what did you think about my try-except proposal above?

[jreback]

elif sep is not None:

   def do_on_encodable():
       ....

   try:
      if len(sep.encode(encoding)) > 1:
         do_on_encodable()
   except UnicodeEncodeError:
      do_on_encodable()

maybe a bit better

[gfyoung]

@jreback : idk if it's necessary to abstract away logic into a separate function, but I'll try putting up a PR with the change, and we can discuss there.

[jreback]

ok I think I enabled appveyor to work. It wasn't sending the pull-request webhook events, only a push. give it a try.