You are absolutely correct,
>>> import yaml
>>> yaml.load("zipcode: 06511")
is just not intuitive. The problem is in two places: (a) the preview
example which shows octal example, and (b) the integer type library.
There are two potential interpretations (fixes) for leading 0's:
- 06511 is loaded as the integer 6511
- 06511 is loaded as the string value '06511'
The first option (as an integer) is problematic in two ways: (a) it
doesn't round-trip the leading 0, and (b) if you happen to be relying
upon the current usage, it wouldn't be an error... you'd just get a
The second one seems the best. People serializing
integers shouldn't be using leading 0's anyway, and those using octal
notation can add a custom representer (for this very rare usage).
Treating it as a plain text value is simple and conservative.
I recommend the following changes (subject to Ingy/Oren's approval):
- Update the preview to get rid of the octal example, and also to
use a zip code with leading 0's in the purchase order.
- Update the integer type library to not use octal, hence the
regex would be amended to not match codes like 06511.
Thank you for pointing this out.
On Mon, Sep 18, 2006 at 09:05:26AM -0400, Chris Ross wrote:
| On Sep 17, 2006, at 6:58 PM, Andreas Rumpf wrote:
| >YAML is about writing *human-readable* data. No human being thinks
| >of eight if he writes 010. In math leading zeros have no meaning.
| >Programmers may think otherwise (because of the sucking C
| >programming language). In order to not confuse anybody it may be
| >adviseable to forbit leading zeros in integers. As an alternative
| >spelling for octal numbers I suggest: 0c10 (c instead of o, because
| >0o10 looks to strange). Note that this may affect octal numbers in
| >quoted literals as well.
| >So please consider this in the next version of the specification.
| I'm not sure, but I don't know that this is actually coded in the
| specification. I just scanned through the specification, and while
| it does presume that an integer in the form "010" would be octal (8),
| I don't think it actually states that it must be interpreted that
| way. Specifically, section 2.4 says:
| In YAML, untagged nodes are given an type depending on the application.
In pratice, PyYAML does do implicit typing, and I don't think you
can even diable it.
| That and other comments lead me to believe that the specification
| doesn't describe how integers (or any other scalar type) should be
| interpreted by the parser, or the application.
| This may be an issue of the Python YAML module more than it is an
| issue of the specification. Tho, of course, the specification should
| make more clear that this is up to the application to decide if
| something as significant as Python's YAML module was to be changed in
| this way...
| Thanks. I'm fairly new to YAML, and these are just my thoughts.
| Please constructively criticize if I've gotten something confused. :-)
| - Chris