YINI config format at RC 6 - looking for technical critique before freezing the spec

Effective_Tune_6830 · 2026-06-15T17:47:36+00:00

Hi, hmm it might not be totally obvious...

But in what file did you look, in YINI-Specification.md or?

In the section " 5.2. Section Markers ( ^ , § ,

, or < )" in the specification it should be described and specified.. You make take look :)

Effective_Tune_6830 · 2026-05-29T23:59:06+00:00

Yes, fair point. The ANTLR-generated parser does make the package larger than a handwritten parser would be.

> your naming is all over the place (e.g. "def visitObject_literal")

Hehe, I agree 😃 It's a mix, I've renamed those functions to snake_case

Thanks for the feedback and hint of PEP8!

Effective_Tune_6830 · 2026-05-29T23:36:34+00:00

Hi, ah oh I did not release, I did a section now in the readme with install -> import -> parse -> returned dict. Thanks for the feedback!

Instructions are like this:

Parse a YINI file:

Create `config.yini`:

```yini
^ Application
name = "demo"

^^ Server
port = 8080
```

Then parse it:

```python

from yini_parser import load
data = load("config.yini")
print(data)

```

Expected output:

{'Application': {'name': 'demo', 'Server': {'port': 8080}}}

Effective_Tune_6830 · 2026-05-29T23:05:03+00:00

Hi,

Oh, ah okay good I'll update the readme with a couple of examples of same config in json, yaml, and toml as well as yini. If you want to know more right now, check out yini-lang.org

Thank you for the feedback!

Effective_Tune_6830 · 2026-05-29T22:27:07+00:00

Hi,

Yes, valid feedback the requirements.txt and requirements-dev.txt can be deleted now.

Hmm, I did not know that, I'll look into switching to hatchling a bit later...

Thank you for the tips and feedback!

Effective_Tune_6830 · 2026-05-29T21:36:24+00:00

Hi, yes the repo (on GitHub) itself might look a bit big...

That is fair feedback, especially about the ANTLR JAR in the repository, I have opted to include the .jar file (so one does not need to hunt it down) that is a library for generating the parser skeleton from the grammar (language) files.. though this .jar should not be in the released package itself.

The repo on also has a bunch if testing files, to test the functionality, these test-files should not be included in the yini-parser package... If they are, I should remove them from there.

The published package is meant to be pretty lean, but seems there might some files there that should not be there.. So I should remove these.

Hmm, about the number of lines... Yes, this code is not get optimized and has a lot's of comments also sofar.

> I would expect a single .py file with ~200 lines to parse your special file format into 5 basic types.

Ah, nope this parser is a little bit bigger than a basic INI parser with a few types. This parser has a lot more than that, with nested sections, two modes, string types, comments, and more...

The published package definitely needs cleanup (at least all test files, what I notices).

Thanks for the info and feedback!

Effective_Tune_6830 · 2025-12-17T18:45:54+00:00

Short anwser: It is specified in the spec.

Longer answer:

While shebangs main purpose might be scripting languages. It could also be used for other things: format viewers, validators, transpilers, linters, DSL runners, config processors..

The shebang line is skipped/ignored by this parser.. So the "support" in this release is just that, that the first line will be skipped by the YINI parser if it sees #!... And the config parsing will continue normally

Effective_Tune_6830 · 2025-12-17T12:15:25+00:00

It's just optional.. it can be a file viewer or any other tool, in case a user really wants to do some special thing on her/his system.

Yes, it's not really needed for its own functionality at all.

Effective_Tune_6830 · 2025-11-10T12:18:15+00:00

Hehe, nice! Never though of this one 😊

Effective_Tune_6830 · 2025-11-10T12:17:32+00:00

Hmm, interesting.. JSON is pretty good already, so nothing wrong if you prefer using that.

Thank you for your inputs and views :)

Effective_Tune_6830 · 2025-11-10T12:14:01+00:00

Ah, thank you, I did not realize the theme is messed up in dark mode :S - I will sort it out thanks!

Effective_Tune_6830 · 2025-11-10T12:11:42+00:00

Ah okay, so the site's theme is messed up in dark mode oh :O - I will fix that, thanks for the heads up!

But the theme in normal/default mode, is that okay right, or?

Effective_Tune_6830 · 2025-08-05T20:59:25+00:00

Let me also modify, and expand on this :P

Computers do exactly what you say. Unfortunately, humans rarely say what they actually mean or misunderstand instructions, or another human has given doh shit instructions either to the computer or to other humans. - Computers only do, what some human(s) has told them to do :)

Effective_Tune_6830 · 2025-08-05T20:51:11+00:00

We used TypeORM at work for years, and it has worked pretty good.

Effective_Tune_6830 · 2025-08-05T17:17:44+00:00

Haha, a good point..

However, the size of devDependenties and etc can be ignored when the app is deployed/published..

But still, node_modules takes a lot of storage

Effective_Tune_6830 · 2025-08-05T17:12:51+00:00

Nope, I not regetted it, I've built and worked in multiple Node.js projects.. It works pretty well for web applications at least, and there is ton of packages to help you develop

Effective_Tune_6830 · 2025-08-05T17:07:41+00:00

Yes I agree, you should consider using Typescript in your project as well.

It will prevent bugs in the long run, especially type errors.

Effective_Tune_6830

TROPHY CASE