You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 30, 2023. It is now read-only.
As discussed in http://bugs.python.org/issue13703 , Python will eventually start using a randomized hash seed, which affects the iteration order of things like dicts and sets. Admittedly, this won't be enabled by default until Python 3.3, but the functionality can be turned on selectively all the way back to Python 2.6. When it IS turned on, it breaks a number of unit tests in the transitfeed library that make assumptions about the order of validation exceptions. The order of the exceptions can be a function of underlying dictionary iteration order, so the test end up being non-deterministic.
I happen to run the transitfeed library in a 2.7 environment where randomized hash seeding has been enabled by default, so I'd like to get these tests fixed. To do so, I will introduce a strict ordering of validation exceptions in unit tests that will be deterministic even if the original order of the exceptions is not.
From [email protected] on November 16, 2012 06:57:35
As discussed in http://bugs.python.org/issue13703 , Python will eventually start using a randomized hash seed, which affects the iteration order of things like dicts and sets. Admittedly, this won't be enabled by default until Python 3.3, but the functionality can be turned on selectively all the way back to Python 2.6. When it IS turned on, it breaks a number of unit tests in the transitfeed library that make assumptions about the order of validation exceptions. The order of the exceptions can be a function of underlying dictionary iteration order, so the test end up being non-deterministic.
I happen to run the transitfeed library in a 2.7 environment where randomized hash seeding has been enabled by default, so I'd like to get these tests fixed. To do so, I will introduce a strict ordering of validation exceptions in unit tests that will be deterministic even if the original order of the exceptions is not.
Original issue: http://code.google.com/p/googletransitdatafeed/issues/detail?id=352
The text was updated successfully, but these errors were encountered: