strictyaml does not act as "a near-drop in replacement for pyyaml"

[rec]

I got started on moving to this, but now I discover your claim is not at all true - strictyaml does not offer even one function that is the same as pyyaml.

---

The one facility that the two appear to share is load, except good pyyaml code is using safe_load - but in fact load is a "false friend", as I discovered when I put it in my code:

>>> strictyaml.load('1') + 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'YAML' and 'int'

Yes, I understand why you are doing this, so you can preserve comments, but why not use another name considering this is an entirely different software service that returns a radically different type?

And there isn't a dump or a dumps like JSON and pretty well all other such systems have. Are we instead supposed to do as_document({"x": 1}).as_yaml()?

---

How much work would it really have taken to create a load, dump/dumps so you'd be compatible with pyyaml, json, toml, and pretty well all other serialization tools in Python?

Time is all humans have in their lives, and I just wasted 40 minutes of it because your description is the reverse of the truth.

[ArneBachmannDLR]

Not entirely wrong, but I see strictyaml more as a schema-validatable YAML subset, not a drop-in replacement for anything else. I also find it a bit hard to find documentation on certain features or APIs, but all in all it's a wonderful product that my tools (at my workplace) rely on.

Harsh criticism of an open-source project doesn't help anyone, it only reduces the maintainers' motivation to keep providing anything for the community for free. Instead, please make a concrete suggestion how to improve the current situation. Always start by contributing something actionable, instead of stating your personal frustration.

"Losing time" while evaluating libraries is part of our business. It may take hours, days, or weeks until you can be sure that a library doesn't have unforeseen incompatibilities, so hopefully you're paid for integrating it. Otherwise it's your hobby anyway...

[rec]

I write a huge amount of open source software and I take a great deal of time to do so and a lot of people use it.

https://github.com/rec/

(And I did very specifically suggest: "How much work would it really have taken to create a load, dump/dumps so you'd be compatible with pyyaml, json, toml, and pretty well all other serialization tools in Python?")

I believe in a decade on github, this is my first non-polite comment. Feel free to check my record.

But this was egregiously false advertising. I resent being sold a bill of goods.

---

The software claims on its front page "Acting as a near-drop in replacement for pyyaml, ruamel.yaml or poyo."

But there is literally not one point of commonality with pyyaml or ruamel.yaml - not one single matching function or method. (I don't know poyo.)

The most charitable suggestion is that someone wrote that line without ever even looking at pyyaml or ruamel.yaml.

That still isn't very honest. The other possibility is that someone wrote this, knowing it was wrong.

---

"Losing time" while evaluating libraries is part of our business.

Yes, of course, I've been doing this for 40 years.

Mistakes are one thing. Misrepresentation is quite another.

Get rid of that provably false claim or take the ten minutes to create load, loads, dump and dumps that work like Json, pyyaml, Toml

[theAkito]

I feel weirded out when developers expect every tool doing a specific job to be as similar as possible to the first most popular one.

It's often the case in my experience, that the first most popular tool for something specific is usually faulty and very lacking. So, keeping compatibility with it is often not a good idea and therefore not desired.

It ought to become more natural and expected to continually improve code, instead of expecting it to work forever just like it did ages ago. This includes API changes.

That said, I wouldn't per sé expect a "near-drop in replacement" to have precisely the same API as the thing it is replacing. It is simply a far-fetched assumption. A replacement most likely has at least all the features available that the tool contains, which it is replacing or it has different features that make the original ones obsolete. However, this does not imply the API always stays magically the same.

[rec]

I didn't "expect" it to do anything. It claimed to "Act as a near-drop in replacement for pyyaml, ruamel.yaml or poyo".