Add io and formatter options to console exporter

[c24t]

Fixes #411.

[ocelotl]

Suggesting this in order to be able to use the Format Specification Mini-Language.

[AntonKueltz]

Moving this to the top level discussion since it got added to a thread just as it was resolved -

I'm not sure format is the best fit for everything all use cases. As an example, one of the fields in the dictionary structure we need to output is the latency of the span in milliseconds which we calculate via round((end - start) / scale). In other words, we're doing data transforms rather than just formatting how existing objects are output.

I suppose it's not impossible to do this sort of thing in a format string but it quickly becomes fairly hard to read compared to a formatter function which takes a Span and returns a str. So passing a function seems more succinct and flexible than format strings. Are there any major advantages you see with the format string approach? Or perhaps any issues with the formatter function approach?

[ocelotl]

Moving this to the top level discussion since it got added to a thread just as it was resolved -

I'm not sure format is the best fit for everything all use cases. As an example, one of the fields in the dictionary structure we need to output is the latency of the span in milliseconds which we calculate via round((end - start) / scale). In other words, we're doing data transforms rather than just formatting how existing objects are output.

I suppose it's not impossible to do this sort of thing in a format string but it quickly becomes fairly hard to read compared to a formatter function which takes a Span and returns a str. So passing a function seems more succinct and flexible than format strings. Are there any major advantages you see with the format string approach? Or perhaps any issues with the formatter function approach?

Ok, I understand your concern. What I think is happening here is that we are asking the format to do more than just formatting, we are asking it to also calculate stuff (in other words, to produce a field). The ideal solution would be to have all the fields that we want to have formatted ready before asking for the formatter to format them. I'm thinking right now about how to keep these 2 things cleanly separated, will update soon.

[ocelotl]

Moving this to the top level discussion since it got added to a thread just as it was resolved -

I'm not sure format is the best fit for everything all use cases. As an example, one of the fields in the dictionary structure we need to output is the latency of the span in milliseconds which we calculate via round((end - start) / scale). In other words, we're doing data transforms rather than just formatting how existing objects are output.

I suppose it's not impossible to do this sort of thing in a format string but it quickly becomes fairly hard to read compared to a formatter function which takes a Span and returns a str. So passing a function seems more succinct and flexible than format strings. Are there any major advantages you see with the format string approach? Or perhaps any issues with the formatter function approach?

Also, in order not to block this PR with my format investigations, I have asked @c24t to disregard the mini language suggestions for the time being, I'll open a new PR later if I find them worthy.

[codecov-io]

Codecov Report

Merging #412 into master will increase coverage by 0.21%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #412      +/-   ##
==========================================
+ Coverage   85.86%   86.08%   +0.21%     
==========================================
  Files          41       41              
  Lines        2080     2084       +4     
  Branches      242      242              
==========================================
+ Hits         1786     1794       +8     
+ Misses        223      219       -4     
  Partials       71       71

Impacted Files	Coverage Δ
...sdk/src/opentelemetry/sdk/trace/export/__init__.py	89.05% <100%> (+2.58%)	⬆️
...emetry-sdk/src/opentelemetry/sdk/trace/__init__.py	91.17% <0%> (+0.36%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2a54a93...e09df42. Read the comment docs.

[codeboten]

Nice, would be good to add an example in the docs, but that can be done separately.