-
-
Notifications
You must be signed in to change notification settings - Fork 157
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
Add function to allow separate taxation of pass-through income #913
Conversation
Current coverage is 98.12% (diff: 100%)@@ master #913 diff @@
==========================================
Files 13 13
Lines 1818 1818
Methods 0 0
Messages 0 0
Branches 0 0
==========================================
Hits 1784 1784
Misses 34 34
Partials 0 0
|
@GoFroggyRun, Please remove tab characters from the
|
@GoFroggyRun, Please remove the following two lines from
And besides, the comment is incorrect: the new function is just as much of a function as the old |
@GoFroggyRun, I don't understand the basic approach to implementing the kinds of reforms discussed in pull request #913. Why create a new |
@martinholmer, thank you very much for your thoughtful comments. I have modified the PEP8 error, as well as the test suite. In regards to your third concenr:
Yes, I agree. We can definitely incorporate the
I'm not sure about this. Although there shouldn't be any problem to combine the cc @MattHJensen |
@martinholmer, my apologies that I am not familiar with the tax logic for pass-through tax. Your suggestion to generalize the current I added a separate set of parameters for pass-through taxes and used the new parameters in Please take a look. Comments, concerns, or remarks would be appreciated. (Especially on descriptions for those new parameters) |
@GoFroggyRun, The changes to With respect to the proposed changes in the |
I just updated the generalization of cc @MattHJensen |
Thanks @MattHJensen for helping me find out a typo in |
@GoFroggyRun, Doesn't the validations for the following entry in
Shouldn't that be |
@GoFroggyRun, I just don't see any reason why there should be differences in the |
I have modified the validation for the 6th bracket of
Sorry that I don't see an obvious explanation either, as there supposed to be no difference at all, theoretically. But given the difference is rather minor, it seems to me that these are some rounding error. |
@GoFroggyRun said:
But that was the explanation you offered when there were aggregate revenue differences, but it turned out that those differences were being caused by a coding error. Why don't you use the |
Thanks @martinholmer for your recent PR #916 on the MTR calculation. |
@GoFroggyRun said:
So, then why is the |
@GoFroggyRun, OK this looks better after your last commit. Later this afternoon, I'll test pull request #913 on my computer, and if all goes well (as I now expect), I'll then merge #913 into the master branch. Thanks for all your work on this important addition to Tax-Calculator. |
@martinholmer |
@GoFroggyRun, Your pull request #913 is incomplete because apparently you have not run all the tests: namely the reform comparison test in the
You really do need to get in the habit of running all the tests before submitting a pull request. |
@martinholmer |
@GoFroggyRun, Thanks for all the work on PR#913. Now merged into the master branch. |
Yes, thanks a lot @GoFroggyRun and also @codykallen for getting things started and @martinholmer for review. |
This PR breaks tax-calculator's backwards compatibility. @GoFroggyRun, could you please open a PR if possible or if not post an issue to www.github.com/opensourcepolicycenter/webapp-public that makes it so that TaxBrain's regular tax rate and bracket parameters modify both II and PT rt and brk parameters? This must be done before a new version of TC is deployed to TB. Alternatively, we would need to solve #861 in some way that restores backwards compatibility. cc @martinholmer, @talumbau, @andersonfrailey, @Amy-Xu, @rickecon, @jdebacker |
This PR streamlines the function
ptTaxer
that was original being added in PR #868, and thus should yield the exact same results as PR #868 does.Essentially, a for-loop has been used to replace some tedious code lines. In order to do so, a new array,
II
, is defined to collect income brackets information.Merging conflicts have also been resolved.
Comments, concerns or remarks would be appreciated.
@MattHJensen @martinholmer