Proposal: Pretty print integers with underscore digit separator

[Wojtek Mach]

Hello everyone,

It's very convenient to write down integer literals as e.g. 10_000_000 - much easier for humans to read.

I was recently debugging some performance issues and I was working with this data in iex:

[memory: 173978912, message_queue_len: 0, heap_size: 12834421,
  total_heap_size: 21747214,
  garbage_collection: [min_bin_vheap_size: 46422, min_heap_size: 233,
   fullsweep_after: 65535, minor_gcs: 2]]

This data would be *much* more readable to me with digit separators:

[memory: 173_978_912, message_queue_len: 0, heap_size: 12_834_421,
  total_heap_size: 21_747_214,
  garbage_collection: [min_bin_vheap_size: 46_422, min_heap_size: 233,
   fullsweep_after: 65_535, minor_gcs: 2]]

It probably shouldn't be the default behavior for inspect/2, so I think this could only happen with one of: [pretty: true] , [pretty: :decimal]or perhaps something like [pretty_decimal: true].

Regards,

Wojtek

[José Valim]

I like this proposal. I would even pick it is a default with an option to turn it off. Does anyone else have feedback? :)

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Director of R&D

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/93f9f36d-f3f3-41f7-856b-c1422cd40026%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Schoenfelder]

I like it much better with underscores than without, much more readable. I would +1 making it the default behaviour with an option to turn it off.

Paul

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2Bd%2BsvetpUs_mC-VEnH3y9J6nFyXyuDQ1ixW6Wnu7zV%3DA%40mail.gmail.com.

[Peter Hamilton]

I'm nervous about existing inspect abuse as a hacky to_string. I could see someone using it and feeding the result into a hashing function and this change would break such an implementation.

Being able to turn it off is probably sufficient. Would it make sense to turn it off at a global level?

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2Bd%2BsvetpUs_mC-VEnH3y9J6nFyXyuDQ1ixW6Wnu7zV%3DA%40mail.gmail.com.

[José Valim]

> I'm nervous about existing inspect abuse as a hacky to_string. 

What do you mean?

>  I could see someone using it and feeding the result into a hashing function and this change would break such an implementation.

Using something like this today is already broken in all kinds of ways that I am not particularly concerned about it. :)

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Director of R&D

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAOMhEnwVRt-Xj2ajecHcdDPcZbCt5FU50v1Ng6gHH%2BAsD%2BjJag%40mail.gmail.com.

[Peter Hamilton]

The specific case I'm worried about is using inspect on a map and then using that result in something that is expected to be deterministic (like using it as a key in Redis).

I did a quick search on Github for Elixir repositories using inspect as to_string. I found 4 cases where inspect was used outside of generating user readable strings.

That one is basically assuming that inspect(<array of strings>) will output valid javascript. If a long integer were in that list it would cause a javascript error (I don't know if that's prevented elsewhere in the code or not):

https://github.com/commentingon/DeepDive_PlugAndCowboy/blob/1ad46dad51543f39de8f3914ea5fc2f7a5624e9a/step_6/templates/rooms.html.ex#L61

This one is probably fine because `plural` will be a string:

https://github.com/phoenixframework/phoenix/blob/b9e4ae9f658108d1def9a32c27b06c318ae67a98/priv/templates/phoenix.gen.model/model.ex#L4

This one is interesting because it assumes that Code.eval(inspect(a)) == a, which brings up the question of whether we allow underscores in integers in our code? (Yes we do, so that's good):

https://github.com/mkremins/alembic/blob/2ae459201220b63af083d0d54325af93afa877f1/lib/config.ex#L47

That one is over my head. I don't know enough about absinthe to quickly figure out whether it would be a problem.

https://github.com/absinthe-graphql/absinthe/blob/43c27219d7f289baf4dae36b1a5596d0a2235072/lib/absinthe/type/built_ins/introspection.ex#L263

I completely agree that it is a bad practice to use inspect as to_string in deterministic situations. However, this would be a really really painful bug if someone were to use inspect(map_with_long_int) as a key in a datastore. All unit tests would likely pass because any new entries would reflect the new behavior, but in production existing entries would be orphaned and cause a pretty big fire (rolling back would also be a nightmare because new entries would then be orphaned with the old code).

I'm in favor of it being the new default, but messaging must be very clear here and disabling it should be part of that messaging.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BBfRJ792%2BPo7AZkkzcNgi4wLKh08YWJ6mfuKFeNAdzsQ%40mail.gmail.com.

[José Valim]

Thanks Peter!

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Director of R&D

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAOMhEnwqzfc3_53aQdcFrfwCKUTd2n%3DaF-CTy_e4bFGPHvxiBg%40mail.gmail.com.

[Ben Wilson]

Absinthe GraphQL will handle this fine. Arguably we shouldn't be using inspect there anyway, but these changes would be compatible regardless.

I'm also +1 about this change.

[Charles Okwuagwu]

Makes it much easier to read large integer (and other) values.

http://stackoverflow.com/questions/34064900/is-there-a-switch-to-enable-thousand-digit-grouping-100-000-by-default-in-iex

There's a suggestion here that you can use right away.

[José Valim]

Wojtek, could you please send a pull request?

--

You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/94761768-95ab-4b3d-9d6c-8fcfcf77b0b7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

[Wojtek Mach]

Yes, I'll work on it. Thanks for considering this proposal!

--
You received this message because you are subscribed to a topic in the Google Groups "elixir-lang-core" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elixir-lang-core/trxIuhky0a8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4J7X6PeXC4DR6pJPioDP6ceN%2Bx_iMUwPN4PR%2Bqq13VgLg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Wojtek Mach