VOTE: PDEP-12: compact-and-reversible-JSON-interface

[Dr-Irv]

Vote on PDEP-12: compact-and-reversible-JSON-interface

Pull request with discussion: #53714

Rendered PDEP for easy reading: https://github.com/pandas-dev/pandas/blob/fbc5fe5d7ae6aa64406756d07897963aa5f96294/web/pandas/pdeps/0012-compact-and-reversible-JSON-interface.md

Number of voting members participating in discussion: 6 (maximum number of disapproval votes)

Voting will close in 15 days, i.e., on September 26, 2023.

Cast your vote in a comment below.

• +1: approve.
• 0: abstain.
  • Reason: A one sentence reason is required.
• -1: disapprove
  • Reason: A one sentence reason is required.
    • A disapprove vote requires prior participation in the linked discussion PR.

@pandas-dev/pandas-core

[mroeschke]

-1: Given the newness of the proposed JSON NTV format, I would support (as described in the PDEP)

if not, a third-party package listed in the ecosystem that reads/writes this format to/from pandas DataFrames should be considered

[phofl]

-1 as well, Same reason as @mroeschke, this should be a third party package for now

[bashtage]

-1. Not mature enough, and not clear what the market size would be.

[attack68]

I like that this PDEP brings a technical specification and clear objective to the JSON interface, which is very useful for microservice APIs. I also think it is very advantageous to have a motivated and solution oriented developer willing to work on the task - thank you for the proposal.

Some of the arguments here are valid, I think the third party option is possible but as you already started on categorising JSON issues I think that steps can be made in this direction anyway as part of maintenance to existing methods.

I think having a PDEP approval and a commitment to maintain this for any and all future types might be too onerous whilst the feature is not mature enough.

[rhshadrach]

-1 for the same reason I left in the PDEP:

I think this does not meet the bar of being a commonly used format for implementation within pandas

[jbrockmendel]

-1; agree with richard

[jreback]

-1 agree with the other core-dev responders

i think work in the existing json interface is extremely valuable. a number of the original issues raised are just bug fixes / extensions of already existing functionality.

trying to start anew is likely not worth the migration effort

that said if a format is well supported in the community we can reconsider in the future (obviously json is well supported but the actual specification detailed here is too new / not accepted as a standard)

[Dr-Irv]

-1 while I do think having a more comprehensive JSON format would be worthwhile, making a new format part of pandas means an implicit endorsement of a standard that is still being reviewed by the broader community.

[topper-123]

0: I like having json standards, but would like some outside adoption (eventually in an external module for pandas) before becoming standard inside pandas. I think this PDEP should be revisited again at a later stage, for example in 1/2 to 1 year.

Some comments about the PDEP process:

IMO we should be more considerate about proposing non core devs doing PDEPs that don't have at least some good support declared among core devs before writing. PDEPs take effort to write and it may be discouraging being asked to write one and then having it rejected IMO.

Concretely, I propose that if a non-core dev is proposed to write a PDEP, a core dev should sponsor the PDEP, i.e. support the basic idea in the PDEP, guide the PDEP writer in formulating the PDEP etc.

Core devs should probably have enough flair to be able to estimate themselves if an idea will be accepted, so PDEPS written by core devs do probably not need a sponsor, but OTOH having a writer + 1 sponsor would improve the likelihood of an idea having wide enough support to be accepted.

Just an idea to consider.

[Dr-Irv]

@pandas-dev/pandas-core Reminder for this vote, which will close on Tuesday, September 26. Note that there is currently no support for this PDEP, but by our proposed guidelines in PDEP-1, we have to allow for the possibility of many late approving votes. A few additional -1 votes will allow the voting to close early.

[phofl]

Fwiw abstains would also facilitate that if folks don’t feel strongly or didn’t participate in the discussion

[MarcoGorelli]

0 - going to abstain on this one

[WillAyd]

0 - nothing to add on top of what has already been said

[lukemanley]

0 - I've followed the discussion and agree with the feedback but do not have a strong opinion so I'll defer to others.

[Dr-Irv]

Final tally is 0 approvals, 5 abstentions, 7 disapprove. The quorum has been met. The PDEP fails.