Mailman 3 April 2017 - scikit-image

Absolute difference of images: OpenCV vs Numpy
by Surya Kasturi 21 Apr '17

21 Apr '17

Hey, I’m doing absolute difference between two images and found that the results from opencv and scikit-image are different >> im1 = imread(“file1.jpg”) >> im2 = imread(“file2.jpg”) >> >> cv2.absdiff(im1, im2) >> np.abs(im1, im2) I was expecting exactly same result.. could anyone please let me know why I’m observing slightly different results. (I could post images if you’d like) Thanks Surya

2 2

Re: [scikit-image] How to move pull requests forward (devs, please read)
by Juan Nunez-Iglesias 14 Apr '17

14 Apr '17

My concern with fully automated tools is that they tend to be overly stringent. There's many places where we violate PEP8 for valid stylistic reasons, e.g. to align the values of an array literal. btw Stéfan, how's the PR for using PEP8speaks only for the diff? On 15 Apr 2017, 9:40 AM +1000, Stefan van der Walt <stefanv(a)berkeley.edu>, wrote: > On Fri, Apr 14, 2017, at 15:23, Nathaniel Smith wrote: > > On Apr 14, 2017 9:12 AM, "Stefan van der Walt" <stefanv(a)berkeley.edu> wrote: > > > On Fri, Apr 14, 2017, at 00:14, Nathaniel Smith wrote: > > > > I wonder if it would be worthwhile to have a bot that automatically > > > > pushes formatting fixes to submitted PRs (using autopep8 or yapf). > > > > > > That'd be great; do you know if such a thing exists? > > > > I don't know of any off the shelf implementation of this, no. > > Oh, we already have it! > > https://github.com/OrkoHunter/pep8speaks > > Just type > > @pep8speaks pep8ify > > as a comment, and you get a PR back. > > Stéfan > > _______________________________________________ > scikit-image mailing list > scikit-image(a)python.org > https://mail.python.org/mailman/listinfo/scikit-image

1 0

Re: [scikit-image] How to move pull requests forward (devs, please read)
by Stefan van der Walt 14 Apr '17

14 Apr '17

On Fri, Apr 14, 2017, at 15:23, Nathaniel Smith wrote: > On Apr 14, 2017 9:12 AM, "Stefan van der Walt" > <stefanv(a)berkeley.edu> wrote: >> On Fri, Apr 14, 2017, at 00:14, Nathaniel Smith wrote: >> > I wonder if it would be worthwhile to have a bot that >> > automatically >> > pushes formatting fixes to submitted PRs (using autopep8 or yapf). >> >> That'd be great; do you know if such a thing exists? > > I don't know of any off the shelf implementation of this, no. Oh, we already have it! https://github.com/OrkoHunter/pep8speaks Just type @pep8speaks pep8ify as a comment, and you get a PR back. Stéfan

1 0

Re: [scikit-image] How to move pull requests forward (devs, please read)
by Nathaniel Smith 14 Apr '17

14 Apr '17

On Apr 14, 2017 9:12 AM, "Stefan van der Walt" <stefanv(a)berkeley.edu> wrote: On Fri, Apr 14, 2017, at 00:14, Nathaniel Smith wrote: > On Thu, Apr 13, 2017 at 3:28 PM, Nelle Varoquaux > <nelle.varoquaux(a)gmail.com> wrote: > > Hello, > > > > For style-changes (such as pep8/flake8) elements, I find that very often new > > contributors don't know they can configure their text editors to display the > > pep8/pyflakes violations. Very often, it is a question of mentoring them > > through the process of configuring their text editors. > > Recently, I've been either creating pull requests on people's branch or > > pushing to the contributor's branch just before merging. > > I wonder if it would be worthwhile to have a bot that automatically > pushes formatting fixes to submitted PRs (using autopep8 or yapf). That'd be great; do you know if such a thing exists? I don't know of any off the shelf implementation of this, no. -n

1 0

Re: [scikit-image] How to move pull requests forward (devs, please read)
by François Boulogne 14 Apr '17

14 Apr '17

> This should be added to the contributor guidelines, potentially as a > separate doc linked in. Would you mind taking lead on that? > I started a PR with a blank file to get a place for comments. I'll start to throw few ideas in it soon. https://github.com/scikit-image/scikit-image/pull/2616 -- François Boulogne. http://www.sciunto.org GPG: 32D5F22F

1 0

Re: [scikit-image] How to move pull requests forward (devs, please read)
by Stefan van der Walt 14 Apr '17

14 Apr '17

On Thu, Apr 13, 2017, at 21:30, Vighnesh Birodkar wrote: > But apart from this the PR does what the algorithm it implements > correctly. Can we merge such a PR in master and keep it as a private > unexposed function while raising an issue to address it's shortcomings > ? The function can de decorated to exclude it from the main docs and > maybe raise a warning when invoked. I believe the flaws I mentioned > can be taken up by someone else in the community. Like a user might > contribute documentation or a newcomer might do the refactoring. Then > later down the line core Devs can agree and make the function public. What you're describing above sounds a lot like skimage.future. Experimental, but with the intent to mature for full inclusion. Stéfan

1 0

Re: [scikit-image] How to move pull requests forward (devs, please read)
by François Boulogne 14 Apr '17

14 Apr '17

Dear all, As Juan, I believe that merging unpolished features is just displacing the problem. Like a messy desk tidy up by dumping everything in the drawers. Side remarks, It seems to me that the magic box is not ticked for our oldest PR. So we need to ask the contributor sometimes to do it. I tried to submit PR to contributors branches a couple of time and I always failed with a awkward diff. I probably miss something stupid in the procedure. Any guidance would be appreciated. It sounds quite difficult to me to define rigid rules. Most of the things I learned is with you guys because you pushed me beyond my borders. Education is also a benefit. Whatever the final decision, it's urgent to care about all the PRs we have so far. We have few years old PRs, that we must either decide to close or move forward by ourself. our objective must be to keep the number of open PRs at a low level. In addition, standard rules for our API would help (standard names of variables, standard checks, typical default values etc), even just for the reviewers. It will shortcut debates. Perhaps we can multiply these discussions: https://github.com/scikit-image/scikit-image/issues?q=is%3Aissue+is%3Aopen+… and agree that it should end up with a note in the documentation. All the best, -- François Boulogne. http://www.sciunto.org GPG: 32D5F22F

2 1

Re: [scikit-image] How to move pull requests forward (devs, please read)
by Stefan van der Walt 14 Apr '17

14 Apr '17

Hi Vighnesh On Thu, Apr 13, 2017, at 23:34, Vighnesh Birodkar wrote: > I understand where you are coming from. But don't you think there are > instances when a contributor , after working on a new feature or > function, does not have the time or energy to drive their work towards > completion. The pending work might be too much for a single developer > but it may be something that multiple developers working together > might be able to complete. > > These features need not have to be part of the next release. But my > assumption is that if one these features is useful, it will quickly > get polished and be good enough to be exposable. If a feature works > and is kept isolated from the public API, its tests/docs/optimizations > can come from different other developers at different points of time. Importantly, each piece of contributed code needs to be maintained. I am not encouraged, when a contributer is unwilling to go through the necessary care to figure out API etc., that they will stick around to fix bugs and update documentation later. In fact, that increases my hesitance to merge, because now not only will they be gone, but we'll be stuck having to fix up their code later. So, while I am all in favor of lowering barriers to entry—mostly arround annoying grunt work—certain other barriers remain useful. My preference is for a smaller but higher quality library, with a lower maintenance burden (especially since we rely on volunteer effort for now). Stéfan

1 0

Re: [scikit-image] How to move pull requests forward (devs, please read)
by Stefan van der Walt 14 Apr '17

14 Apr '17

On Fri, Apr 14, 2017, at 00:14, Nathaniel Smith wrote: > On Thu, Apr 13, 2017 at 3:28 PM, Nelle Varoquaux > <nelle.varoquaux(a)gmail.com> wrote: > > Hello, > > > > For style-changes (such as pep8/flake8) elements, I find that very often new > > contributors don't know they can configure their text editors to display the > > pep8/pyflakes violations. Very often, it is a question of mentoring them > > through the process of configuring their text editors. > > Recently, I've been either creating pull requests on people's branch or > > pushing to the contributor's branch just before merging. > > I wonder if it would be worthwhile to have a bot that automatically > pushes formatting fixes to submitted PRs (using autopep8 or yapf). That'd be great; do you know if such a thing exists? Stéfan

1 0

Re: [scikit-image] Turning mailing list reply-to-list on by default
by Stefan van der Walt 14 Apr '17

14 Apr '17

On Fri, Apr 14, 2017, at 02:27, Matthew Brett wrote: > For what it's worth, I completely agree. I believe the > counter-argument is here: > > http://www.unicom.com/pw/reply-to-harmful > > but the argument seems pretty weak to me, it's main strength being the > use of the famous phrase 'considered harmful' [1] It's funny how often we see the argument: "put power in the hands of the user/coder"; but the counter-argument of "do the right thing most of the time" is more compelling. This is also driving the discussion behind making the contribution process easier; having each contributor rebase and polish perfect patches is great in theory, but 98% of the time you just want things to work and be easy. Stéfan

1 0