[Feature Request] Include Json in standard library

[drunkwcodes]

Review Mojo's priorities

• I have read the roadmap and priorities and I believe this request falls within the priorities.

What is your request?

Json is an important data serialization format.
With json, we can communicate with web API, javascript, and subprocesses' inter-process communication.

What is your motivation for this change?

It is such a good replacement of python pickle format. It allows us dumping data objects in plain text.

By manipulating lists and dicts, and putting it in to core language feature, we can make savvy mojo applications.

Any other details?

python json exposes an API familiar to users of the standard library marshal and pickle modules.

Here I list json's API as following:

json.dump(obj, fp, *, skipkeys=False, ensure_ascii=True, check_circular=True, allow_nan=True, cls=None, indent=None, separators=None, default=None, sort_keys=False, **kw)

json.dumps(obj, *, skipkeys=False, ensure_ascii=True, check_circular=True, allow_nan=True, cls=None, indent=None, separators=None, default=None, sort_keys=False, **kw)

json.load(fp, *, cls=None, object_hook=None, parse_float=None, parse_int=None, parse_constant=None, object_pairs_hook=None, **kw)

json.loads(s, *, cls=None, object_hook=None, parse_float=None, parse_int=None, parse_constant=None, object_pairs_hook=None, **kw)

The detail is in the python docs.

[lattner]

JSON is super important, but right now we are tracking more basic things, e.g. getting core data structures in place. Higher level libraries like this should likely be part of the broader package ecosystem, and we need packages before we plan that :-)

[drunkwcodes]

I understand that the modular team is currently prioritizing more basic functions, but there are certain packages that are essential for the package downloader itself. These packages, such as json, requests, click, tomlkit, and zipfile, are crucial for communication with the package index website, establishing a CLI interface, handling classic configuration file formats, and packaging.

Ideally, these packages should already be present in the standard library, as they serve as foundational building blocks for other third-party packages. If they are not part of the standard library, they will need to be vendored in the package manager.

However, it's worth considering the benefits of including these packages in the standard library. Doing so would greatly benefit the mojo community, aligning with Python's traditional "batteries included" philosophy. Moreover, having these newer packages included in the standard library would lead to a more well-developed paradigm with better APIs than what's currently available in Python.

I urge the team to reconsider their stance on including these essential packages in the standard library, as it would undoubtedly enhance the overall Mojo ecosystem and support the development of high-quality CLI applications.

[ksandvik]

You could bootstrap any package tools/code using Python modules initially.

[lattner]

Hi @drunkwcodes, I think you might misunderstand. I realize that this is all super important, I just don't think we need to track these in the issue tracker at this early stage. We'd love to build this out as a community, and will need to figure out how to organize that work. Having ideas like this in the issue tracker doesn't help get that going. For example, we need to get mojo downloadable first :-)

[drunkwcodes]

Hello Mr. @lattner,

If this is not as planned, I will adjust and use Discord more frequently. And I found that the Python dict works with the code in the programming manual. Sorry for that, and I corrected my post.

I feel a little bit "scared," which means awesome, by Rust's weekly march, and I expect another "Julia release" once more. I used Julia once, and it was remarkably smooth. But something got "lost" in my heart, and I left when my colleague's wow sound ended.

Luckily, here comes mojo. So, I'm collecting some timestamps in my timeline now. Better than none. And also preparing some surprises for Mojo. One thing is Tube, a Mojo code formatter. I only have a logo now. May I register the package name right now?

Mojo will eat Python's market share by definition. And my preparation includes reading the black formatter from the first commit on GitHub. Nowadays, a code formatter should have code consistency or equivalence checks, which require the technical support of a well-coordinated team. It would need one season after getting parsing support to see certain accomplishments. I plan to port it to Python first to have a concrete formatter app, then port it back to Mojo when the moment comes. So good! For example, I currently have black's pytree module.

I can't wait to read the Mojo source code to know how to parse Mojo correctly.