yini-parser-python is now public - feedback and early testing welcome

I recently made yini-parser-python public.

It is a Python parser for YINI - an INI-inspired, indentation-insensitive configuration format with explicit nested sections and predictable parsing rules.

The package is also on PyPI: pypi.org/project/yini-parser

YINI is still a young project and the spec is moving toward its first stable 1.0.0 release. That is exactly why I want feedback now - before things solidify. If something looks unclear, surprising, fragile, or difficult to maintain, I would rather hear about it at this stage than after the format is locked.

What the parser does

The goal of yini-parser-python is to provide a usable Python implementation of YINI. A small example looks like this:

@yini

^ Application
name = 'Demo Application'
version = '1.0.0'
debug = yes

^^ Server
host = 'localhost'
port = 8080

^^^ Logging
level = 'info'
file = './app.log'

Which represents this structure:

Application
└─ Server
   └─ Logging

Section nesting is defined by the markers - not by indentation or whitespace. That is the core idea.

Current status

The parser is early-stage but usable enough for testing and review. It currently passes the full yini-test suite - a separate Python-based test project with golden tests for parser behavior.

That suite has around 150 tests at the moment (76 lenient + 75 strict = 151 golden tests, I might make a more specific post about yini-test later on). It covers the important cases but is not yet comprehensive. More tests will be added as both the format and the implementations mature. The yini-test project is also planned to go public, if it has not already by the time you read this.

What kind of feedback would be useful?

Primarily:

• Parser bugs
• Unclear or surprising behavior
• Edge cases worth adding to the test suite
• Packaging or installation issues
• Python API design
• Documentation improvements
• Places where the implementation could be simpler or more maintainable

Bug reports, small reproductions, pull requests, and implementation suggestions are all welcome. Alpha or beta testers too - even a quick "I tried this and it worked / did not work" is useful right now.

Why share it before 1.0.0?

Because this is when careful review matters most. Once a configuration format stabilizes, small syntax and behavior decisions become much harder to change. I would rather get practical feedback early - especially from developers with experience in configuration formats, parsers, tooling, or Python packaging.

YINI is not trying to replace JSON, YAML, TOML, or INI. Those all have valid use cases. This is a more focused experiment:

What if INI-style configuration had clearer nested structure, while staying readable and predictable?

That is the design space I am trying to test.

Links

• GitHub: YINI-lang/yini-parser-python
• PyPI: pypi.org/project/yini-parser
• Organization: github.com/YINI-lang
• Website: yini-lang.org

If you try the parser and notice anything odd, unclear, or broken - feel free to make an issue, comment, or pull request, that would be very much appreciated.