My collection of Python 3.5.0 regressions
(Oh hey, I don't understand how I sent the previous email. Mistake with keyboard shortcut in Gmail?) Hi, Sadly, Python 3.5.0 comes with regressions. FYI I fixed the following regressions: "OSError in os.waitpid() on Windows" http://bugs.python.org/issue25118 "Windows: datetime.datetime.now() raises an OverflowError for date after year 2038" http://bugs.python.org/issue25155 "3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5)" http://bugs.python.org/issue25150 It may be good to not wait too long before releasing a first 3.5.1 bugfix version :-) I just pushed fixes. We may wait a little bit for buildbots ;-) -- There are some more issues which may be Python 3.5 regressions: "Regression: test_datetime fails on 3.5, Win 7, works on 3.4" http://bugs.python.org/issue25092 "asynico: add ssl_object extra info" http://bugs.python.org/issue25114 "test_httpservers hangs on 3.5.0, win 7" http://bugs.python.org/issue25095 Victor
Once Steve comes back from vacation he's going to have a lot of Windows install issues to look at. IMO, we should resolve those, and then issue 3.5.1. It's really too bad more people didn't test the installation with the release candidates, and I'm very glad that those people who did so did so....I know there were a significant number of issues with the new Windows installer infrastructure that were caught and fixed before final. On Fri, 18 Sep 2015 15:18:32 +0200, Victor Stinner <victor.stinner@gmail.com> wrote:
(Oh hey, I don't understand how I sent the previous email. Mistake with keyboard shortcut in Gmail?)
Hi,
Sadly, Python 3.5.0 comes with regressions. FYI I fixed the following regressions:
"OSError in os.waitpid() on Windows" http://bugs.python.org/issue25118
"Windows: datetime.datetime.now() raises an OverflowError for date after year 2038" http://bugs.python.org/issue25155
"3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5)" http://bugs.python.org/issue25150
It may be good to not wait too long before releasing a first 3.5.1 bugfix version :-)
I just pushed fixes. We may wait a little bit for buildbots ;-)
--
There are some more issues which may be Python 3.5 regressions:
"Regression: test_datetime fails on 3.5, Win 7, works on 3.4" http://bugs.python.org/issue25092
"asynico: add ssl_object extra info" http://bugs.python.org/issue25114
"test_httpservers hangs on 3.5.0, win 7" http://bugs.python.org/issue25095
Victor _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/rdmurray%40bitdance.com
On 18/09/2015 16:27, R. David Murray wrote:
Once Steve comes back from vacation he's going to have a lot of Windows install issues to look at. IMO, we should resolve those, and then issue 3.5.1.
It's really too bad more people didn't test the installation with the release candidates, and I'm very glad that those people who did so did so....I know there were a significant number of issues with the new Windows installer infrastructure that were caught and fixed before final.
I agree very strongly with your point here. Raising umpteen issues over installation failures when a full release comes out strikes me as below the belt when there have been multiple previous releases without a squeak. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
On 9/18/2015 9:18 AM, Victor Stinner wrote:
Sadly, Python 3.5.0 comes with regressions. FYI I fixed the following regressions:
The tracker needs a new keyword: '3.5regression', to match others.
"OSError in os.waitpid() on Windows" http://bugs.python.org/issue25118
"Windows: datetime.datetime.now() raises an OverflowError for date after year 2038" http://bugs.python.org/issue25155
"3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5)" http://bugs.python.org/issue25150
It may be good to not wait too long before releasing a first 3.5.1 bugfix version :-)
I just pushed fixes. We may wait a little bit for buildbots ;-)
--
There are some more issues which may be Python 3.5 regressions:
"Regression: test_datetime fails on 3.5, Win 7, works on 3.4" http://bugs.python.org/issue25092
"asynico: add ssl_object extra info" http://bugs.python.org/issue25114
"test_httpservers hangs on 3.5.0, win 7" http://bugs.python.org/issue25095
You also diagnosed another regression: "AST for dict and set displays has the lineno of the first value" https://bugs.python.org/issue25131 -- Terry Jan Reedy
Mark Lawrence writes:
I agree very strongly with your point here. Raising umpteen issues over installation failures when a full release comes out strikes me as below the belt when there have been multiple previous releases without a squeak.
Raising issues is always useful and appropriate. It's up to Larry Hastings to decide whether he personally needs to do more work. I suspect he probably will, though. I knew these changes were risky on the lead time given, even though I don't do Windows, and I'm not a core Python developer. I would hope that Steve Dower and Larry were at least as well aware of what they were getting into, and there are a lot of Windows users we *want* to support well. (*Not* "have to", and YMMV. But the Python developer community clearly has a working consensus on supporting Windows well.)
On 19 Sep 2015 15:40, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
Mark Lawrence writes:
I agree very strongly with your point here. Raising umpteen issues over installation failures when a full release comes out strikes me as below the belt when there have been multiple previous releases without a squeak.
Raising issues is always useful and appropriate. It's up to Larry Hastings to decide whether he personally needs to do more work.
I suspect he probably will, though. I knew these changes were risky on the lead time given, even though I don't do Windows, and I'm not a core Python developer. I would hope that Steve Dower and Larry were at least as well aware of what they were getting into, and there are a lot of Windows users we *want* to support well. (*Not* "have to", and YMMV. But the Python developer community clearly has a working consensus on supporting Windows well.)
There were some pretty big changes on the Windows side of things for Python 3.5.0 - not just porting the installer to the Wix toolset and migrating to a new of Visual Studio, but also adjusting to some fairly major underlying changes to the way the Microsoft C runtime works in general. As part of all that, I believe we also finally switched to being a well behaved Windows citizen and now default to installing into Program Files rather than the root of C:\. With the wide variety of system configurations out there, that degree of change from past practices was always going to encounter some teething troubles. Fortunately, we're unlikely to ever have to go through a shift like this again, and are now in a situation where our installation practices not only better align with Microsoft's recommendations, but are able to benefit from future evolution in the Wix toolset rather than necessarily having to track changes to Microsoft's recommendations directly. Cheers, Nick.
On 19/09/2015 06:38, Stephen J. Turnbull wrote:
Mark Lawrence writes:
I agree very strongly with your point here. Raising umpteen issues over installation failures when a full release comes out strikes me as below the belt when there have been multiple previous releases without a squeak.
Raising issues is always useful and appropriate. It's up to Larry Hastings to decide whether he personally needs to do more work.
My point is that issues were raised after the full release was made, but no attempt was made to test for these problems in any of the previous releases, whether alpha, beta or release candidate. There was advance warning here http://stevedower.id.au/blog/the-python-3-5-installer/, which was flagged up here http://www.gossamer-threads.com/lists/python/dev/1175080. Larry doesn't need to do anything that I'm aware of, except perhaps be guided by our windows gurus.
I suspect he probably will, though. I knew these changes were risky on the lead time given, even though I don't do Windows, and I'm not a core Python developer. I would hope that Steve Dower and Larry were at least as well aware of what they were getting into, and there are a lot of Windows users we *want* to support well. (*Not* "have to", and YMMV. But the Python developer community clearly has a working consensus on supporting Windows well.)
I'm certain that Steve was well aware of what he was getting into, Larry, at least with respect to Windows, I'm not so sure about. Not that it really matters to me. All I know is that the build procedures have been made easier on Windows, thanks mostly to Steve and Zach Ware in recent years, building on work done by Tim Golden, Martin v. Löwis and Mark Hammond amongst others. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
On 20 September 2015 at 18:03, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
I'm certain that Steve was well aware of what he was getting into, Larry, at least with respect to Windows, I'm not so sure about. Not that it really matters to me. All I know is that the build procedures have been made easier on Windows, thanks mostly to Steve and Zach Ware in recent years, building on work done by Tim Golden, Martin v. Löwis and Mark Hammond amongst others.
From a process perspective, the release manager is responsible for wrangling the release process, tagging the source tree, and creating and publishing the source tarball, but the binary installers are in the hands of the platform specialists listed in the release PEP (https://www.python.org/dev/peps/pep-0478/ in the case of 3.5).
The full release process is at https://www.python.org/dev/peps/pep-0101/, which has details of the unfortunately manual Windows installation testing process at the end. It might be interesting to see if running the installs at least in quiet mode could be automated on Appveyor to reduce the manual testing requirements. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (6)
-
Mark Lawrence -
Nick Coghlan -
R. David Murray -
Stephen J. Turnbull -
Terry Reedy -
Victor Stinner