[Numpy-discussion] Re: Automatic formatters for only changed lines

2022-05-08 Thread Sebastian Berg
On Sat, 2022-05-07 at 22:37 -0700, Juan Nunez-Iglesias wrote:
> With the caveat that I am just an interested bystander, I would like
> to point back to yapf as an alternative. I agree with what has
> already been echoed by the majority of the community, that setting
> *some* auto-formatter is a huge benefit for both review and writing
> sanity. I very much disagree with some of the other choices that
> black makes, while in contrast I find that I can get yapf to write
> code that I find very close to what I would naturally write as an
> old-fashioned Python style pedant.
> 
> I might have already pointed to these lines of code < 
> https://github.com/napari/napari/blob/bcb6523c0dbbbf685c93873980cf04989839b050/napari/layers/labels/labels.py#L646-L652
> > that black produced for napari that I find abhorrent:
> 
>     (
>     custom_colormap,
>     label_color_index,
>     ) = color_dict_to_colormap(self.color)
> 


To be fair to black, the main issue there is the trailing `,` which
forces items to be formatted on a line each (yapf does the same).
If you remove the trailing comma, you will get close to what you want
also in black:

custom_colormap, label_color_index = color_dict_to_colormap(
self.color, even, more, options
)


> I can confirm that this hurts readability because recently I and
> another experienced developer stared just a couple of lines
> downstream for a hot minute wondering where the hell
> "label_color_index" was defined. It is also more lines of code than
> 
>     custom_colormap, label_color_index = (
>     color_dict_to_colormap(self.color)
>     )
> 
> (Personally I really like the pep8 recommendation on hanging indents,
> "further indentation should be used to clearly distinguish itself as
> a continuation line," which black ignores.)


Trying around with yapf, I cannot see how you can get such "hanging
indent" without using it also for e.g. lists definitions.
There is the "continuation indent" option to get the extra indent.  But
it is applies to those literals giving you:

my_list = [
(
"first thing",
"second",
),
]

(Of course you can tweak a few things there)

Yapf is not capable of adding/removing parentheses around expressions.
So you have to do that manually on otherwise long lines.
(Not sure this is a limit that matters in practice.  It is similar to
that trailing comma magic that also requires some manual care.)

- Sebastian


> 
> Anyway, didn't mean to start a flame war, just to express my
> preference for yapf and that it would therefore make me very happy to
> see NumPy adopt it as a counteracting force to the monopoly that
> black is developing. I do strongly agree that black is preferable to
> no formatter. In short my recommendation order would be:
> 
> 1. Use yapf;
> 2. Use black;
> 3. Don't use a formatter.
> 
> Juan.
> 
> On Sat, 7 May 2022, at 3:20 PM, Peter Cock wrote:
> > On Fri, May 6, 2022 at 4:59 PM Charles R Harris <
> > charlesr.har...@gmail.com> wrote:
> > > 
> > > Heh. I think automatic formatting is the future and was happy to
> > > see the PR. The only question is if black is the way we want to
> > > go. IIRC, the main sticking points were
> > >  * Line length (<= 79).
> > >  * Quotation mark changes (noisy).
> > >  * Formatting of  '*', '**', and '/'
> > > Even if the result isn't perfect by our current standards, I
> > > suspect we will get used to it and just not worry anymore.
> > 
> > On that note, in black v22.1.0 (the first non-beta release), one of
> > the changes was to the ** operator to better suit mathematical
> > conventions:
> > 
> >  "Remove spaces around power operators if both operands are simple"
> > https://github.com/psf/black/pull/2726
> > 
> > Either way I agree with you, most people seem to get used to black
> > and stop worrying about it.
> > 
> > Peter
> > 
> > ___
> > NumPy-Discussion mailing list -- numpy-discussion@python.org
> > To unsubscribe send an email to numpy-discussion-le...@python.org
> > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> > Member address: j...@fastmail.com
> > 
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: sebast...@sipsolutions.net


___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com


[Numpy-discussion] Re: Automatic formatters for only changed lines

2022-05-08 Thread Evgeni Burovski
Mind sharing your yapf config Juan?


вс, 8 мая 2022 г., 08:40 Juan Nunez-Iglesias :

> With the caveat that I am just an interested bystander, I would like to
> point back to yapf as an alternative. I agree with what has already been
> echoed by the majority of the community, that setting *some* auto-formatter
> is a huge benefit for both review and writing sanity. I very much disagree
> with some of the other choices that black makes, while in contrast I find
> that I can get yapf to write code that I find very close to what I would
> naturally write as an old-fashioned Python style pedant.
>
> I might have already pointed to these lines of code
> 
> that black produced for napari that I find abhorrent:
>
> (
> custom_colormap,
> label_color_index,
> ) = color_dict_to_colormap(self.color)
>
> I can confirm that this hurts readability because recently I and another
> experienced developer stared just a couple of lines downstream for a hot
> minute wondering where the hell "label_color_index" was defined. It is also
> more lines of code than
>
> custom_colormap, label_color_index = (
> color_dict_to_colormap(self.color)
> )
>
> (Personally I really like the pep8 recommendation on hanging indents,
> "further indentation should be used to clearly distinguish itself as a
> continuation line," which black ignores.)
>
> Anyway, didn't mean to start a flame war, just to express my preference
> for yapf and that it would therefore make me very happy to see NumPy adopt
> it as a counteracting force to the monopoly that black is developing. I do
> strongly agree that black is preferable to no formatter. In short my
> recommendation order would be:
>
> 1. Use yapf;
> 2. Use black;
> 3. Don't use a formatter.
>
> Juan.
>
> On Sat, 7 May 2022, at 3:20 PM, Peter Cock wrote:
>
> On Fri, May 6, 2022 at 4:59 PM Charles R Harris 
> wrote:
>
>
> Heh. I think automatic formatting is the future and was happy to see the
> PR. The only question is if black is the way we want to go. IIRC, the main
> sticking points were
>
>- Line length (<= 79).
>- Quotation mark changes (noisy).
>- Formatting of  '*', '**', and '/'
>
> Even if the result isn't perfect by our current standards, I suspect we
> will get used to it and just not worry anymore.
>
>
> On that note, in black v22.1.0 (the first non-beta release), one of the
> changes was to the ** operator to better suit mathematical conventions:
>
>  "Remove spaces around power operators if both operands are simple"
> https://github.com/psf/black/pull/2726
>
> Either way I agree with you, most people seem to get used to black and
> stop worrying about it.
>
> Peter
>
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: j...@fastmail.com
>
>
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: evgeny.burovs...@gmail.com
>
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com


[Numpy-discussion] Re: Automatic formatters for only changed lines

2022-05-08 Thread Joshua Wilson
As someone who worked on a project that used to use yapf, a word of caution
- regardless of quality of formatting versus black, it generally has not
had the resources to keep up with new releases of Python. See

https://github.com/google/yapf/issues/772
https://github.com/google/yapf/issues/993
https://github.com/google/yapf/issues/1001

for example. We eventually had to switch to black because of the lack of
3.8 support. (Though with 3.8 in particular you'd be fine if you banned
using the walrus operator.)

On Sun, May 8, 2022 at 5:59 AM Evgeni Burovski 
wrote:

> Mind sharing your yapf config Juan?
>
>
> вс, 8 мая 2022 г., 08:40 Juan Nunez-Iglesias :
>
>> With the caveat that I am just an interested bystander, I would like to
>> point back to yapf as an alternative. I agree with what has already been
>> echoed by the majority of the community, that setting *some* auto-formatter
>> is a huge benefit for both review and writing sanity. I very much disagree
>> with some of the other choices that black makes, while in contrast I find
>> that I can get yapf to write code that I find very close to what I would
>> naturally write as an old-fashioned Python style pedant.
>>
>> I might have already pointed to these lines of code
>> 
>> that black produced for napari that I find abhorrent:
>>
>> (
>> custom_colormap,
>> label_color_index,
>> ) = color_dict_to_colormap(self.color)
>>
>> I can confirm that this hurts readability because recently I and another
>> experienced developer stared just a couple of lines downstream for a hot
>> minute wondering where the hell "label_color_index" was defined. It is also
>> more lines of code than
>>
>> custom_colormap, label_color_index = (
>> color_dict_to_colormap(self.color)
>> )
>>
>> (Personally I really like the pep8 recommendation on hanging indents,
>> "further indentation should be used to clearly distinguish itself as a
>> continuation line," which black ignores.)
>>
>> Anyway, didn't mean to start a flame war, just to express my preference
>> for yapf and that it would therefore make me very happy to see NumPy adopt
>> it as a counteracting force to the monopoly that black is developing. I do
>> strongly agree that black is preferable to no formatter. In short my
>> recommendation order would be:
>>
>> 1. Use yapf;
>> 2. Use black;
>> 3. Don't use a formatter.
>>
>> Juan.
>>
>> On Sat, 7 May 2022, at 3:20 PM, Peter Cock wrote:
>>
>> On Fri, May 6, 2022 at 4:59 PM Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>
>> Heh. I think automatic formatting is the future and was happy to see the
>> PR. The only question is if black is the way we want to go. IIRC, the main
>> sticking points were
>>
>>- Line length (<= 79).
>>- Quotation mark changes (noisy).
>>- Formatting of  '*', '**', and '/'
>>
>> Even if the result isn't perfect by our current standards, I suspect we
>> will get used to it and just not worry anymore.
>>
>>
>> On that note, in black v22.1.0 (the first non-beta release), one of the
>> changes was to the ** operator to better suit mathematical conventions:
>>
>>  "Remove spaces around power operators if both operands are simple"
>> https://github.com/psf/black/pull/2726
>>
>> Either way I agree with you, most people seem to get used to black and
>> stop worrying about it.
>>
>> Peter
>>
>> ___
>> NumPy-Discussion mailing list -- numpy-discussion@python.org
>> To unsubscribe send an email to numpy-discussion-le...@python.org
>> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
>> Member address: j...@fastmail.com
>>
>>
>> ___
>> NumPy-Discussion mailing list -- numpy-discussion@python.org
>> To unsubscribe send an email to numpy-discussion-le...@python.org
>> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
>> Member address: evgeny.burovs...@gmail.com
>>
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: josh.craig.wil...@gmail.com
>
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com


[Numpy-discussion] Re: Automatic formatters for only changed lines

2022-05-08 Thread Juan Nunez-Iglesias
On Sun, 8 May 2022, at 7:11 AM, Sebastian Berg wrote:
> To be fair to black, the main issue there is the trailing `,` which
> forces items to be formatted on a line each (yapf does the same).
> If you remove the trailing comma, you will get close to what you want
> also in black:
>
> custom_colormap, label_color_index = color_dict_to_colormap(
> self.color, even, more, options
> )

No, black added those parentheses and the trailing comma all by itself, and 
cannot be persuaded otherwise (believe me, I've tried). Perhaps your test 
didn't show it because you were missing that our line length is configured to 
79c.

**Update** Whoa, this is actually a black version update, removing the comma 
fixes the formatting! :tada: This makes me very happy. :joy:

> Trying around with yapf, I cannot see how you can get such "hanging
> indent" without using it also for e.g. lists definitions.
> There is the "continuation indent" option to get the extra indent.  But
> it is applies to those literals giving you:
>
> my_list = [
> (
> "first thing",
> "second",
> ),
> ]
>
> (Of course you can tweak a few things there)

Yes, what I tweak is consolidating of parentheses, so this is what I get with 
that construct:

my_list = [(
"first thing", "second"
)]

> Yapf is not capable of adding/removing parentheses around expressions.
> So you have to do that manually on otherwise long lines.
> (Not sure this is a limit that matters in practice.  It is similar to
> that trailing comma magic that also requires some manual care.)

Yeah in my experience it's been fine.

> Mind sharing your yapf config Juan?

Here it is:

https://github.com/jni/skan/blob/0ff5677461068e036ab6641729635cd651aaa87c/.style.yapf

> regardless of quality of formatting versus black, [yapf] generally has not 
> had the resources to keep up with new releases of Python.

That's sad to hear, and I'll happily acknowledge, a major drawback.

Juan.
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com


[Numpy-discussion] Re: Automatic formatters for only changed lines

2022-05-08 Thread Charles R Harris
On Sun, May 8, 2022 at 10:30 AM Joshua Wilson 
wrote:

> As someone who worked on a project that used to use yapf, a word of
> caution - regardless of quality of formatting versus black, it generally
> has not had the resources to keep up with new releases of Python. See
>
> https://github.com/google/yapf/issues/772
> https://github.com/google/yapf/issues/993
> https://github.com/google/yapf/issues/1001
>
> for example. We eventually had to switch to black because of the lack of
> 3.8 support. (Though with 3.8 in particular you'd be fine if you banned
> using the walrus operator.)
>

That was my main concern, one of the advantages of using a widely used
package like black (or clang-format) is that it is more likely to be
maintained going forward. It is also easier to find help if needed.



Chuck
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com


[Numpy-discussion] Documentation Team meeting - Monday May 9

2022-05-08 Thread Melissa Mendonça
Hi all!

Our next Documentation Team meeting will happen on *Monday, May 9* at ***4PM
UTC***.

All are welcome - you don't need to already be a contributor to join. If
you have questions or are curious about what we're doing, we'll be happy to
meet you!

If you wish to join on Zoom, use this link:

https://zoom.us/j/96219574921?pwd=VTRNeGwwOUlrYVNYSENpVVBRRjlkZz09

Here's the permanent hackmd document with the meeting notes (still being
updated):

https://hackmd.io/oB_boakvRqKR-_2jRV-Qjg


Hope to see you around!

** You can click this link to get the correct time at your timezone:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=NumPy+Documentation+Team+Meeting&iso=20220509T16&p1=1440&ah=1

*** You can also visit https://scientific-python.org/calendars to add the
NumPy community calendar as an .ics file to your preferred calendar manager

- Melissa
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com