Probably secret option number 3 of no-one having needed it yet - because the tool is standalone, you can render the required output before running whatever needs to consume it. I’ve certainly used it from Python in that manner - bindings are only required if you want to consume the raw language programmatically from a Python context.

Exactly this. Pkl is most useful as a type-safe configuration language that can output to any other format (already supported, or put together by the user within Pkl). You’ll always get valid JSON, YAML, PLIST, what-have-you as output. This you can then parse in the language/system of your choice.

Certainly language bindings are useful, and if there’s demand likely someone will create them.

> 1) Because the developers of Pkl are Python haters

Is it really that deep?

“Popular” doesn’t mean “fitting every purpose”.

All the listed languages are compiled and statically typed. Python is neither. Neither is JavaScript, another popular programming language which is also not listed.

I don't see how the static typing of the bound languages enters into it. Python has type hints which can be enforced by some compilers, if you are so committed to type safety in your config scripts. If you have Pkl output YAML or XML then where is your type safety?

Since "popular" does mean that very many people are using it, I think it would be wise to try to serve the Python community.

> Because the developers of Pkl are Python haters

Look at the languages that they do support - Go, Swift, Kotlin, Java. These are all robust languages for writing production grade software. That's probably why - the people at Apple using this don't need it for their hacky Python scripts.

By "production grade software" do you mean major sites like Instagram or Reddit?

I think this intended for compiled languages? If you already have Python or Ruby in your stack you can simply write a little script to generate the required JSON or YAML. I'm not sure you would ever want to add Pkl to the mix in that case?

Another possibility: a naming conflict with, and potential confusion around the already existing Python serialisation library 'pickle'?