Welcome Team!

[johannschopplich]

Hi @bpradana, @davidpirogov, @xaviviro, and @Justar96! 👋

Following our discussion in #54, the official Python implementation repo is now ready. All of you have been invited as maintainers.

What's Ready

This Repository

You now have full access to toon-format/toon-python. This is where you can build the consolidated Python implementation together.

Language-Agnostic Tests

I have finished the language-agnostic: The spec repository now includes language-agnostic test fixtures that all implementations can use:

• Encoding tests: JSON → TOON conversion (tests/fixtures/encode/)
• Decoding tests: TOON → JSON parsing (tests/fixtures/decode/)
• Error cases: Validation and strict mode checks
• Edge cases: All specification corner cases

These JSON fixtures ensure consistency across all language implementations and make it easy to validate spec compliance.

Next Steps

Based on your feedback, Option A (pick the strongest foundation) was the consensus. Here's how to move forward:

1. Technical Evaluation (async via issues):
   • Review each existing implementation's architecture
   • Identify strengths and learnings from each approach
   • Propose which codebase to use as the foundation
   • Discuss testing strategy, API design, and milestones

Note

You can touch every file in this repo – I've only set up a base without much knowledge about Python. Feel free to challenge everything!

2. Initial Setup:

   • @davidpirogov proposed toon-llm as a starting point
   • Set up project structure (uv, type safety, linting, CI)
   • Integrate the spec repo's test fixtures
   • Establish contribution guidelines

3. Collaborate:

   • Use issues and PRs for design discussions
   • Work async across timezones
   • Equal ownership and decision-making

Key Priorities

From the discussion, here's what we're aligned on:

• ✅ Full SPEC.md compliance using the language-agnostic tests
• ✅ uv for package/environment management
• ✅ Type safety and linting enforced from day one
• ✅ CI with GitHub Actions validating spec compliance
• ✅ Support for Python 3.11-3.14t (including free-threaded)
• ✅ Clear docs and pythonic API design

Future milestones discussed:

• NumPy/SciPy/Pandas support
• Custom serializer architecture
• Performance optimizations (Rust/C bindings later)

Team Work

Please be kind to each other. I've something is off or you experience troubles in the team, please DM me and we get this sorted out.

Let's Get Started

Feel free to open issues to kick off discussions about:

• Which codebase to use as the foundation
• Project structure and tooling decisions
• How to integrate the spec test fixtures
• Migration plan for existing users

Thank you all for stepping up to collaborate on this. Looking forward to what you're going to build! 🎉

---

P.S. – Release tokens for PyPI publishing will be added to the repo's environment secrets once we're ready to publish.

[Justar96]

my suggestion for scope let's keep it pure serialization. my understanding is toon is not a data processing library?

• core operations: encode(dict) → str and `decode(str) → dict
• works with standard Python types (dict, list, str, int, bool, None)
• users can easily convert: encode(df.to_dict('records')) themselves. more flexible.

same approach as json and yaml

[xaviviro]

Hi team! 👋
Thanks @johannschopplich for setting this up and bringing us together!
Foundation & PyPI Package
I'm happy to contribute my python-toon implementation as the starting point. I'll migrate the core parts here, incorporating the improvements we've discussed:

✅ uv for package management
✅ Full type safety with mypy
✅ Linting setup (ruff)
✅ CI/CD with the spec test fixtures
✅ Python 3.11-3.14t support

Regarding PyPI: Both toon-python and toon-format are already taken. However, I currently own python-toon on PyPI. If the team agrees, we could use pip install python-toon as the official package and I can transfer ownership to the toon-format organization when we're ready.

• ❌ toon-python (taken)
• ❌ toon-format (taken)
• ✅ python-toon (owned by me, available for transfer)

Scope Agreement
@Justar96 I completely agree with keeping it pure serialization. Core focus:

encode(dict) → str and decode(str) → dict
Standard Python types only
Let users handle their own conversions (like df.to_dict())

This keeps it simple, follows the json/yaml philosophy, and avoids scope creep.

[johannschopplich]

As stated earlier in toon-format/toon#54, I've set up toon-format for this organization. Please use this package name instead of migrating yours. Thanks!

[xaviviro]

Great!

✅ toon_format

[johannschopplich]

PS: I haven't added your names to either the README and License. Please add them in one of the following PRs. Thanks!

[batprem]

Hi, I just found this. I want to propose my idea to use Rust as a backend to enhance encode/decode speed.

I've done some work in my repo here.

https://github.com/batprem/py-rtoon

[Justar96]

hey! thanks for the proposal, this looks awesome!!. we're currently focused on keeping the codebase in pure python stdlib for now, but we might consider integrating your rust binding in the future for performance enhancements.

[batprem]

@Justar96 Thank you for your reply

Just sharing current state of my project:

• Now, it's available on PyPi with ensure compatible to Window, Mac, Linux with Python>=3.9
• More than 80 unit test cases

The further plans are:

• Add benchmarking (computational performance test) to pure Python module
• Add accurate benchmarking
• Integration to third party such as Pandas, Pydantic, Langchain, Langgraph etc.

[johannschopplich]

@batprem Thanks for sharing! Although, I'd love to see you contributing to this repo and/or toon-rust so we can work together on making the de-facto community-driven TOON libraries. Ecosystem fragmentation in the end hurts other devs, so having a unified approach would bring the TOON standard forward. In case you're open to this idea, feel free to join the development.

Currently, this repo is still in its beginning shoes. Your insights are value, for sure.

[davidpirogov]

For applicability to many different orgs and use cases, we need to have a pure Python serializer and deserializer as default.

Then, we can have a Rust/etc options.

that said, I’d be keen to have optionality