[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] Technical issues with Proposal P. .
- To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] Technical issues with Proposal P. .
- From: "Bollinger, John C" <John.Bollinger@STJUDE.ORG>
- Date: Tue, 22 Feb 2011 10:32:34 -0600
- Accept-Language: en-US
- acceptlanguage: en-US
- In-Reply-To: <alpine.BSF.2.00.1102220845481.84613@epsilon.pair.com>
- References: <AANLkTi=kadbHikjabDyioDOw=L_pthGORgi6w2b45yX6@mail.gmail.com><alpine.BSF.2.00.1102220644270.84613@epsilon.pair.com><417719.45449.qm@web87006.mail.ird.yahoo.com><alpine.BSF.2.00.1102220741480.84613@epsilon.pair.com><301639.7573.qm@web87001.mail.ird.yahoo.com><alpine.BSF.2.00.1102220845481.84613@epsilon.pair.com>
On Tuesday, February 22, 2011 7:51 AM, Herbert J. Bernstein wrote: > From the point of view of writing a pure "CIF2" application that is not aware of the whitespace, particular quote marks, comments, etc, those two string are identical. > > From the point of view of a more general CIF API, in which comments, magic numbers, and partiular quote marks, those two string are different in precisely the same way that the string 'ABC' and "ABC" are different, and 13.4 and >1.34e1 are different. > > This is _not_ an ambiguity. It is a matter of whether we are looking for the information in a file or looking for the representations of the data in the file. Herbert is right about this. It doesn't matter which syntactic variant was used to express a data value in an input CIF. Once the value is parsed, the result is the value. In particular, under proposal P, """C\"""" expresses a different value than does r"""C\"""", whereas """C\\\"""" and r"""C\"""" express the same value. The fact that the character sequence C" cannot be expressed via Python raw string format is irrelevant. An application receiving these values does not need to know and should not care in which form the value was expressed in a CIF, if indeed it was ever expressed in CIF format at all. However, although there is no technical issue here, the fact that an experienced and successful Python and CIF practitioner such as James raised the question is illuminating. It demonstrates that the complexity of the syntax and semantics provided by proposal P would be likely to be a source of confusion for developers and users both. Regards, John -- John C. Bollinger, Ph.D. Department of Structural Biology St. Jude Children's Research Hospital Email Disclaimer: www.stjude.org/emaildisclaimer _______________________________________________ ddlm-group mailing list ddlm-group@iucr.org http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- Follow-Ups:
- Re: [ddlm-group] Technical issues with Proposal P. . (James Hester)
- References:
- [ddlm-group] Technical issues with Proposal P (James Hester)
- Re: [ddlm-group] Technical issues with Proposal P (Herbert J. Bernstein)
- Re: [ddlm-group] Technical issues with Proposal P (SIMON WESTRIP)
- Re: [ddlm-group] Technical issues with Proposal P (Herbert J. Bernstein)
- Re: [ddlm-group] Technical issues with Proposal P (SIMON WESTRIP)
- Re: [ddlm-group] Technical issues with Proposal P (Herbert J. Bernstein)
- Prev by Date: Re: [ddlm-group] Vote on moving elide discussion to COMCIFS. .. .... .
- Next by Date: Re: [ddlm-group] Vote on moving elide discussion to COMCIFS. .. .... .
- Prev by thread: Re: [ddlm-group] Technical issues with Proposal P. .
- Next by thread: Re: [ddlm-group] Technical issues with Proposal P. .
- Index(es):