The Norway Problem

656 点作者 dedalus大约 4 年前

65 条评论

This is part of more general problem, they had to rename a gene to stop excel auto-completing it into a date.<a href="https://www.theverge.com/2020/8/6/21355674/human-genes-rename-microsoft-excel-misreading-dates" rel="nofollow">https://www.theverge.com/2020/8/6/21355674/human-genes-renam...</a>Edit: Apparently Excel has its own Norway Problem ... <a href="https://answers.microsoft.com/en-us/msoffice/forum/msoffice_excel-mso_win10-mso_o365b/norway-not-showing-on-maps-in-excel/a0a9d886-598b-46e1-a2f9-35794960b89a" rel="nofollow">https://answers.microsoft.com/en-us/msoffice/forum/msoffice_...</a>

评论 #26679426 未加载

评论 #26679629 未加载

评论 #26681150 未加载

评论 #26680493 未加载

评论 #26679744 未加载

评论 #26679570 未加载

评论 #26680626 未加载

评论 #26680501 未加载

评论 #26680982 未加载

评论 #26686632 未加载

评论 #26691152 未加载

评论 #26680637 未加载

评论 #26693684 未加载

评论 #26680215 未加载

评论 #26679752 未加载

atombender大约 4 年前

The world desperately needs a replacement for YAML.TOML is fine for configuration, but not an adequate solution for representing arbitrary data.JSON is a fine data exchange format, but is not particularly human-friendly, and is especially poor for editable content: Lacks comments, multi-line strings, is far too strict about unimportant syntax, etc.Jsonnet (a derivative of Google's internal configuration language) is very good, but has failed to reach widespread adoption.Cue is a newer Jsonnet-inspired language that ticks a lot of boxes for me (strict, schema support, human-readable, compact), but has not seen wide adoption.Protobuf has a JSON-like text format that's friendlier, but I don't think it's widely adopted, and as I recall, it inherits a lot of Protobufisms.Dhall is interesting, but a bit too complex to replace YAML.Starlark is a neat language, but has the same problem as Dhall. It's essentially a stripped-down Python.Amazon Ion [1] is neat, but I've not seen any adoption outside of AWS.NestedText [2] looks promising, but it's just a Python library.StrictYAML [3] is a nice attempt at cleaning up YAML. But we need a new language with wide adoption across many popular languages, and this is Python only.Any others?[1] <a href="https://amzn.github.io/ion-docs/" rel="nofollow">https://amzn.github.io/ion-docs/</a>[2] <a href="https://nestedtext.org/" rel="nofollow">https://nestedtext.org/</a>[3] <a href="https://github.com/crdoconnor/strictyaml/" rel="nofollow">https://github.com/crdoconnor/strictyaml/</a>

评论 #26682730 未加载

评论 #26682792 未加载

评论 #26683310 未加载

评论 #26683205 未加载

评论 #26683314 未加载

评论 #26682412 未加载

评论 #26682258 未加载

评论 #26683122 未加载

评论 #26682703 未加载

评论 #26682842 未加载

评论 #26682934 未加载

评论 #26682079 未加载

评论 #26682046 未加载

评论 #26682574 未加载

评论 #26691261 未加载

评论 #26682101 未加载

评论 #26689291 未加载

azernik大约 4 年前

YAML had a worse example, once.For the ease of entering time units YAML 1.1 parsed any set of two digits, separated by colons, as a number in sexagesimal (base 60). So 1:11:00 would parse to the integer 4260, as in 1 hour and 11 minutes equals 4260 seconds.Now try plugging MAC addresses into that parser.The most annoying part is that the MAC addresses would only be mis-parsed if there were no hex digits in the string. Like the bug in this post, it could only be reproduced with specific values.Generally, if you're doing implicit typing, you need to keep the number of cases as low as possible, and preferably error out in case of ambiguity.

评论 #26679983 未加载

评论 #26679728 未加载

评论 #26679657 未加载

评论 #26681548 未加载

评论 #26679385 未加载

kstenerud大约 4 年前

The worst tragedy of this is the security implications of subtly different parsers. As your application surface increases, you're likely to mix languages (and thus different parsers), which means that the same input data will produce different output data depending on whether your parser replaces, truncates, ignores, or otherwise attempts to automatically "fix up" the data. A carefully crafted document could exploit this to trick your data storage layer into storing truncated data that elevates privileges or sets zero cost, while your access control layer that ignores or replaces the data is perfectly happy to let the bad document pass by.And here's something else to keep you up at night: Just think of how many unintentional land mines lurk in your serialized data, waiting to blow up spectacularly (or even worse, silently) as soon as you attempt to change implementation technologies!This is why I've been so anal about consistent decoder behavior in Concise Encoding <a href="https://github.com/kstenerud/concise-encoding/blob/master/ce-structure.md#security-and-limits" rel="nofollow">https://github.com/kstenerud/concise-encoding/blob/master/ce...</a><a href="https://concise-encoding.org/" rel="nofollow">https://concise-encoding.org/</a>

yellowapple大约 4 年前

This is exactly why configuration/serialization formats should make as few assumptions about value types as possible. Once parsing's done, everything should be a string (or possibly a symbol/atom, if the program ingesting such a file supports those), and it should be up to the application to convert values to the types it expects. This is Tcl's approach, and it's about as sensible as it gets....which is why it pains me to admit that in my own project for a Tcl-like scripting/config language[1] I missed the float v. string issue, so it'll currently "cleverly" return different types for 1.2 (float) v. 1.2.3 (atom). Coincidentally, I started work on a "stringy" alternative interpreter that hews closer to Tcl's philosophy (to fix a separate issue - namely, to avoid dynamically generating atoms, and therefore avoid crashing the Erlang VM when given potentially-adversarial input), so I'm gonna fix that case for at least the "stringy" mode (by emitting strings instead of numbers, too), knocking out two birds with one stone for the upcoming 0.3.0 release :)----[1]: <a href="https://otpcl.github.io" rel="nofollow">https://otpcl.github.io</a>, for those curious

评论 #26679465 未加载

评论 #26679583 未加载

WalterBright大约 4 年前

> The most tragic aspect of this bug, howevere, is that it is intended behavior according to the YAML 2.0 specification.This is one of those great ideas that sadly one needs experience to realize are really bad ideas. Every new generation of programmers has to relearn it.Other bad ideas that resurface constantly:1. implicit declaration of variables2. don't really need a ; as a statement terminator3. assert should not abort because one can recover from assert failures

评论 #26679838 未加载

评论 #26679663 未加载

评论 #26680428 未加载

评论 #26683822 未加载

评论 #26679949 未加载

评论 #26679719 未加载

mcv大约 4 年前

If it ignores part of the spec, I don't think "strictyaml" is the correct name here. Instead, if it interprets everything as string, perhaps "stringyaml" would have been more accurate, though I'm sure that's not as good PR.I'm reminded of the discussion we had a few days ago about environment variables; one problem there is that env variables are always strings, and sometimes you do want different types in your config. But clearly having the system automatically interpret whether it's a string or something else is a major source of bugs. Maybe having an explicit definition of which field should be which type would help, but then you end up with the heavy-handed XML with its XSD schema.Or you just use JSON, which is light-weight, easy to read, but unambiguous about its types. I guess there's a good reason it's so popular.Maybe other systems like yaml and environment variables should only ever be used for strings, and not for anything else, and I suppose replacing regular yaml with 'strictyaml' could play a role there. Or cause unending confusion, because it does violate the spec.

评论 #26681545 未加载

评论 #26681498 未加载

评论 #26681355 未加载

grenoire大约 4 年前

I was helping out a friend of mine in the risk department of a Big 4; he was parsing CSV data from a client's portfolio. Once he started parsing it, he was getting random NaNs (pandas' nan type, to be more accurate).I couldn't get access to the original dataset but the column gave it away. Namibia's 2-letter ISO country code is NA—which happens to be in pandas' default list of NaN equivalent strings.It was a headache and a half...

评论 #26679033 未加载

评论 #26679053 未加载

sdfhbdf大约 4 年前

What I am most baffled by with Yaml is the fact that it’s a superset of JSON.Whenever an input accepts YAML you can actually pass in JSON there and it’ll be validIt really surprised me when I found out and I use JSON Whenever possible since then since it’s much stricter<a href="https://en.m.wikipedia.org/wiki/JSON#YAML" rel="nofollow">https://en.m.wikipedia.org/wiki/JSON#YAML</a>

评论 #26679699 未加载

评论 #26679840 未加载

评论 #26679609 未加载

yakshaving_jgt大约 4 年前

> it’s equally true that extremely strict type systems require a lot more upfront and the law of diminishing returns applies to type strictness - a cogent answer to the question “why is so little software written in haskell?“I was with the article up until that point. I don't agree that diminishing returns with regards to type strictness applies linearly. Term-level Haskell is not massively harder than writing most equivalent code in JavaScript — in fact I'd say it's easier and you reap greater benefit. Perhaps it's a different story when you go all-in on type-level programming, but I'm not sure that's what the author was getting at. This smells of the Middle Ground logical fallacy to me. Or of course the comment was tongue-in-cheek and I'm overreacting.

评论 #26680288 未加载

评论 #26679116 未加载

评论 #26679139 未加载

abujazar大约 4 年前

Norwegian here. I’d say the problem is YAML, not Norway :D

jasode大约 4 年前

That author's blog post sent me down a rabbit hole of insanity with YAML and the PyYAML parser idiosyncrasies.First, he mentions "YAML 2.0" but there's no such reference about "2.0" from yaml.org or Google/Bing searches. Yaml.org and wikipedia says yaml is at 1.2. Apparently the other commenters in this thread clarified that the older "YAML 1.1" is what the author is referring to.Ok, if we look at the official YAML 1.1 spec[1], it has this excerpt for implicit bool conversions:<pre><code> y|Y|yes|Yes|YES|n|N|no|No|NO |true|True|TRUE|false|False|FALSE |on|On|ON|off|Off|OFF </code></pre> But the pyyaml code excerpts[2][3] from resolver.py has this:<pre><code> u'tag:yaml.org,2002:bool', re.compile(ur'''^(?:yes|Yes|YES|n|N|no|No|NO |true|True|TRUE|false|False|FALSE |on|On|ON|off|Off|OFF)$''', re.X), </code></pre> The programmer omitted the single character options of 'y' and 'Y' but it still has 'n' and 'N' ?!? The lack of symmetry makes the parser inconsistent.And btw for trivia... PyYAML also converts strings with leading zeros to numbers like MS Excel: <a href="https://stackoverflow.com/questions/54820256/how-to-read-load-yaml-parameters-with-leading-zeros-as-a-string" rel="nofollow">https://stackoverflow.com/questions/54820256/how-to-read-loa...</a>[1] <a href="https://yaml.org/type/bool.html" rel="nofollow">https://yaml.org/type/bool.html</a>[2] 2020 latest: <a href="https://github.com/yaml/pyyaml/blob/ee37f4653c08fc07aecff69cfd92848e6b1a540e/lib/yaml/resolver.py#L172" rel="nofollow">https://github.com/yaml/pyyaml/blob/ee37f4653c08fc07aecff69c...</a>[3] 2006 original : <a href="https://github.com/yaml/pyyaml/blob/4c570faa8bc4608609f0e531452f9941e4a272b3/lib/yaml/resolver.py#L96" rel="nofollow">https://github.com/yaml/pyyaml/blob/4c570faa8bc4608609f0e531...</a>

ancarda大约 4 年前

You can catch this with yamllint (<a href="https://github.com/adrienverge/yamllint" rel="nofollow">https://github.com/adrienverge/yamllint</a>):<pre><code> % cat countries.yml --- countries: - US - GB - NO - FR % yamllint countries.yml countries.yml 5:4 warning truthy value should be one of [false, true] (truthy)</code></pre>

RcouF1uZ4gsC大约 4 年前

YAML seems like a really neat idea, but over time, I have I have come to regard it as being too complicated for me to use for configuration.My personal favorite is TOML, but I would even prefer plain JSON over YAMLThe last thing I want at 2 AM when trying to look figure out if an outage is due to a configuration change is having to think if each line of my configuration is doing the thing I want.YAML prizes making data look nicely formatted over simplicity or precision. That for me, is not a tradeoff, I am willing to make.

评论 #26679210 未加载

ravanave大约 4 年前

Btw, the reason Haskell isn’t used more isn’t type system per se, as all types can be inferred at the compilation time. People would sometimes use this feature even to see if GHCi guesses the type correctly (by correctly I mean exactly how the user wants, technically it’s correct always) first time and save them some time writing it either with an extension or just copy&paste from the interpreter window.When it gets hairy is that most programming languages have low entrance barrier. To write Haskell effectively you’ve got to unlearn a lot of rooted bad habits and you get to dive into the “mathematical” aspect of the language. Not only you got monads, but there’s plethora of other types you need to get comfortably onboard with and the whole branch of mathematics talking about types (you don’t need to even know that such a field as category theory exists to use it).However, since most people just want to write X, or just want hire a dev team at price they can afford, Haskell rarely is the first choice language.

评论 #26688131 未加载

lolinder大约 4 年前

This comment was buried in a thread, but I'm bringing it out because it's very relevant to the conversation:<a href="https://news.ycombinator.com/item?id=26679728" rel="nofollow">https://news.ycombinator.com/item?id=26679728</a>> the article refers to YAML 2.O, a nonexistent spec, and to PyYAML, a real parser which supports only YAML 1.1.> Both the unquoted-YES/NO-as-boolean and sexagesimal literals were removed in YAML 1.2.

评论 #26689516 未加载

paxys大约 4 年前

I will never understand why YAML didn't just require quoted strings. Did the creator not anticipate how many problems the ambiguity would cause?

评论 #26679524 未加载

blunte大约 4 年前

If you want no misunderstandings, be explicit. This applies to YAML and life in general. There's an annoying but fairly accurate saying about assumptions that applies.If you want something to be a specific type, you better have an explicit way of indicating that. If you say quotes will always indicate a string, great. Of course we know it's not that simple, since there are character sets to consider.The safest answer is to do something like XML with DTDs. But that imposes a LOT of overhead. Naturally we hate that, so we make some "convention over configuration" choices. But eventually, we hit a point where the invisible magic bites us.This is one case where tests would catch the problem, if those tests are thorough enough - explicitly testing every possibility or better yet, generative testing.

评论 #26682750 未加载

dpratt71大约 4 年前

I don't understand why Haskell gets brought up in the middle of an otherwise interesting and useful article. This sort of thing cannot happen in Haskell. And while Haskell is not universally admired, I can't recall seeing Haskell's flavor of type inference being a reason why someone claimed to dislike Haskell.

Waterluvian大约 4 年前

I have never gotten far into a project and thought, "my config files are too verbose. I wish there were clever shorthands."Does Yaml have any sort of strict mode?I imagine I could find a linter that disallows implicit strings.

评论 #26680672 未加载

eitland大约 4 年前

There exists a couple of mainstream languages that are full of these sorts of interesting behavior, one of them is supposedly cool and productive and the other is supposedly ugly and evil.

评论 #26682626 未加载

评论 #26679403 未加载

评论 #26679141 未加载

dragonwriter大约 4 年前

its weird that this is a 2019 article misrepresenting behavior in the YAML 1.1 spec (2005) most of which reverted in the YAML 1.2 spec (2009) as being part of a nonexistent YAML 2.0 spec and justifying a library that purports to handle “YAML” ignoring the spec.

评论 #26681699 未加载

IHLayman大约 4 年前

Reminds me of the multiple YAML bugs that have plagued Kubernetes such as <a href="https://github.com/kubernetes/kubernetes/issues/82296" rel="nofollow">https://github.com/kubernetes/kubernetes/issues/82296</a>It is interesting how the standard of any language seems to diverge due to just the implementation from different parsers.

dan-robertson大约 4 年前

Other reasons to not want types happening during parse time:- “modified” numbers, e.g. $50, 35%, 1.2345568896347853246863477- Dates. If your language tries to convert a date to Unix time or Julian Day, you can have problems with time zones or distant or historical dates.- strings vs symbols. The person writing config shouldn’t have to care about this distinction.- Automatic deduplication for fields of objects can be a problem.

LeonM大约 4 年前

I was bitten with this issue some time ago.The Stripe library has constants for which type of VAT number is supplied. One of those constants is 'NO_VAT'...Needless to say, this caused me some grey hairs

suttree大约 4 年前

Reminds me that the reasoning behind austerity came from an Excel calculation that didn't include all the relevant rows :~/<a href="https://www.theguardian.com/politics/2013/apr/18/uncovered-error-george-osborne-austerity" rel="nofollow">https://www.theguardian.com/politics/2013/apr/18/uncovered-e...</a><a href="https://www.bbc.co.uk/news/magazine-22223190" rel="nofollow">https://www.bbc.co.uk/news/magazine-22223190</a><a href="https://theconversation.com/the-reinhart-rogoff-error-or-how-not-to-excel-at-economics-13646" rel="nofollow">https://theconversation.com/the-reinhart-rogoff-error-or-how...</a>

评论 #26689590 未加载

thrower123大约 4 年前

I've never seen anything that used YAML that I didn't want to douse with gasoline, nuke from orbit, and then salt the ground where it once stood.I cry and rage and rend my clothes when I stumble upon some new thing that makes me have to use it.

pintxo大约 4 年前

> “While the website went down and we were losing money we chased down a number of loose ends until finally finding the root cause.”And that's why you have a staging environment. Or you debug in production, whatever you prefer.

评论 #26679029 未加载

评论 #26679165 未加载

评论 #26679079 未加载

评论 #26679394 未加载

dwheeler大约 4 年前

The YAML specification eliminated this problem in 2009, with the release of version 1.2. That spec also eliminated some other problematic problems.The real problem is that YAML parsers in wide use have not been updated to the spec that was released TWELVE years ago.So who's going to help the common YAML parser developers update their implementations to support version 1.2? I think that would be a big help. Maybe the Norwegian government can chip in some money & time to get them updated, that would probably quietly eliminate a number of problems.

评论 #26692916 未加载

runeks大约 4 年前

Why not just enclose your strings in quotes and be done with it?As far as I can see, this has nothing to do with typing and everything to do with syntax (of literals). If strings were required to be quoted this problem wouldn’t appear.This is the reason no programming language has this issue — regardless of type system (JS/Python/Java/Haskell). If you want a string here you need quotes.Haskell could even be regarded as what the author calls “implicitly typed” — since types are derived from literals — and I’ve never heard a Haskeller complain about this issue.

jansan大约 4 年前

Norway is one of the luckiest countries in the world. They have a vast amount of resources, can produce their electrical energy entirely from hydropower, have a great democracy, a government they can trust, a beautiful landscape and great people.I must say that I feel a little bit of relief to see that they have problems that nobody else has, besides insanely expensive alcohol that is only sold in "wine monopoly" stores that are more heavily guarded than banks.

DoofusOfDeath大约 4 年前

Funny coincidence. Around 2000, I worked for a company that coined the term "Norway problem" for a different software problem.Their product used an MVCC database (I think ObjectStore). One of their customers in Norway had a problem where updates to the database seemed to not show up. IIRC the problem was a bug in this company's software that caused MVCC to show an older version of the database content than expected.

Hendrikto大约 4 年前

> The real fix requires explicitly disregaring the specOr… just quote your strings.

评论 #26679881 未加载

dangoor大约 4 年前

Cue also solves this problem. The "no" example is right on the front page: <a href="https://cuelang.org" rel="nofollow">https://cuelang.org</a>I used it for configuration of a Go program recently and found it pleasant to work with. I hope the language is declared stable soon, because it's a good model.

namelosw大约 4 年前

I prefer JSON over YAML because I spend more time confused and burned by the problems caused by it.I understand that people don't like directly use JSON because it's not very friendly: no comments, no multi-line string, etc.A great alternative IMHO is cson[0]. It's like JSON to JavaScript but for CoffeeScript (though nobody talks about it nowadays). It has indentation-based syntax, comments, and multiline string which usually don't need to escape. The advantage is it's close enough to JSON which is the canonical format that everybody can agree on nowadays. For YAML and TOML there are too many visual part-aways from JSON.Or just create a JSON variant that enables comments and the backtick multiline string from JavaScript.[0] <a href="https://github.com/bevry/cson" rel="nofollow">https://github.com/bevry/cson</a>

korijn大约 4 年前

Edit: downvoters, thanks! I realize this is not an easily agreeable opinion ("let's all chant 'death to YAML!'") but it's really easy to avoid losing money on something like this. Just do proper testing.Aren't you setting yourself up for surprises if you write file formats such as TOML and YAML without reading the documentation, learning and experimenting first? How about unit testing? Or verifying the type in your config parser? Have you tried opening your site in the norway config on your development or testing environment? Or even in production? It all seems very basic and not at all blog post or even HN worthy.I'm going to assume the authors still haven't learned their lesson and are going to experience many more surprises in the future working with plain text file formats.

earthboundkid大约 4 年前

It's fashionable to hate XML because it was used in a lot of places it was a bad fit in the 00s, but at least it's a pretty good document language.YAML though is always a bad fit. If you want machine readable config, use JSON; human readable, use TOML. When does YAML ever fit?

lopespm大约 4 年前

> Christopher Null has a name that is notorious for breaking software code - airlines, banks, every bug caused by a programmer who didn’t know a type from their elbow has hit him.This one made chuckle, and TIL that Null is a real life surname.

bsenftner大约 4 年前

This is such a core issue with a tool like YAML, how the hell did this program get so popular? Are there that many developers willy nilly using tools that fail in critical, silent ways, and the horde of no-nothings follows them?

makkesk8大约 4 年前

We too had this problem, we solved it using the 3 letter country code instead.

DennisP大约 4 年前

Something that used to plague me is that I had database processes importing Excel docs from clients, and if the first few rows in a column were numbers, SQLServer assumed that all the values must be numbers. Then it would run into cells containing other strings, and instead of revising its assumption, it would just import them as null. Since clients often didn't have great data hygiene, it was a problem.I finally solved it by exporting to csv, and using third-party software that handled its own import and did it correctly.

jmartrican大约 4 年前

It seems like we need to treat yaml like json and quote all strings. Would that help resolve these issues? Just trying to figure out a rule I can implement to prevent these issues.

schoen大约 4 年前

Recent related HN discussion: <a href="https://news.ycombinator.com/item?id=26365365" rel="nofollow">https://news.ycombinator.com/item?id=26365365</a>

zomglings大约 4 年前

Have had a similar issue when adding git revisions to YAML documents.The problem is that if a YAML parser sees a string like this:"0123e04"It interprets it as a number: 123 * 10^4Our hacky solution was to prefix the revision hashes like sha-0123e04, but still this was quite annoying.After that experience, I have stopped using YAML for any of my own configuration. Have started preferring putting my configurations in code. And when I don't want that, have found JSON good enough for my purposes.

评论 #26689656 未加载

评论 #26689645 未加载

joshxyz大约 4 年前

This is why i love JSON. It's only string, number, boolean, arrays, objects/dictionaries, unless you write custom serializer and deserializers..

评论 #26681674 未加载

评论 #26689666 未加载

jmull大约 4 年前

> “While the website went down and we were losing money we chased down a number of loose ends until finally finding the root cause.”Hopefully not a real story. If you’re trying out new configurations in production and have no mechanism to rollback problematic changes, you’ve got bigger problems than YAML.To me, though, YAML, including “StrictYAML” doesn’t solve any problems JSON, perhaps w/comments, already solves.

paulintrognon大约 4 年前

I am sometimes annoyed by the fact you have to put double quotes around string properties in JSON. It would be so much lighter to use JS syntax..! Then I read articles like this one. Thank you JSON for not trying to be smart.

gitowiec大约 4 年前

I don't like YAML because when I need to write configuration in it I waste time to remember what is the syntax. I have much better understanding of JSON, because I use it almost on daily basis.

NaturalPhallacy大约 4 年前

This is why implicit typing is an invitation to errors.

lenkite大约 4 年前

Why does YAML accept unquoted strings ? Be Strict. Be Safe.

kleer001大约 4 年前

Ah, tool centric (not centered in the person) time-offset (the ones making the original mistake doesn't see it) paredolia. Good 'el TCTOP...

groundCode大约 4 年前

I've hit this exact same problem loading YAML in Ruby. Luckily caught it before it hit prod, but still, it made me go argh for a while.

mrzool大约 4 年前

Wow, YAML has definitely some pretty quirky edges.

vanshg大约 4 年前

Why not just use Python itself for storing configurations? You can be explicit about the data type and no need to parse anything

teddyh大约 4 年前

This is another good argument against weak types in general. Strong types are better, and explicit is better than implict.

mleonhard大约 4 年前

Don't use ambiguous formats. Use TOML.<a href="https://toml.io/" rel="nofollow">https://toml.io/</a>

lifeisstillgood大约 4 年前

Hang on. The strict model seems off.In the first model enteringGB 9.3gets you a string and a number.But the second gets you two strings?Both are wrong in my opinion."GB" 9.3is the correct approachExplicit beats implicit every time.

pietroppeter大约 4 年前

I like strict yaml but I have used it very little. Anyone who uses it more that can give more feedback?

jgalt212大约 4 年前

another gotcha:2020-03-25 -> datetime.date(2020, 3, 25), not "2020-03-25"

throwaway4good大约 4 年前

Just use json.

knorker大约 4 年前

NO problem.

Meniteos4大约 4 年前

They decided to go against the YAML standard and therefore are no longer a YAML parser. The actual answer to this problem would have been to use a better storage format. Perhaps JSON5? or TOML?

enaaem大约 4 年前

Related xkcd<a href="https://xkcd.com/327/" rel="nofollow">https://xkcd.com/327/</a>

评论 #26683179 未加载

dudeinjapan大约 4 年前

You say Norway, I say Yesway.

bmn__大约 4 年前

The problem is insufficiently analysed by the article author and the commenters in this thread so far. It is very superficial. The recent thread "Can’t use iCloud with “true” as the last name" <a href="https://news.ycombinator.com/item?id=26364993" rel="nofollow">https://news.ycombinator.com/item?id=26364993</a> went deeper. Let me take up its relevant particulars into this thread.The article author hitchdev does not say it outright, but it is heavily implied that the YAML file was edited by hand. This is the immediate cause of the problem. The indirect root of the problem is that the spec authors chose a plain text serialisation format and thus created an affordance <a href="http://enwp.org/Affordance#As_perceived_action_possibilities" rel="nofollow">http://enwp.org/Affordance#As_perceived_action_possibilities</a> to be edited by hand.This turns out the be unsafe/source of bugs because YAML end-users are not capable of correctly applying the serialisation rules considering the edge cases detailed in the article because humans are creatures of habit, applying analogy and common sense, making assumptions and then sometimes go wrong, whereas a piece of software will not make the Norway, Null etc. mistakes. hitchdev even writes that quoting the string is "a fix for sure, but kind of a hack", but that's a grave misunderstanding. Quoting the string here is actually applying the serialisation rules correctly.The tangential at the end of the article about typing is also orthogonal/irrelevant. YAML is strictly/strongly/unambiguously typed, and so is the mentioned variant Strict YAML. The difference is that Strict YAML has serialisation rules that are more amenable to or aligning with the human factors of habit etc. and thus work better in practice.My personal recommendation is to never edit YAML by hand and always use a serialiser. This is less convenient, but safe.In closing, I would like the reader of this comment to make an effort to distinguish between "what is" and "what ought to be" in their head, otherwise the ideas here will be very muddled.

评论 #26679797 未加载

评论 #26679856 未加载

评论 #26679771 未加载

评论 #26679798 未加载