About few days ago python-nightly started failing on TravisCI for no reason, and I dont think its due to my code. In fact it fails on importing numpy but fails to get into catch ImportError. This is a recent BUG. 

Build log:
https://travis-ci.org/construct/construct/jobs/241153020

The error is /home/travis/virtualenv/python3.7-dev/lib/python3.7/site-packages/numpy/core/multiarray.cpython-37m-x86_64-linux-gnu.so: undefined symbol: PyTraceMalloc_Untrack. On a quick look I couldn't find any recent changes in CPython related to tracemalloc.

It's because Julian thinks _PyTraceMalloc_Untrack is going to lose its underscore in 3.7, so he made numpy assume that. Numpy issue, I'll see what we can do.

Can we close this issue then?

Negative, this bug causes TravisCI to fail on every commit regardless of
code. Please treat this tickes as highest priority.

sob., 10 cze 2017 o 20:54 użytkownik Ned Deily <report@bugs.python.org>
napisał:

>
> Ned Deily added the comment:
>
> Can we close this issue then?
>
> ----------
> nosy: +ned.deily
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue30623>
> _______________________________________
>
-- 
~ Arkadiusz Bulski
~ tel 503 357 111 lub WhatsApp/Telegram

Sounds like the issue is with numpy, not CPython, so there's little reason to keep this CPython bug open.

Oh good point, but when I submitted this on TravisCI issues they pointed me
to here.
And this is a highest priority bug.

sob., 10 cze 2017 o 21:02 użytkownik Jelle Zijlstra <report@bugs.python.org>
napisał:

>
> Jelle Zijlstra added the comment:
>
> Sounds like the issue is with numpy, not CPython, so there's little reason
> to keep this CPython bug open.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue30623>
> _______________________________________
>
-- 
~ Arkadiusz Bulski
~ tel 503 357 111 lub WhatsApp/Telegram

@Arek: It's great that you're testing your code against the latest 3.7 pre-release, because that helps give early warning of issues in CPython as its developed, which helps everyone. BUT, you really cannot expect to use in-development versions and expect everything to be perfectly supported and work well together all the time -- we need time and space to work things out and coordinate. If you can't tolerate failures in your 3.7-prerelease builds, then you should remove them from you CI entirely and wait for the final release (or at least sometime in the beta/rc period).

Anyway-

Numpy bug here: https://github.com/numpy/numpy/issues/9227

This CPython PR is also relevant: https://github.com/python/cpython/pull/1236

Basically the bug is that numpy just made a release (1.13.0) which assumed that if it's running on some version of 3.7, then that PR is surely merged. But it turns out that that PR is not yet merged.

We'll probably need to make the usual emergency x.x.1 release in a few days anyway, and the simplest fix would be to switch back to the underscore-prefixed versions then. But... this needs a bit of coordination, because if we do that then the same thing will happen again at some point when that PR is merged; the problem here is that numpy was trying to avoid that breakage and thus created different breakage :-).

My suggestion would be that NumPy go ahead with releasing a fixed version ASAP, and *also* that CPython PR 1236 add back-compat for the underscore-prefixed versions. And maybe that it be merged soon if it's easy and going to happen anyway, since that will retroactively unbreak 1.13.0.

Bigger picture: I guess there's some irony that I warned that testing against prereleases can get complicated at the language summit based on numpy's experience, and now it's numpy's fault that cpython is getting grumpy users filing bugs at it... sorry about that. It's a useful data point though that we should keep in mind, that if we're encouraging people to test prereleases, then what used to be a temporary breakage that no-one would notice can actually cause more problems now – again, if numpy hadn't broken this now, PR 1236 would have at some point, and with the same results. (In the past it's been common that numpy just doesn't support a new python release until a month or two after it comes out! Apparently those days have passed...)

Thank you, I will temporarily remove the numpy unit test from the 3.7 until
I get notification that it was fixed.

sob., 10 cze 2017 o 22:48 użytkownik STINNER Victor <report@bugs.python.org>
napisał:

>
> Changes by STINNER Victor <victor.stinner@gmail.com>:
>
>
> ----------
> pull_requests: +2151
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue30623>
> _______________________________________
>
-- 
~ Arkadiusz Bulski
~ tel 503 357 111 lub WhatsApp/Telegram

There is a possible future in which the development style is based around continuous integration with third parties, where we apply our backward compatibility policy even to changes from one commit to the next within our development cycle.  I think that possible future is interesting, but is non-trivial to accomplish, and represents a cultural shift that we'd need to commit to.

If we go there then, as I believe was touched on at the language summit, actual python official releases would become less significant events :)

https://github.com/python/cpython/pull/1236 has been merged, I believe this issue can be closed.