k0kubun/pp

Option to print byte as decimal

taynguyen opened this issue · 10 comments

When print the byte slice, pp print as hex, quite hard to see.

E.g:

pp.Println("65:", []byte{65})

will print:

print:
"65:" []uint8{
  0x41,
}

Expected something like:

"65:" []uint8{
  65,
}

Is this possible and useful?

FYI:

$ cat a.go
package main
import "fmt"

func main() {
        fmt.Printf("%#v\n", []byte{65})
        fmt.Printf("%#v\n", []int{65})
}

$ go run a.go
[]byte{0x41}
[]int{65}

The general philosophy here is to be compatible with %#v to avoid surprise for new users. If you store integers, I think you should use []int. []byte is usually used for binaries and you don't store numbers there.

Yeah, that quite make sense if we use the Printf with %#v. The default should be a bit more friendly?

package main

import (
	"fmt"

	"github.com/k0kubun/pp"
)

func main() {
	pp.Println("65:", []byte{65})
	fmt.Println("65:", []byte{65})
}

Would print:

go run cmd/debug/main.go
"65:" []uint8{
  0x41,
}
65: [65]

fmt.Println shows not []int{65} but [65]. That's just another example where pp is closer to %#v than Println.

The default should be a bit more friendly?

Could you explain why making 65 default is more friendly than 0x41 in your usage? If your use case sounds common, I think it should be the default, but otherwise, it should be an option. What do you use []byte{65} for? Given that you could use []int to solve your problem, why do you need to use []byte instead of []int?

Yeah. I working with lots of []byte and calculation on them.
When debugging, I would need to fast compare them on some different way, the hex format would hard to see, remember, or compare with your eyes.

In example:
The array: blob := []byte("5Q75aX^")
We would have this in console when print:

 []uint8{
  0x35, 0x51, 0x37, 0x35, 0x61, 0x58, 0x5e,
}

That seem not really friendly with my brain, hard to work with them. When that happen, I have to use fmt to print it.

Something like

[]uint8{ 53 81 55 53 97 88 94 }

could give me some love.

Hmm, I guess seeing 0x in every element is sort of disturbing your mind? In general, I prefer seeing binary in hex because each byte can be always represented by 2 characters (0x00~0xff) whereas the decimal could go 0~255.

If your usage is to compare two binaries, I'd say hex is rather useful to have a larger chance of alignment, while not guaranteed:

[]byte{ 35 71 37 35 71 58 6e }
[]byte{ 35 51 37 35 21 58 6e }

rather than

[]byte{ 53 113 55 53 113 88 110 }
[]byte{ 53 81 55 53 33 88 110 }

Either way, both of these are too deviated from the standard library's behaviors (either %#v or fmt.Println), so I don't think it's friendly to make the behavior default. You might feel it's friendly, but others may not.

If pp had an option to switch hex to decimal (like your original proposal), would you use it?

Sure. Why not. We could also take a look what other lib or other language print (node, js, ...) blob if necessary. I happy to use if have that feature.
Or I think event I could fork and create a custom version if pp don't have that.

Could you try #55?

By the way, if you still prefer making it default, please discuss it with the author of #16. If he's happy about it, I'm okay with making it default (or even supporting only decimal).

@sdidyk Are you there? What do you think about this idea?

It's been open for so long time. I'll just merge the option so that you could use it. For now, I'd like to keep the compatibility with %#v.

Using pp today, I rethought that using decimal representations by default is more useful since you often want to use unsigned integer types for just non-negative integers. Hex representations are useful for constant-width binary buffers, but I feel like it's rather rare. So I'm going to make SetDecimalUnit(true) the default.