Support for `/` operator as shorthand for `ic(…)`

[isidroas]

Currently, to log a variable using icecream, we must call the function:

ic(my_var)

I’d like to propose supporting the use of the / operator as a shorthand to improve ergonomics

ic / my_var

This syntax eliminates the need for parenthesis, making it quicker to type and just as easy to remove in your editor.

An additional alternative could be:

my_var | ic

However, I’d suggest discarding this one, as it could cause unintended behavior when working with integers.

Inspired in https://github.com/igrek51/wat

I believe there’s no overlap between the two libraries: wat is more geared toward interactive usage, while icecream is primarily for debugging during development.

Let me know what you think!

[salabim]

I find this a crazy idea.

E.g. what to do with ic/x*y ? According to the operator precedence rules, this will be equivalent to (ic/x)*y And that is -I guess- not wanted behaviour.

And anyway, what's wrong with two parentheses ?

So, I vote -1 !

[isidroas]

Hi @salabim, thanks for the feedback!

(ic/x)*y
And that is – I guess – not wanted behavior.

You’re absolutely right. In cases where precedence would bite you, I’d simply use the normal call syntax ic(x * y)

And anyway, what's wrong with two parentheses?

It comes down to keystrokes and speed in your editor. In most text editors:

• Call syntax

  1. Type ic(
  2. Jump to the end of the expression
  3. Type )

• Operator syntax

  1. Type ic/

And when you remove the debug statement:

• Call syntax

  1. Delete ic(
  2. Jump to the end of the expression
  3. Delete )

• Operator syntax

  1. Delete ic/

Because these logs are usually temporary, shaving off even a couple of keystrokes per statement can speed up both insertion and cleanup.

Would that compromise address your concerns?

[salabim]

It looks like your main use case is than you have an expression that you want to 'ic' and later keep the expression but remove ic. I don't think that is how ic is normally used, which is much more a supercharged print. E.g. ic(value[1]) This whole line would be deleted later.

Does that make sense?

[isidroas]

I agree—when when you are creating a new line only for printing, the keystroke savings are minimal, especially since many editors auto-close ( for you. The real win is when you want to inject traces into an existing expression without restructuring it. For example, given:

return process(parse(data.pop()))

you could “sniff” at any point in the pipeline:

return process(parse(ic / data.pop()))
return process(ic / parse(data.pop()))
return ic / process(parse(data.pop()))

This lets you drop in—and later remove—ic/ at exactly the spot you need, rather than juggling parentheses.

I also use this shorthand exclusively for debugging and would never commit an icecream call to the repository. If I need to print something for end users, there are more suitable tools available. Perhaps this is the root cause of our discrepancy?

[rodigu]

this idea grows on me the more i think about it.

the fact that there already is a published library with the exact same functionality, i think it is worth taking into consideration.

looking at wat's implementation, it does exactly what you'd imagine (with dunder truediv):

    def __truediv__(self, other): return self.inspect(other)  # /

icecream's formatting implementation inside __call__ might need some adjustments for this to work as seeminglessly as it does now.

[Jakeroid]

Honestly speaking, from my point of view, it looks like adding unnecessary complexity to the library.

There are 2 main reasons:

1 . Why not just add a macro to your editor to quickly add a new line and then remove it completely? For example, in NeoVim you could add appending new line with ic ( + selection + ) with Lua. I believe, other editors also could do something like that by hotkey.

2. Adding inside linter a rule to double check ic would help avoid committing it into repo.

[Jakeroid]

What I can suggest here that we can add an instruction how to patch somehow ic instance to make it able to work with / operator. In that way the library would not have any additional complexity, however README.md would have an instruction how to do so.

If someone decide to help here - let me know. Till then I'm closing the issue.