Re: [Numpy-discussion] Remove bento from numpy
On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris charlesr.har...@gmail.com wrote: Ralf likes the speed of bento, but it is not currently maintained What exactly is not maintained ? David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Questions about fixes for 1.9.0rc2
On Sat, Jul 5, 2014 at 1:41 AM, Nathaniel Smith n...@pobox.com wrote: On 5 Jul 2014 00:07, Charles R Harris charlesr.har...@gmail.com wrote: I've filed issues with all the affected projects. Here is the current status. matplotlib -- Reported, being fixed, should be in 1.4 in a few days. skimage -- Reported. scikit-learn -- Reported. tables -- Reported. statsmodels -- Reported, fixed in master. bottleneck -- Reported. IIRC, kwgoodman already knew of the changes. pyfits -- Reported to astropy. milk -- Reported. pandas -- Reportedly fixed in master. That is a massive pile of affected projects :-(. My worry is that if all these projects we know about are broken, then how many other codebases that we aren't testing are also broken? Same worry here. If a major change in numpy breaks ~half of the projects that make up a typical scipy stack, that change should not be made without at least one release that emits warnings first. We would have caught this much earlier had we had something like https://github.com/matthew-brett/scipy-stack-osx-testing. Maybe a good idea to have that as a separate repo in the numpy org, add a few more projects to it, and then regularly run numpy master (or a PR) against the latest releases of those projects. Ralf If the issues are fixed in matplotlib and pandas I'd be inclined to release as is with a mention of versions in the release notes. Even if it's fixed in pandas master, how long until it's in user's hands? -n Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Remove bento from numpy
On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau courn...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris charlesr.har...@gmail.com wrote: Ralf likes the speed of bento, but it is not currently maintained What exactly is not maintained ? The issue is that Julian made some slightly nontrivial changes to core/setup.py and didn't want to update core/bscript. No one else has taken the time either to make those changes. That didn't bother me enough yet to go fix it, because they're all optional features and using Bento builds works just fine at the moment (and is part of the Travis CI test runs, so it'll keep working). I don't think the above is a good reason to remove Bento support. The much faster builds alone are a good reason to keep it. And the assertion that all numpy devs understand numpy.distutils is more than a little questionable:) Ralf David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Remove bento from numpy
On Sat, Jul 5, 2014 at 5:23 PM, Ralf Gommers ralf.gomm...@gmail.com wrote: On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau courn...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris charlesr.har...@gmail.com wrote: Ralf likes the speed of bento, but it is not currently maintained What exactly is not maintained ? The issue is that Julian made some slightly nontrivial changes to core/setup.py and didn't want to update core/bscript. No one else has taken the time either to make those changes. That didn't bother me enough yet to go fix it, because they're all optional features and using Bento builds works just fine at the moment (and is part of the Travis CI test runs, so it'll keep working). What are those changes ? David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Remove bento from numpy
On Sat, Jul 5, 2014 at 10:44 AM, David Cournapeau courn...@gmail.com wrote: On Sat, Jul 5, 2014 at 5:23 PM, Ralf Gommers ralf.gomm...@gmail.com wrote: On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau courn...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris charlesr.har...@gmail.com wrote: Ralf likes the speed of bento, but it is not currently maintained What exactly is not maintained ? The issue is that Julian made some slightly nontrivial changes to core/setup.py and didn't want to update core/bscript. No one else has taken the time either to make those changes. That didn't bother me enough yet to go fix it, because they're all optional features and using Bento builds works just fine at the moment (and is part of the Travis CI test runs, so it'll keep working). What are those changes? Comment in bscript: # TODO: add OPTIONAL_HEADERS, OPTIONAL_INTRINSICS and # OPTIONAL_GCC_ATTRIBUTES (see setup.py and gh-3766). These are # performance optimizations for GCC. Plus the changes in https://github.com/numpy/numpy/pull/4692, that apparently weren't documented in bscript as TODO. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Remove bento from numpy
On 05.07.2014 11:02, Ralf Gommers wrote: On Sat, Jul 5, 2014 at 10:44 AM, David Cournapeau courn...@gmail.com mailto:courn...@gmail.com wrote: On Sat, Jul 5, 2014 at 5:23 PM, Ralf Gommers ralf.gomm...@gmail.com mailto:ralf.gomm...@gmail.com wrote: On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau courn...@gmail.com mailto:courn...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris charlesr.har...@gmail.com mailto:charlesr.har...@gmail.com wrote: Ralf likes the speed of bento, but it is not currently maintained What exactly is not maintained ? The issue is that Julian made some slightly nontrivial changes to core/setup.py and didn't want to update core/bscript. No one else has taken the time either to make those changes. That didn't bother me enough yet to go fix it, because they're all optional features and using Bento builds works just fine at the moment (and is part of the Travis CI test runs, so it'll keep working). What are those changes? Comment in bscript: # TODO: add OPTIONAL_HEADERS, OPTIONAL_INTRINSICS and # OPTIONAL_GCC_ATTRIBUTES (see setup.py and gh-3766). These are # performance optimizations for GCC. Plus the changes in https://github.com/numpy/numpy/pull/4692, that apparently weren't documented in bscript as TODO. + bento builds in debug mode which is could be slower because I sprinkled asserts in lots of places ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Remove bento from numpy
On 5 Jul 2014 09:23, Ralf Gommers ralf.gomm...@gmail.com wrote: On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau courn...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris charlesr.har...@gmail.com wrote: Ralf likes the speed of bento, but it is not currently maintained What exactly is not maintained ? The issue is that Julian made some slightly nontrivial changes to core/setup.py and didn't want to update core/bscript. No one else has taken the time either to make those changes. That didn't bother me enough yet to go fix it, because they're all optional features and using Bento builds works just fine at the moment (and is part of the Travis CI test runs, so it'll keep working). Perhaps a compromise would be to declare it officially unsupported and remove it from Travis CI, while leaving the files in place to be used on an at-your-own-risk basis? As long as it's in Travis, the default is that anyone who breaks it has to fix it. If it's not in Travis, then the default is that the people (person?) who use bento are responsible for keeping it working for their needs. I don't think the above is a good reason to remove Bento support. The much faster builds alone are a good reason to keep it. And the assertion that all numpy devs understand numpy.distutils is more than a little questionable:) They surely don't. But thousands of people use setup.py, and one or two use bento. Yet supporting both requires twice as much energy and attention as supporting just one. We've probably spent more person-hours talking about this, documenting the missing bscript bits, etc. than you've saved on those fast builds. -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Remove bento from numpy
On Sat, Jul 5, 2014 at 1:54 PM, Nathaniel Smith n...@pobox.com wrote: On 5 Jul 2014 09:23, Ralf Gommers ralf.gomm...@gmail.com wrote: On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau courn...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris charlesr.har...@gmail.com wrote: Ralf likes the speed of bento, but it is not currently maintained What exactly is not maintained ? The issue is that Julian made some slightly nontrivial changes to core/setup.py and didn't want to update core/bscript. No one else has taken the time either to make those changes. That didn't bother me enough yet to go fix it, because they're all optional features and using Bento builds works just fine at the moment (and is part of the Travis CI test runs, so it'll keep working). Perhaps a compromise would be to declare it officially unsupported and remove it from Travis CI, while leaving the files in place to be used on an at-your-own-risk basis? As long as it's in Travis, the default is that anyone who breaks it has to fix it. If it's not in Travis, then the default is that the people (person?) who use bento are responsible for keeping it working for their needs. -1 that just means that simple changes like adding a new extension will not get made before PRs get merged, and bento support will be in a broken state much more often. I don't think the above is a good reason to remove Bento support. The much faster builds alone are a good reason to keep it. And the assertion that all numpy devs understand numpy.distutils is more than a little questionable:) They surely don't. But thousands of people use setup.py, and one or two use bento. I'm getting a little tired of these assertions. It's clear that David and I use it. A cursory search on Github reveals that Stefan, Fabian, Jonas and @aksarkar do (or did) as well: https://github.com/scipy/scipy/commit/74d823b3 https://github.com/numpy/numpy/issues/2993 https://github.com/numpy/numpy/pull/3606 https://github.com/numpy/numpy/issues/3889 For every user you can measure there's usually a number of users that you don't hear about. Yet supporting both requires twice as much energy and attention as supporting just one. That's of course not true. For most changes the differences in where and how to update the build systems are small. Only for unusual changes like Julian patches to make use of optional GCC features, Bento and distutils may require very different changes. We've probably spent more person-hours talking about this, documenting the missing bscript bits, etc. than you've saved on those fast builds. Then maybe stop talking about it:) Besides the fast builds, which is only one example of why I like Bento better, there's also the fundamental question of what we do with build tools in the long term. It's clear that distutils is a dead end. All the PEPs related to packaging move in the direction of supporting tools like Bento better. If in the future we need significant new features in our build tool, Bento is a much better base to build on than numpy.distutils. It's unfortunate that at the moment there's no one that works on improving our build situation, but that is what it is. Removing Bento support is a step in the wrong direction imho. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Remove bento from numpy
On Sat, Jul 5, 2014 at 2:32 PM, Ralf Gommers ralf.gomm...@gmail.com wrote: On Sat, Jul 5, 2014 at 1:54 PM, Nathaniel Smith n...@pobox.com wrote: On 5 Jul 2014 09:23, Ralf Gommers ralf.gomm...@gmail.com wrote: On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau courn...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris charlesr.har...@gmail.com wrote: Ralf likes the speed of bento, but it is not currently maintained What exactly is not maintained ? The issue is that Julian made some slightly nontrivial changes to core/setup.py and didn't want to update core/bscript. No one else has taken the time either to make those changes. That didn't bother me enough yet to go fix it, because they're all optional features and using Bento builds works just fine at the moment (and is part of the Travis CI test runs, so it'll keep working). Perhaps a compromise would be to declare it officially unsupported and remove it from Travis CI, while leaving the files in place to be used on an at-your-own-risk basis? As long as it's in Travis, the default is that anyone who breaks it has to fix it. If it's not in Travis, then the default is that the people (person?) who use bento are responsible for keeping it working for their needs. -1 that just means that simple changes like adding a new extension will not get made before PRs get merged, and bento support will be in a broken state much more often. Yes, and then the handful of people who care about this would fix it or not. Your -1 is attempting to veto other people's *not* paying attention to this build system. I... don't think -1's work that way :-( I don't think the above is a good reason to remove Bento support. The much faster builds alone are a good reason to keep it. And the assertion that all numpy devs understand numpy.distutils is more than a little questionable:) They surely don't. But thousands of people use setup.py, and one or two use bento. I'm getting a little tired of these assertions. It's clear that David and I use it. A cursory search on Github reveals that Stefan, Fabian, Jonas and @aksarkar do (or did) as well: https://github.com/scipy/scipy/commit/74d823b3 https://github.com/numpy/numpy/issues/2993 https://github.com/numpy/numpy/pull/3606 https://github.com/numpy/numpy/issues/3889 For every user you can measure there's usually a number of users that you don't hear about. I apologize for forgetting before that you do use Bento, but these patches you're finding don't really change the overall picture. Let's assume that there are 100 people using Bento, who would be slightly inconvenienced if they had to use setup.py instead, or got stuck patching the bento build themselves to keep it working. 100 is probably an order of magnitude too high, but whatever. OTOH numpy has almost 7 million downloads on PyPI+sf.net, of which approximately every one used setup.py one way or another, plus all the people get it from alternative channels like distros, which also AFAIK universally use setup.py. Software development is all about trade-offs. Time that numpy developers spend messing about with bento to benefit those hundred users is time that could instead be spent on improvements that benefit many orders of magnitudes more users. Why do you want us to spend our time producing x units of value when we could instead be producing 100*x units of value for the same effort? Yet supporting both requires twice as much energy and attention as supporting just one. That's of course not true. For most changes the differences in where and how to update the build systems are small. Only for unusual changes like Julian patches to make use of optional GCC features, Bento and distutils may require very different changes. We've probably spent more person-hours talking about this, documenting the missing bscript bits, etc. than you've saved on those fast builds. Then maybe stop talking about it:) Besides the fast builds, which is only one example of why I like Bento better, there's also the fundamental question of what we do with build tools in the long term. It's clear that distutils is a dead end. All the PEPs related to packaging move in the direction of supporting tools like Bento better. If in the future we need significant new features in our build tool, Bento is a much better base to build on than numpy.distutils. It's unfortunate that at the moment there's no one that works on improving our build situation, but that is what it is. Removing Bento support is a step in the wrong direction imho. We must do something! This is something! Bento is pre-alpha software whose last upstream commit was in July 2013. It's own CI tests have been failing since Feb. 2013, almost a year and a half ago. Bento build support was added to numpy in early 2011, and 3.5 years later it still hasn't convinced most of the core team that it provides any value at all, yet it continues
Re: [Numpy-discussion] Remove bento from numpy
On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith n...@pobox.com wrote: On Sat, Jul 5, 2014 at 2:32 PM, Ralf Gommers ralf.gomm...@gmail.com wrote: On Sat, Jul 5, 2014 at 1:54 PM, Nathaniel Smith n...@pobox.com wrote: On 5 Jul 2014 09:23, Ralf Gommers ralf.gomm...@gmail.com wrote: On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau courn...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris charlesr.har...@gmail.com wrote: Ralf likes the speed of bento, but it is not currently maintained What exactly is not maintained ? The issue is that Julian made some slightly nontrivial changes to core/setup.py and didn't want to update core/bscript. No one else has taken the time either to make those changes. That didn't bother me enough yet to go fix it, because they're all optional features and using Bento builds works just fine at the moment (and is part of the Travis CI test runs, so it'll keep working). Perhaps a compromise would be to declare it officially unsupported and remove it from Travis CI, while leaving the files in place to be used on an at-your-own-risk basis? As long as it's in Travis, the default is that anyone who breaks it has to fix it. If it's not in Travis, then the default is that the people (person?) who use bento are responsible for keeping it working for their needs. -1 that just means that simple changes like adding a new extension will not get made before PRs get merged, and bento support will be in a broken state much more often. Yes, and then the handful of people who care about this would fix it or not. Your -1 is attempting to veto other people's *not* paying attention to this build system. I... don't think -1's work that way :-( I don't think the above is a good reason to remove Bento support. The much faster builds alone are a good reason to keep it. And the assertion that all numpy devs understand numpy.distutils is more than a little questionable:) They surely don't. But thousands of people use setup.py, and one or two use bento. I'm getting a little tired of these assertions. It's clear that David and I use it. A cursory search on Github reveals that Stefan, Fabian, Jonas and @aksarkar do (or did) as well: https://github.com/scipy/scipy/commit/74d823b3 https://github.com/numpy/numpy/issues/2993 https://github.com/numpy/numpy/pull/3606 https://github.com/numpy/numpy/issues/3889 For every user you can measure there's usually a number of users that you don't hear about. I apologize for forgetting before that you do use Bento, but these patches you're finding don't really change the overall picture. Let's assume that there are 100 people using Bento, who would be slightly inconvenienced if they had to use setup.py instead, or got stuck patching the bento build themselves to keep it working. 100 is probably an order of magnitude too high, but whatever. OTOH numpy has almost 7 million downloads on PyPI+sf.net, of which approximately every one used setup.py one way or another, plus all the people get it from alternative channels like distros, which also AFAIK universally use setup.py. Software development is all about trade-offs. Time that numpy developers spend messing about with bento to benefit those hundred users is time that could instead be spent on improvements that benefit many orders of magnitudes more users. Why do you want us to spend our time producing x units of value when we could instead be producing 100*x units of value for the same effort? Yet supporting both requires twice as much energy and attention as supporting just one. That's of course not true. For most changes the differences in where and how to update the build systems are small. Only for unusual changes like Julian patches to make use of optional GCC features, Bento and distutils may require very different changes. We've probably spent more person-hours talking about this, documenting the missing bscript bits, etc. than you've saved on those fast builds. Then maybe stop talking about it:) Besides the fast builds, which is only one example of why I like Bento better, there's also the fundamental question of what we do with build tools in the long term. It's clear that distutils is a dead end. All the PEPs related to packaging move in the direction of supporting tools like Bento better. If in the future we need significant new features in our build tool, Bento is a much better base to build on than numpy.distutils. It's unfortunate that at the moment there's no one that works on improving our build situation, but that is what it is. Removing Bento support is a step in the wrong direction imho. We must do something! This is something! Bento is pre-alpha software whose last upstream commit was in July 2013. It's own CI tests have been failing since Feb. 2013, almost a year
Re: [Numpy-discussion] Remove bento from numpy
On Sat, Jul 5, 2014 at 3:21 PM, David Cournapeau courn...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith n...@pobox.com wrote: On Sat, Jul 5, 2014 at 2:32 PM, Ralf Gommers ralf.gomm...@gmail.com wrote: On Sat, Jul 5, 2014 at 1:54 PM, Nathaniel Smith n...@pobox.com wrote: On 5 Jul 2014 09:23, Ralf Gommers ralf.gomm...@gmail.com wrote: On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau courn...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris charlesr.har...@gmail.com wrote: Ralf likes the speed of bento, but it is not currently maintained What exactly is not maintained ? The issue is that Julian made some slightly nontrivial changes to core/setup.py and didn't want to update core/bscript. No one else has taken the time either to make those changes. That didn't bother me enough yet to go fix it, because they're all optional features and using Bento builds works just fine at the moment (and is part of the Travis CI test runs, so it'll keep working). Perhaps a compromise would be to declare it officially unsupported and remove it from Travis CI, while leaving the files in place to be used on an at-your-own-risk basis? As long as it's in Travis, the default is that anyone who breaks it has to fix it. If it's not in Travis, then the default is that the people (person?) who use bento are responsible for keeping it working for their needs. -1 that just means that simple changes like adding a new extension will not get made before PRs get merged, and bento support will be in a broken state much more often. Yes, and then the handful of people who care about this would fix it or not. Your -1 is attempting to veto other people's *not* paying attention to this build system. I... don't think -1's work that way :-( I don't think the above is a good reason to remove Bento support. The much faster builds alone are a good reason to keep it. And the assertion that all numpy devs understand numpy.distutils is more than a little questionable:) They surely don't. But thousands of people use setup.py, and one or two use bento. I'm getting a little tired of these assertions. It's clear that David and I use it. A cursory search on Github reveals that Stefan, Fabian, Jonas and @aksarkar do (or did) as well: https://github.com/scipy/scipy/commit/74d823b3 https://github.com/numpy/numpy/issues/2993 https://github.com/numpy/numpy/pull/3606 https://github.com/numpy/numpy/issues/3889 For every user you can measure there's usually a number of users that you don't hear about. I apologize for forgetting before that you do use Bento, but these patches you're finding don't really change the overall picture. Let's assume that there are 100 people using Bento, who would be slightly inconvenienced if they had to use setup.py instead, or got stuck patching the bento build themselves to keep it working. 100 is probably an order of magnitude too high, but whatever. OTOH numpy has almost 7 million downloads on PyPI+sf.net, of which approximately every one used setup.py one way or another, plus all the people get it from alternative channels like distros, which also AFAIK universally use setup.py. Software development is all about trade-offs. Time that numpy developers spend messing about with bento to benefit those hundred users is time that could instead be spent on improvements that benefit many orders of magnitudes more users. Why do you want us to spend our time producing x units of value when we could instead be producing 100*x units of value for the same effort? Yet supporting both requires twice as much energy and attention as supporting just one. That's of course not true. For most changes the differences in where and how to update the build systems are small. Only for unusual changes like Julian patches to make use of optional GCC features, Bento and distutils may require very different changes. We've probably spent more person-hours talking about this, documenting the missing bscript bits, etc. than you've saved on those fast builds. Then maybe stop talking about it:) Besides the fast builds, which is only one example of why I like Bento better, there's also the fundamental question of what we do with build tools in the long term. It's clear that distutils is a dead end. All the PEPs related to packaging move in the direction of supporting tools like Bento better. If in the future we need significant new features in our build tool, Bento is a much better base to build on than numpy.distutils. It's unfortunate that at the moment there's no one that works on improving our build situation, but that is what it is. Removing Bento support is a step in the wrong direction imho. We must do something! This is something! Bento is pre-alpha software
Re: [Numpy-discussion] Remove bento from numpy
On Sat, Jul 5, 2014 at 8:28 AM, Matthew Brett matthew.br...@gmail.com wrote: On Sat, Jul 5, 2014 at 3:21 PM, David Cournapeau courn...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith n...@pobox.com wrote: On Sat, Jul 5, 2014 at 2:32 PM, Ralf Gommers ralf.gomm...@gmail.com wrote: On Sat, Jul 5, 2014 at 1:54 PM, Nathaniel Smith n...@pobox.com wrote: On 5 Jul 2014 09:23, Ralf Gommers ralf.gomm...@gmail.com wrote: On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau courn...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris charlesr.har...@gmail.com wrote: Ralf likes the speed of bento, but it is not currently maintained What exactly is not maintained ? The issue is that Julian made some slightly nontrivial changes to core/setup.py and didn't want to update core/bscript. No one else has taken the time either to make those changes. That didn't bother me enough yet to go fix it, because they're all optional features and using Bento builds works just fine at the moment (and is part of the Travis CI test runs, so it'll keep working). Perhaps a compromise would be to declare it officially unsupported and remove it from Travis CI, while leaving the files in place to be used on an at-your-own-risk basis? As long as it's in Travis, the default is that anyone who breaks it has to fix it. If it's not in Travis, then the default is that the people (person?) who use bento are responsible for keeping it working for their needs. -1 that just means that simple changes like adding a new extension will not get made before PRs get merged, and bento support will be in a broken state much more often. Yes, and then the handful of people who care about this would fix it or not. Your -1 is attempting to veto other people's *not* paying attention to this build system. I... don't think -1's work that way :-( I don't think the above is a good reason to remove Bento support. The much faster builds alone are a good reason to keep it. And the assertion that all numpy devs understand numpy.distutils is more than a little questionable:) They surely don't. But thousands of people use setup.py, and one or two use bento. I'm getting a little tired of these assertions. It's clear that David and I use it. A cursory search on Github reveals that Stefan, Fabian, Jonas and @aksarkar do (or did) as well: https://github.com/scipy/scipy/commit/74d823b3 https://github.com/numpy/numpy/issues/2993 https://github.com/numpy/numpy/pull/3606 https://github.com/numpy/numpy/issues/3889 For every user you can measure there's usually a number of users that you don't hear about. I apologize for forgetting before that you do use Bento, but these patches you're finding don't really change the overall picture. Let's assume that there are 100 people using Bento, who would be slightly inconvenienced if they had to use setup.py instead, or got stuck patching the bento build themselves to keep it working. 100 is probably an order of magnitude too high, but whatever. OTOH numpy has almost 7 million downloads on PyPI+sf.net, of which approximately every one used setup.py one way or another, plus all the people get it from alternative channels like distros, which also AFAIK universally use setup.py. Software development is all about trade-offs. Time that numpy developers spend messing about with bento to benefit those hundred users is time that could instead be spent on improvements that benefit many orders of magnitudes more users. Why do you want us to spend our time producing x units of value when we could instead be producing 100*x units of value for the same effort? Yet supporting both requires twice as much energy and attention as supporting just one. That's of course not true. For most changes the differences in where and how to update the build systems are small. Only for unusual changes like Julian patches to make use of optional GCC features, Bento and distutils may require very different changes. We've probably spent more person-hours talking about this, documenting the missing bscript bits, etc. than you've saved on those fast builds. Then maybe stop talking about it:) Besides the fast builds, which is only one example of why I like Bento better, there's also the fundamental question of what we do with build tools in the long term. It's clear that distutils is a dead end. All the PEPs related to packaging move in the direction of supporting tools like Bento better. If in the future we need significant new features in our build tool, Bento is a much better base to build on than numpy.distutils. It's unfortunate that at the moment there's no one
Re: [Numpy-discussion] Remove bento from numpy
On Sat, Jul 5, 2014 at 11:51 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Sat, Jul 5, 2014 at 8:28 AM, Matthew Brett matthew.br...@gmail.com wrote: On Sat, Jul 5, 2014 at 3:21 PM, David Cournapeau courn...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith n...@pobox.com wrote: On Sat, Jul 5, 2014 at 2:32 PM, Ralf Gommers ralf.gomm...@gmail.com wrote: On Sat, Jul 5, 2014 at 1:54 PM, Nathaniel Smith n...@pobox.com wrote: On 5 Jul 2014 09:23, Ralf Gommers ralf.gomm...@gmail.com wrote: On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau courn...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris charlesr.har...@gmail.com wrote: Ralf likes the speed of bento, but it is not currently maintained What exactly is not maintained ? The issue is that Julian made some slightly nontrivial changes to core/setup.py and didn't want to update core/bscript. No one else has taken the time either to make those changes. That didn't bother me enough yet to go fix it, because they're all optional features and using Bento builds works just fine at the moment (and is part of the Travis CI test runs, so it'll keep working). Perhaps a compromise would be to declare it officially unsupported and remove it from Travis CI, while leaving the files in place to be used on an at-your-own-risk basis? As long as it's in Travis, the default is that anyone who breaks it has to fix it. If it's not in Travis, then the default is that the people (person?) who use bento are responsible for keeping it working for their needs. -1 that just means that simple changes like adding a new extension will not get made before PRs get merged, and bento support will be in a broken state much more often. Yes, and then the handful of people who care about this would fix it or not. Your -1 is attempting to veto other people's *not* paying attention to this build system. I... don't think -1's work that way :-( I don't think the above is a good reason to remove Bento support. The much faster builds alone are a good reason to keep it. And the assertion that all numpy devs understand numpy.distutils is more than a little questionable:) They surely don't. But thousands of people use setup.py, and one or two use bento. I'm getting a little tired of these assertions. It's clear that David and I use it. A cursory search on Github reveals that Stefan, Fabian, Jonas and @aksarkar do (or did) as well: https://github.com/scipy/scipy/commit/74d823b3 https://github.com/numpy/numpy/issues/2993 https://github.com/numpy/numpy/pull/3606 https://github.com/numpy/numpy/issues/3889 For every user you can measure there's usually a number of users that you don't hear about. I apologize for forgetting before that you do use Bento, but these patches you're finding don't really change the overall picture. Let's assume that there are 100 people using Bento, who would be slightly inconvenienced if they had to use setup.py instead, or got stuck patching the bento build themselves to keep it working. 100 is probably an order of magnitude too high, but whatever. OTOH numpy has almost 7 million downloads on PyPI+sf.net, of which approximately every one used setup.py one way or another, plus all the people get it from alternative channels like distros, which also AFAIK universally use setup.py. Software development is all about trade-offs. Time that numpy developers spend messing about with bento to benefit those hundred users is time that could instead be spent on improvements that benefit many orders of magnitudes more users. Why do you want us to spend our time producing x units of value when we could instead be producing 100*x units of value for the same effort? Yet supporting both requires twice as much energy and attention as supporting just one. That's of course not true. For most changes the differences in where and how to update the build systems are small. Only for unusual changes like Julian patches to make use of optional GCC features, Bento and distutils may require very different changes. We've probably spent more person-hours talking about this, documenting the missing bscript bits, etc. than you've saved on those fast builds. Then maybe stop talking about it:) Besides the fast builds, which is only one example of why I like Bento better, there's also the fundamental question of what we do with build tools in the long term. It's clear that distutils is a dead end. All the PEPs related to packaging move in the direction of supporting tools like Bento better. If in the future we need significant new features in our build tool, Bento is a much better
Re: [Numpy-discussion] Fast way to convert (nested) list to numpy object array?
On Fr, 2014-07-04 at 17:32 +0200, Marc Hulsman wrote:
On 07/03/2014 02:44 PM, Sebastian Berg wrote:
True and true. I don't see a problem with fromiter being more general,
just someone has to sit down and add new error checks/cleanup stuff
for the object case. The assignment could probably also be optimized,
not sure how hard that is, I would expect it isn't that hard. As
usually, someone just needs to find time and the interest to actually
do it ;). - Sebastian
I looked at the code of FromIter below.
/*
* We would need to alter the memory RENEW code to decrement any
* reference counts before throwing away any memory.
*/
if (PyDataType_REFCHK(dtype)) {
PyErr_SetString(PyExc_ValueError,
cannot create object arrays from iterator);
goto done;
}
However, the memory renew code (which just reallocs the memory to
increase the array size) uses
a simple realloc. It seems to me that it is not necessary to adapt
reference counts in this case (as the incref
from the new memory compensates the decref from the memory that is
removed)? For the addition of elements
to the array, everything seems to be ok anyway, as setitem is used,
which does the incref already.
So I think it should be possible to just remove this check?
Yes and no. I agree that the comment was just being overly careful,
since the renew will copy the pointers without calling Py_INCREF.
However, you *will* need to add new error cleanup logic in case the
iterator throws an error, or you run out of memory. Since then you need
to decref everything again.
I did not yet look at the assignment issue, had some difficulty finding
the correct place in the code, does does
anyone have any pointers were to look?
This is handled by PyArray_CopyObject in arrayobject.c. The actual logic
is probably done by PyArray_GetArrayParamsFromObject in ctors.c, that is
a public function, so my guess is, you would have to create a new one
which allows passing in a maximum ndim and then make the old one call
that one with NPY_MAXDIMS (or whatever it was)
- Sebastian
The generic solution of adding an nmaxdim parameter to numpy.array would
of course be even more ideal :)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Questions about fixes for 1.9.0rc2
On Sa, 2014-07-05 at 00:41 +0100, Nathaniel Smith wrote: On 5 Jul 2014 00:07, Charles R Harris charlesr.har...@gmail.com snip That is a massive pile of affected projects :-(. My worry is that if all these projects we know about are broken, then how many other codebases that we aren't testing are also broken? Yeah, I would imagine quite a few might be. It isn't that I guess many used the feature deliberately, but it is easy to just code it and assume that the code is correct since it works. So I think I will just need to fix it. The pull request *should* already do this with a band aid-solution, by just falling back to the old funky stuff if there is a failure. If someone is good with python exception handling and string formatting in C, please feel free to have a look ;). - Sebastian If the issues are fixed in matplotlib and pandas I'd be inclined to release as is with a mention of versions in the release notes. Even if it's fixed in pandas master, how long until it's in user's hands? -n Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Remove bento from numpy
On Sat, Jul 5, 2014 at 3:21 PM, David Cournapeau courn...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith n...@pobox.com wrote: Maybe bento will revive and take over the new python packaging world! Maybe not. Maybe something else will. I don't see how our support for it will really affect these outcomes in any way. And I especially don't see why it's important to spend time *now* on keeping bento working, just in case it becomes useful *later*. But it is working right now, so that argument is moot. My suggestion was that we should drop the rule that a patch has to keep bento working to be merged. We're talking about future breakages and future effort. The fact that it's working now doesn't say anything about whether it's worth continuing to invest time in it. -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Remove bento from numpy
The efforts are on average less demanding than this discussion. We are talking about adding entries to a list in most cases... Also, while adding the optimization support for bento, I've noticed that a lot of the related distutils code is broken, and does not work as expected on at least OS X + clang. David On Sun, Jul 6, 2014 at 1:38 AM, Nathaniel Smith n...@pobox.com wrote: On Sat, Jul 5, 2014 at 3:21 PM, David Cournapeau courn...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith n...@pobox.com wrote: Maybe bento will revive and take over the new python packaging world! Maybe not. Maybe something else will. I don't see how our support for it will really affect these outcomes in any way. And I especially don't see why it's important to spend time *now* on keeping bento working, just in case it becomes useful *later*. But it is working right now, so that argument is moot. My suggestion was that we should drop the rule that a patch has to keep bento working to be merged. We're talking about future breakages and future effort. The fact that it's working now doesn't say anything about whether it's worth continuing to invest time in it. -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Remove bento from numpy
On 05.07.2014 18:40, David Cournapeau wrote: The efforts are on average less demanding than this discussion. We are talking about adding entries to a list in most cases... Also, while adding the optimization support for bento, I've noticed that a lot of the related distutils code is broken, and does not work as expected on at least OS X + clang. It just spits out a lot of warnings but they are harmless. We could remove them by using with -Werror=attribute for the conftests if it really bothers someone. Or do you mean something else? David On Sun, Jul 6, 2014 at 1:38 AM, Nathaniel Smith n...@pobox.com mailto:n...@pobox.com wrote: On Sat, Jul 5, 2014 at 3:21 PM, David Cournapeau courn...@gmail.com mailto:courn...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith n...@pobox.com mailto:n...@pobox.com wrote: Maybe bento will revive and take over the new python packaging world! Maybe not. Maybe something else will. I don't see how our support for it will really affect these outcomes in any way. And I especially don't see why it's important to spend time *now* on keeping bento working, just in case it becomes useful *later*. But it is working right now, so that argument is moot. My suggestion was that we should drop the rule that a patch has to keep bento working to be merged. We're talking about future breakages and future effort. The fact that it's working now doesn't say anything about whether it's worth continuing to invest time in it. -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org mailto:NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Remove bento from numpy
On Sun, Jul 6, 2014 at 1:55 AM, Julian Taylor jtaylor.deb...@googlemail.com wrote: On 05.07.2014 18:40, David Cournapeau wrote: The efforts are on average less demanding than this discussion. We are talking about adding entries to a list in most cases... Also, while adding the optimization support for bento, I've noticed that a lot of the related distutils code is broken, and does not work as expected on at least OS X + clang. It just spits out a lot of warnings but they are harmless. Adding lots of warnings are not harmless as they render the compiler warning system near useless (too many false alarms). I will fix the checks for both distutils and bento (using the autoconf macros setup, which should be more reliable than what we use for builtin and __attribute__-related checks) David We could remove them by using with -Werror=attribute for the conftests if it really bothers someone. Or do you mean something else? David On Sun, Jul 6, 2014 at 1:38 AM, Nathaniel Smith n...@pobox.com mailto:n...@pobox.com wrote: On Sat, Jul 5, 2014 at 3:21 PM, David Cournapeau courn...@gmail.com mailto:courn...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith n...@pobox.com mailto:n...@pobox.com wrote: Maybe bento will revive and take over the new python packaging world! Maybe not. Maybe something else will. I don't see how our support for it will really affect these outcomes in any way. And I especially don't see why it's important to spend time *now* on keeping bento working, just in case it becomes useful *later*. But it is working right now, so that argument is moot. My suggestion was that we should drop the rule that a patch has to keep bento working to be merged. We're talking about future breakages and future effort. The fact that it's working now doesn't say anything about whether it's worth continuing to invest time in it. -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org mailto:NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Remove bento from numpy
On Sun, Jul 6, 2014 at 2:24 AM, Julian Taylor jtaylor.deb...@googlemail.com wrote: On 05.07.2014 19:11, David Cournapeau wrote: On Sun, Jul 6, 2014 at 1:55 AM, Julian Taylor jtaylor.deb...@googlemail.com mailto:jtaylor.deb...@googlemail.com wrote: On 05.07.2014 18:40, David Cournapeau wrote: The efforts are on average less demanding than this discussion. We are talking about adding entries to a list in most cases... Also, while adding the optimization support for bento, I've noticed that a lot of the related distutils code is broken, and does not work as expected on at least OS X + clang. It just spits out a lot of warnings but they are harmless. Adding lots of warnings are not harmless as they render the compiler warning system near useless (too many false alarms). true but until now we haven't received a single complaint nor fixes so probably not many developers are actually using macs/clang to work on numpy C code. Not many people are working on numpy C code period :) FWIW, clang is now the standard OS X compiler since Maverick (Apple in all its wisdom made gcc an alias to clang...). David But I do agree its bad and I have fixing that on my todo list, I didn't get around to it yet. I will fix the checks for both distutils and bento (using the autoconf macros setup, which should be more reliable than what we use for builtin and __attribute__-related checks) David We could remove them by using with -Werror=attribute for the conftests if it really bothers someone. Or do you mean something else? David On Sun, Jul 6, 2014 at 1:38 AM, Nathaniel Smith n...@pobox.com mailto:n...@pobox.com mailto:n...@pobox.com mailto:n...@pobox.com wrote: On Sat, Jul 5, 2014 at 3:21 PM, David Cournapeau courn...@gmail.com mailto:courn...@gmail.com mailto:courn...@gmail.com mailto:courn...@gmail.com wrote: On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith n...@pobox.com mailto:n...@pobox.com mailto:n...@pobox.com mailto:n...@pobox.com wrote: Maybe bento will revive and take over the new python packaging world! Maybe not. Maybe something else will. I don't see how our support for it will really affect these outcomes in any way. And I especially don't see why it's important to spend time *now* on keeping bento working, just in case it becomes useful *later*. But it is working right now, so that argument is moot. My suggestion was that we should drop the rule that a patch has to keep bento working to be merged. We're talking about future breakages and future effort. The fact that it's working now doesn't say anything about whether it's worth continuing to invest time in it. -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org mailto:NumPy-Discussion@scipy.org mailto:NumPy-Discussion@scipy.org mailto: NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org mailto:NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org mailto:NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Teaching Scipy BoF at SciPy
On Jul 4, 2014, at 7:02 AM, Phil Elson pelson@gmail.com wrote: Nice idea. Just a repository of courses would be a great first step. Yup -- or really even a curated page of links and refrrences. Maybe we can get first draft of such a thing put together during the BoF. Feel free to add this idea to the Wiki :-) I hope you can come to the BoF, I know there are a number of others at the same time. -CHB For example, I know Jake Vanderplas's course at https://github.com/jakevdp/2013_fall_ASTR599 is useful, and I have a few introduction (3hr) courses at https://github.com/SciTools/courses. On 3 July 2014 16:59, Chris Barker chris.bar...@noaa.gov wrote: HI Folks, I will be hosting a Teaching the SciPy Stack BoF at SciPy this year: https://conference.scipy.org/scipy2014/schedule/presentation/1762/ (Actually, I proposed it for the conference, but would be more than happy to have other folks join me in facilitating, hosting, etc.) I've put up a Wiki page to collect ideas for topics. Please take a look and add your $0.02: https://github.com/numpy/numpy/wiki/TeachingSciPy-BoF-at-Scipy-2014 See you there, -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Remove bento from numpy
On Sat, Jul 5, 2014 at 4:17 PM, Nathaniel Smith n...@pobox.com wrote: On Sat, Jul 5, 2014 at 2:32 PM, Ralf Gommers ralf.gomm...@gmail.com wrote: On Sat, Jul 5, 2014 at 1:54 PM, Nathaniel Smith n...@pobox.com wrote: On 5 Jul 2014 09:23, Ralf Gommers ralf.gomm...@gmail.com wrote: Perhaps a compromise would be to declare it officially unsupported and remove it from Travis CI, while leaving the files in place to be used on an at-your-own-risk basis? As long as it's in Travis, the default is that anyone who breaks it has to fix it. If it's not in Travis, then the default is that the people (person?) who use bento are responsible for keeping it working for their needs. -1 that just means that simple changes like adding a new extension will not get made before PRs get merged, and bento support will be in a broken state much more often. Yes, and then the handful of people who care about this would fix it or not. What next, we give Alan Isaac commit rights and then it's OK to break numpy.matrix when that's convenient? Your -1 is attempting to veto other people's *not* paying attention to this build system. I... don't think -1's work that way :-( You're proposing it'll be OK for others to break stuff that the people before them put quite some effort into implementing. I damn well have the right to give that a -1. David is fixing the few existing problems now, so there should be zero issues here. You're deliberately mischaracterizing the situation (pre-alpha, lot of effort, etc.), so I'm not going to bother responding to the rest, I'm annoyed enough as is. Ralf P.S. if anyone wants to spend some productive energy on the build situation, MSVC 2010 support for Python 3.x would be nice: https://github.com/numpy/numpy/issues/4245 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Remove bento from numpy
On 7/5/2014 6:42 PM, Ralf Gommers wrote: What next, we give Alan Isaac commit rights and then it's OK to break numpy.matrix when that's convenient? I always wondered what I would do with commit rights ... Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Questions about fixes for 1.9.0rc2
Drats... I actually know those two topics... and I might have free time tomorrow afternoon at SciPy. Maybe I could take a peek at it? Ben On Sat, Jul 5, 2014 at 11:24 AM, Sebastian Berg sebast...@sipsolutions.net wrote: On Sa, 2014-07-05 at 00:41 +0100, Nathaniel Smith wrote: On 5 Jul 2014 00:07, Charles R Harris charlesr.har...@gmail.com snip That is a massive pile of affected projects :-(. My worry is that if all these projects we know about are broken, then how many other codebases that we aren't testing are also broken? Yeah, I would imagine quite a few might be. It isn't that I guess many used the feature deliberately, but it is easy to just code it and assume that the code is correct since it works. So I think I will just need to fix it. The pull request *should* already do this with a band aid-solution, by just falling back to the old funky stuff if there is a failure. If someone is good with python exception handling and string formatting in C, please feel free to have a look ;). - Sebastian If the issues are fixed in matplotlib and pandas I'd be inclined to release as is with a mention of versions in the release notes. Even if it's fixed in pandas master, how long until it's in user's hands? -n Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Remove bento from numpy
Speaking as someone who started but then stopped dabbling in the NumPy C core, having to think about two build system is a huge turn-off. Getting into the NumPy C code is hard enough without having to worry about multiple build systems. Bryan On Jul 5, 2014, at 6:42 PM, Ralf Gommers ralf.gomm...@gmail.com wrote: On Sat, Jul 5, 2014 at 4:17 PM, Nathaniel Smith n...@pobox.com wrote: On Sat, Jul 5, 2014 at 2:32 PM, Ralf Gommers ralf.gomm...@gmail.com wrote: On Sat, Jul 5, 2014 at 1:54 PM, Nathaniel Smith n...@pobox.com wrote: On 5 Jul 2014 09:23, Ralf Gommers ralf.gomm...@gmail.com wrote: Perhaps a compromise would be to declare it officially unsupported and remove it from Travis CI, while leaving the files in place to be used on an at-your-own-risk basis? As long as it's in Travis, the default is that anyone who breaks it has to fix it. If it's not in Travis, then the default is that the people (person?) who use bento are responsible for keeping it working for their needs. -1 that just means that simple changes like adding a new extension will not get made before PRs get merged, and bento support will be in a broken state much more often. Yes, and then the handful of people who care about this would fix it or not. What next, we give Alan Isaac commit rights and then it's OK to break numpy.matrix when that's convenient? Your -1 is attempting to veto other people's *not* paying attention to this build system. I... don't think -1's work that way :-( You're proposing it'll be OK for others to break stuff that the people before them put quite some effort into implementing. I damn well have the right to give that a -1. David is fixing the few existing problems now, so there should be zero issues here. You're deliberately mischaracterizing the situation (pre-alpha, lot of effort, etc.), so I'm not going to bother responding to the rest, I'm annoyed enough as is. Ralf P.S. if anyone wants to spend some productive energy on the build situation, MSVC 2010 support for Python 3.x would be nice: https://github.com/numpy/numpy/issues/4245 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
