From: Damian C. <dam...@gm...> - 2004-09-08 21:42:20
|
On Wed, 8 Sep 2004 14:36:19 -0400, Clark C. Evans <cc...@cl...> wrote: > > However, your other examples where you hint at Python's problem with { > 1: 'integer', 1.0: 'float' } is an exceptional case, and it is > implementation specific. This is a situation where the Python mapping > and its native types fail to behave how the YAML Model specifies. Assuming that the YAML processor assigns different tags to them. If the implicitly interpolated tag for 1.0 and 1 is !!number (let's say) and they both had the same canonical form, then the YAML processor would recognize them as equal in the same way 1.0 = 1.00 and 0x2A = 052. Some programming languages' equivalent of a map compare using object-identity, others (such as Python) by value equality. I think that coming up with a form of words that lets YAML define 'uniqueness' for map keys that is completely bullet-proof in the face of these subtle differences between programming languages will not be possible. If we try to insist on one behaviour or another, we force implementers to abandon the native types in favour of YAML-specific equivalents, which would surely be inefficient and inconvenient. Maybe the cases that might cause conflicts (such as the 1 != 1.0 example) will have to be left deliberately ambiguous. Python dictionaries will silently overwrite one with the other; dot-Net's Hashtable will throw an exception if you Add a duplicate. And your processor might be configured to use completely different types anyway. On the other hand, cases where this causes divergent behaviour ought to be rare. For example, I am finding it difficult to imagine a real need to have separate mappings for numbers depending on whether I included a decimal point..! -- Damian |