[Numpy-discussion] ndarray repr - put shape & type first

[Ilya Kamenshchikov]

Hello,

I wanted to discuss a pain point I've experienced while debugging numpy
code. When dealing with e.g. transformed image arrays or other non-trivial
ndarrays in debugger, I'm swamped by a bunch of numbers in their repr that
don't help me at all. What I really care about is *shape and dtype*, as
they are essentially what distinguishes complete type of numpy arrays.

Example of not helpful output:
```
array([[[0.49113064, 0.42102904, 0.62108876],
[0.25435884, 0.18665439, 0.53790145],
```

By counting the [ brackets, I can at least get the number of dimensions,
but usefulness stops here.

Could repr of an array start with something like:
`array(*shape=[32,32,3], dtype=float, data=*([[[0.49113064, ...)`

I know one invariant that repr likes to keep is that you can post repr and
it should be the initialisation of the represented object, but given that
we replace long number sequence with ..., this is already not the case.

Short term: Perhaps a plugin / change to IDE could do what I ask, please
let me know if something like this already exists :)

Long term: I think that behavior will be more useful than what is currently
there. It could also be conditionally there once we anyhow need to use ...
for too long arrays.

Best Regards,
--
Ilya Kamen
___
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: ndarray repr - put shape & type first

[Andras Deak]

On Sat, May 7, 2022, at 11:36, Ilya Kamenshchikov wrote:
> Hello,
>
> I wanted to discuss a pain point I've experienced while debugging numpy 
> code. When dealing with e.g. transformed image arrays or other 
> non-trivial ndarrays in debugger, I'm swamped by a bunch of numbers in 
> their repr that don't help me at all. What I really care about is 
> *shape and dtype*, as they are essentially what distinguishes complete 
> type of numpy arrays.

Hi Ilya,

It sounds like you're not actually looking for the repr when you are debugging. 
If you just need the shape and dtype, why not just print those?

Even "mere" debuggers like pdb support command aliases, see e.g. 
https://docs.python.org/3/library/pdb.html#pdbcommand-alias . I'm sure any 
debugger or IDE worth its salt will let you define a helper function in some 
configuration file which you can use during debugging to print what you need.

András

>
> Example of not helpful output:
> ```
> array([[[0.49113064, 0.42102904, 0.62108876],
> [0.25435884, 0.18665439, 0.53790145],
> ```
>
> By counting the [ brackets, I can at least get the number of 
> dimensions, but usefulness stops here.
>
> Could repr of an array start with something like:
> `array(*shape=[32,32,3], dtype=float, data=*([[[0.49113064, ...)`
>
> I know one invariant that repr likes to keep is that you can post repr 
> and it should be the initialisation of the represented object, but 
> given that we replace long number sequence with ..., this is already 
> not the case.
>
> Short term: Perhaps a plugin / change to IDE could do what I ask, 
> please let me know if something like this already exists :)
>
> Long term: I think that behavior will be more useful than what is 
> currently there. It could also be conditionally there once we anyhow 
> need to use ... for too long arrays.
>
> Best Regards,
> --
> Ilya Kamen
> ___
> 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: deak.and...@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

[Peter Cock]

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: arch...@mail-archive.com

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

[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: arch...@mail-archive.com