Re: [Yaml-core] Identity rules

[Clark C . E. <cc...@cl...>]

On Tue, Dec 18, 2001 at 11:19:48AM -0800, Brian Quinlan wrote:
| Clark wrote:
| > Perhaps you are right; although I 'd rather consider
| > the Python identity function to be not compliant since
| > it does not distinguish between the first "1" that I
| > type in and subsequent times that I type in "1".  To me,
| > these are not identical, but they are equal.
| 
| But the YAML definition is not that flexible:
| 
| "In most programming languages, there are two manners in which variables
| can be equivalent. The first is by reference, where the two variables
| refer to the same memory address. We call this equivalence relation
| identity."

Right.  This really is the expressed intent.  I guess we need
to find a slightly better wording that gives the implementation
some flexibility with regard to this point, no?

| My point is that serializing built-in Python immutable types according
| to identity is going to lead to some odd behavior because Python has no
| reason to provide any clear semantics for those types.

Right.

| So imagine that I serialize:
| >>> a = (1,2)
| >>> b = copy.copy(a)
| >>> serialize([a,b])
| 
| -
|  - &tuple
|   - 1
|   - 2
|  - *tuple

This behavior sounds good; it'd be impossible to do
it any other way, no?  Python often optimizes 
immutables so that they are identical when the language 
would only imply that they are equivalent.  Nothing 
we can do about this.   With Python land it will be
consistent... 

On Tue, Dec 18, 2001 at 09:13:09AM -0800, Brian Ingerson wrote:
| > I'd rather not have the serialization record Python's
| > immutable optimizations for strings and integers.
| > This would sacrifice readability.  As you said, Python's
| > identity operator isn't very useful in certain cases.
|
| +1
|
| I don't check the identity of simple leaf nodes. I've always thought
| that was a bad idea. Neither YAML nor any other serialization
| language can maintain the absolute purity of an internal data 
| structure (especially across platforms). Sarathy's Data::Dumper 
| has a Purity level option. But it's of limited value. Gisle's 
| Data::Dump tries to be more pure in general, but the
| output reads like hell.
|
| Here's a classic Data::Dumper bungle:
|
| ysh > --- !seq
| yaml> 8: eight
| yaml> ...
| $VAR1 = [
|           undef,
|           ${\$VAR1->[0]},
|           ${\$VAR1->[0]},
|           ${\$VAR1->[0]},
|           ${\$VAR1->[0]},
|           ${\$VAR1->[0]},
|           ${\$VAR1->[0]},
|           ${\$VAR1->[0]},
|           'eight'
|         ];
| ysh >
|
| Most of the Perl people I've talked to, hate that.

This is the same thing that would occur with Python's None; which 
should probably get mapped to our null value (~)    I guess we'll 
just have to shrug our shoulders on this one, any idea as to how 
to fix up the spec so that it doesn't have behavior similar to
the (god-awful) above behavior?

Best,

Clark