-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Python 3 support #8
Comments
see #26 |
Bummer. Thanks for the reply. |
It should help with issues blue-yonder#8 and blue-yonder#26
sooner or later we will have that python3 support :) until then, you could extract the features with a local python2.7 interpreter, pickle the dataframe and then load them into your python3.5 project |
I will look into this later |
I just uploaded the branch "i8_add_python3_support" on it, I started to make tsfresh runable under python3. Now, all unit tests are passing on python 2.7. On Python 3.5.1, 14 unit tests are failing. Maybe I will have time during the next days to finish the job. Otherwise it would be nice if somebody else could check the changes and getting that unit tests to pass. |
I will take a look. I have to do it for Skyline at some point and I really want to deep dive into what you are up to here, so it may be an effective method for me to start a Python 3 path in my own sphere and get a handle on how you do not run into some of the clustering issues relating to timeseries as with k-means et al. @jneuff I have read the paper now and dug a bit deep and I now understand a little more :) I should be say hey TPOT -> tsFRESH :) @MaxBenChrist anybody interested in having a go at porting any bits and pieces to Python 3 can use Python 3.5.2 (latest) unless there is a reason that Python 3.5.1 is required, which silence on the matter shall be read as Nice of blue-yonder and you all to release it, timeseries and ml not being easy and all, this looks like a step :) |
hi @earthgecko we are happy about anybody that wants to contribute. You could take my "i8_add_python3_support" branch as a starting point. Where do one find this Bytheway, to what are you referring with TPOT ? :) Max |
I have your i8_add_python3_support branch and I am working on that. Any changes A question concerning about how to handle Python 3 builtins in a backwards I shall add some additional detailed info on #30 for consideration. There is no flag, it was a question :) You are OK with using 3.5.2, there is no specific reason you are using 3.5.1? TPOT - https://github.com/rhiever/tpot - I initially thought that tsfresh was doing a subset of what TPOT does, but no TPOT could probably add a FRESH dimension :) |
Now down 5 failing unit tests from 14 The outstanding ones are mostly related to objects have no attribute 'assertItemsEqual' in a number of contexts and there is a pandas errors related to:
In tests/transformers/test_full_pipeline.py along with an AssertionError too, they may be related
|
Some info on blocking points (was playing with the Python3 branch but unfortunately have no time to go into depth or create a fix myself right now): The first Quickstart example yields:
. When using with
|
The current py2 py3 tests state in a gist - https://gist.github.com/earthgecko/118d168f88ebb37661154e3cb898c1fb |
The method assertItemsEqual has been removed from unites.TestCase somewhere along the way to Python 3.5 – we'll need to find a replacement with the same semantics. |
Due to a change in unittest in as identified by @jneuff in blue-yonder#8 (comment) Semantically they appear to be the same and this fixes the related failing tests on Python 3.5 as described in the gist in blue-yonder#8 (comment) Adds a basic method to determine python version for now, only committing so that the new deeper unitest.assertEqual issue that now presents itself can be addressed.
@jneuff yes! Semantically they appear to be the same, relating failing tests pass \o/ However, fixing that now just letting the next unittest.assertEqual issue raise its head, it seems that assertEqual has changed in py3 as well, that may go a bit deeper :( One step at a time :) assertEqual changeCurrent debug
Used in quite a few places - https://github.com/blue-yonder/tsfresh/search?q=assertEqual&type=Code and further to that it must be kept in mind that with tests with 2 elements, this could pass sometimes if any elements were returned in differing order each time.
|
* Changed xrange to range for #8 * Modified csort due to range changing from list to type for #8 * Use assertItemsEqual py2 and assertCountEqual py3 Due to a change in unittest in as identified by @jneuff in #8 (comment) Semantically they appear to be the same and this fixes the related failing tests on Python 3.5 as described in the gist in #8 (comment) Adds a basic method to determine python version for now, only committing so that the new deeper unitest.assertEqual issue that now presents itself can be addressed.
I rewrote those unittests with the six framework. Some of the unit tests still failed, the reason for that was the bug in #29 . I fixed that. Now you should be able to enjoy your fresh features under python3 :) |
* use python3 compatible print function * use absolute import for py3 support * in py3 one has to load reduce * check for basestring in column name * import range for py3 support * call list of range iterator * fixed standard library import * added builtin support for str, basestring, zip, object * class FeatureExtractionSettings inherits from baseobject * call list of iterator objects * change iter() to iteritems() * replaced filter by list comprehension * added future to requirements.txt * Changed xrange to range for #8 (#30) * csort range py3 compatible (#32) * Changed xrange to range for #8 * Modified csort due to range changing from list to type for #8 * Use assertItemsEqual py2 and assertCountEqual py3 Due to a change in unittest in as identified by @jneuff in #8 (comment) Semantically they appear to be the same and this fixes the related failing tests on Python 3.5 as described in the gist in #8 (comment) Adds a basic method to determine python version for now, only committing so that the new deeper unitest.assertEqual issue that now presents itself can be addressed. * pinned version of future package * added six to test-requirements.txt * use six for assertCountEqual unit testing * deleted some comments * use six for assertCountEqual to test feature_augmentor __dict__ will give iterator for properties * use six.assertCountEqual * use assertGreaterEqual to test subset * parameter have to be sorted in feature name fixes bug #29, features with multiple, but same parameters could end up with different names * added python 3.5.2 to .travis.yml closes #8
Currently we only support Python 2. In future releases we want to support both Python 2 and 3. This howto outlines the main steps towards Python 3 support.
The text was updated successfully, but these errors were encountered: