Skip to content
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.6 compatibility #367

Merged
merged 30 commits into from
Apr 25, 2018
Merged

Python 3.6 compatibility #367

merged 30 commits into from
Apr 25, 2018

Conversation

jdebacker
Copy link
Member

This PR updates OG-USA to run on both Python 2.7 and Python 3.6.

cc @rickecon

@jdebacker
Copy link
Member Author

All tests except for pickle comparisons in test_basic.py are passing in Python 3.6.

However, running the model generates errors. It looks like the solver for the household problem in the SS goes out of bounds and stays there, generating nan's. This doesn't happen in the tests of SS.py, so it is likely related to some input to the model changing. This needs to be diagnosed.

@jdebacker
Copy link
Member Author

Update: error running model has to do with trying to run model with analytical mtrs with tax function estimates with constant rates - this doesn't work given how we implement constant rates (because you get a division by zero issue in the mtr functions in tax.py.

@jdebacker jdebacker changed the title [WIP] Python 3.6 compatibility Python 3.6 compatibility Apr 23, 2018
@hdoupe
Copy link
Contributor

hdoupe commented Apr 23, 2018

@jdebacker what do you think about moving the try/except logic into a function?

Then, you could do something like:

def safe_read_pickle(file_path):
    with open(file_path, 'rb') as f:
        try:
            obj = pickle.load(f, encoding='latin1')
        except TypeError:
            obj = pickle.load(f) 
    return obj

That way you don't have so many of the try/except clauses in the code base. This would also make changing the logic around reading pickle files easier in the future since you would only have to change it in the function and not a bunch of times throughout the code-base.

@rickecon
Copy link
Member

@jdebacker @hdoupe . Is there any reason to maintain Python 2.7 compatability? That is, do Tax-Calculator, taxdata, or policybrain have any Python 2.7 dependencies? If not, we should leave it completely behind.

@jdebacker
Copy link
Member Author

Ok - I'm going to incorporate @hdoupe's suggestion to simplify the code a bit.

@rickecon, I think PB is still running 2.7. So I think we go ahead an maintain 2.7 compatibility for OG-USA for now (since it already has it). We can then simplify the code by dropping lines necessary only for backward compatibility in a future PR (around the time PB switches over).

@hdoupe
Copy link
Contributor

hdoupe commented Apr 24, 2018

@jdebacker that sounds good to me. I'm not sure what the python 2 to 3 conversion timeline looks like yet.

@@ -13,5 +11,6 @@ dependencies:
- numpy>=1.12.1
- pandas>=0.20.1
- pytest
- python=2.7
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be nice to declare python=3.6 as a dependency to encourage people to use it moving forward. Might make it easier to fully drop 2.7 when the time comes

@jdebacker jdebacker merged commit 6ba958c into PSLmodels:master Apr 25, 2018
@jdebacker jdebacker deleted the py3 branch April 25, 2018 14:59
keiirizawa pushed a commit to keiirizawa/OG-USA that referenced this pull request Mar 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants