-
-
Notifications
You must be signed in to change notification settings - Fork 2k
Failures on Windows with Python 3 (possible fix) #539
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
Failures on Windows with Python 3 (possible fix) #539
Conversation
|
@mdboom - this seemed to help. One of the Python 3 builds that was failing before now reports is it simply a case of a missing |
|
Interestingly, some Python 2 tests that were not failing before are now failing: If this becomes too hard to debug this way, I can start up the Windows VM I set up on AWS. |
|
The @iguananaut: I haven't used it in a while, and sorry if you explained this already and it slipped by me: do I need to do anything other than pushing to my staging branch to get the Windows Jenkins test to fire? |
|
Right now I don't even have a staging branch build for you on Windows. I had to delete them all at one point because the configs got messed up. I'll recreate it though. If you've already pushed to your staging branch I can then just manually kick off a build. |
|
Okay, I have it building ebd2778 right now. |
|
It looks like on Python 2.6 float formatting was done using system libraries, and these had different behavior on Linux vs. Windows. In Python 2.7/3.1 and later, Python includes its own float formatting code so that it's consistent everywhere. We're just seeing this failure now because the "precision" fields are being handled correctly for the first time in VOTable (the precision not being used properly before meant that this difference was hidden). We could include our own copy of the "dtoa" included with Python 2.7 for use on Python 2.6. Whether we can integrate that into the built-in string There might be a way to leverage Numpy (which is some cases does its own string formatting of numbers) to do this, but I haven't found a way to do it -- is there a Numpy function to format a number with precision that doesn't fallback to exponential notation? ( Lastly, we can just mark this test as known fail when the legacy float formatting is in use -- Python even provides This is from "What's new in Python 2.7":
|
|
I seem to recall encountering this float formatting issue somewhere myself. IIRC my solution at the time was to just re-reinvent the wheel and write my own float-formatting--just enough to deal with the parts that were inconsistent (in this case I believe it had to do with the number of digits after the exponent symbol. |
|
Yeah -- I've seen that "digits after the exponent" thing before, too... I think adding our own function seems like the thing to do -- but it's rather complex to get right. This is the code that Python 2.7/3.1 based their implementation on: Unlike glibc's implementation, this one has a BSD-like license. Here's CPython's modification of it: And we would need to add a very simple Python wrapper around that, of course. This shouldn't be horrible, but it does seem like a lot of work for a version of Python that is already seeing pretty light usage percentage-wise. |
|
I would just xfail this test in cases where it's expected to fail on Python 2.6. It's not like the results are actually that wrong that it would matter to the user anyway, right? |
|
Agreed that it probably wouldn't matter to the user. However, if the user requested a particular precision in VOTable, I think they are probably doing so for a reason and would care about getting all of the precision they asked for. I think the thing to do now is probably to xfail (so we can at least have tests passing) and open a new issue for the precision problem. |
|
I've added the xfails and pushed to my staging branch to make sure everything passes on Windows. Once that's true, I think this is good to merge. |
|
The Jenkins failure seems to be a network issue on just one of the configurations, so I'm going to go ahead and merge this. |
|
Sounds good! |
Failures on Windows with Python 3 (possible fix)
…-reading Failures on Windows with Python 3 (possible fix)
This is a shot in the dark to fix #538.