Feature #14609: `Kernel#p` without args shows the receiver

• Status: Open
• Priority: Normal
• Assignee: matz (Yukihiro Matsumoto)
• Target version: 2.6

[ko1 (Koichi Sasada)]

Abstract

Kernel#p(obj) prints obj as inspected.
How about to show the receiver if an argument is not given?

Background

We recently introduce yield_self which encourages block chain.

https://zverok.github.io/blog/2018-01-24-yield_self.html
Quoted from this article, we can write method chain with blocks:

construct_url
  .yield_self { |url| Faraday.get(url) }.body
  .yield_self { |response| JSON.parse(response) }
  .dig('object', 'id')
  .yield_self { |id| id || '<undefined>' }
  .yield_self { |id| "server:#{id}" }

There is a small problem at debugging.
If we want to see the middle values in method/block chain, we need to insert tap{|e| p e}.

With above example,

construct_url
  .yield_self { |url| Faraday.get(url) }.body
  .yield_self { |response| JSON.parse(response) }.tap{|e| p e} # debug print
  .dig('object', 'id')
  .yield_self { |id| id || '<undefined>' }.tap{|e| p e} # debug print
  .yield_self { |id| "server:#{id}" }

Proposal

obj.p shows same as p(obj).

We can replace
block{...}.tap{|e| p e}
to
block{...}.p

For above example, we can simply add .p at the end of line:

construct_url
  .yield_self { |url| Faraday.get(url) }.body
  .yield_self { |response| JSON.parse(response) }.p # debug print
  .dig('object', 'id')
  .yield_self { |id| id || '<undefined>' }.p # debug print
  .yield_self { |id| "server:#{id}" }

Compatibility issue

(1) Shorthand for nil

This spec change can introduce compatibility issue because p returns nil and do not output anything.
That is to say, p is shorthand of nil. Some code-golfers use it.

Maybe we can ignore them :p

(2) make public method

Kernel#p is private method, so if we typo obj.x to obj.p (not sure how it is feasible), it will be NoMethodError because of visibility.
We need to change this behavior.

Note

Past proposal and discussion

Endoh-san proposed same idea 10+ years ago in Japanese.
I think we should revisit this idea because of yield_self introduction.

At this thread, Matz said "simple p shows p(self), it is not clear".

  p

はどう動くのかとか(p selfと同じ、は変な気が)

  self.p(obj)

はどうなのかとか。その辺が解決(納得)できたら、ということで。

English translation:

What the behavior of (I feel strange that it is similar to `p(self)`):

  p

What happen on

  self.p(obj)

pp

If this proposal is accepted, we also need to change pp behavior.

gems

tapp method is provided by gem.
https://github.com/esminc/tapp

I'd thought to propose this method into core. But I found that p is more shorter than tapp.
Disadvantage is p is too short and difficult to grep.

[mame (Yusuke Endoh)]

+1

Kernel#p is one of the greatest feature in Ruby. It would be further great to make it useful.

[zverok (Victor Shepelev)]

Small notice: If #13581 would be once acted upon, attaching p in the middle of the chain could be as simple as (using one of the proposed syntaxes)

  .yield_self { |response| JSON.parse(response) }.tap(&:.p)
  .dig('object', 'id')
  .yield_self { |id| id || '<undefined>' }.tap(&:.p)

Just .p is still nicer, though.

[Hanmac (Hans Mackowiak)]

hm i have a slightly problem with this

check out the different return types there:

a = []
p *a #=> nil

a = [1]
p *a #=> 1

a = [1,2]
p *a #=> [1,2]

[ko1 (Koichi Sasada)]

Hanmac: do you rely on this behavior?

[Hanmac (Hans Mackowiak)]

ko1 (Koichi Sasada) wrote:

Hanmac: do you rely on this behavior?

Me? not so much, in general i don't trust the return value of print commands (print returns null)

it was months ago, i probably wanted to point out that the return value of p might be differ depending on the parameters
It might be inconsistency?

There is Object.display too but i don't use it much because it doesn't have new lines

[osyo (manga osyo)]

Good proposal.
This can solve the following problem.

# NG: syntax error, unexpected ':', expecting '}'
p { name: "homu", age: 14 }

# OK:
{ name: "homu", age: 14 }.p
# => {:name=>"homu", :age=>14}

[nobu (Nobuyoshi Nakada)]

osyo (manga osyo) wrote:

Good proposal.
This can solve the following problem.

# NG: syntax error, unexpected ':', expecting '}'
p { name: "homu", age: 14 }

You can use parentheses.

p(name: "home", age: 14)

[shevegen (Robert A. Heiler)]

I don't mind, personally. To me, the biggest improvement was
that we could omit doing:

require 'pp'

;)

Since I did that a lot in my code. (I love pp; I think I use it
more than just p)

I personally have not been using (or needing) yield_self or tap so
far, so the change would probably not be of immediate benefit to
me; but probably also not require of me to change anything either.

To the name "tapp" - that name is a bit weird. To me it reads as
if we combine "tap" and then add a "p" to it. Reminds me of a
joke proposal to condense "end" into "enddd" and such. :D

To be fair, I consider the name yield_self to be also weird :D -
but matz added an alias called "then" to it if I understand it
correctly (though the semantic confuses me a bit as well ... but
I don't really want to distract here since I don't really feel
too strongly either way; picking good names is not always easy).

On a side note, perhaps in the long run we could have something
to "experiment" with - like new or changed features in ruby that
have not been 100% approved in the sense of a name AND the associated
functionality, so we can try them out for some time, which may help
build a stronger opinion either way. (I mean this in general, not
just in regards to #p here).

It may still be best to ask matz again though. Syntax shortcuts
(syntactic sugar) has always been an area in ruby where code changes
has happened (e. g. yield_self to then, or omitting the end value
for infinite ranges and so forth).