[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ddlm-group] Eliding in triple-quoted strings: Proposals C andD. .. .. .

Perhaps I was unclear as to why I am not satisfied with Ralf's
proposal.  I object because:

(1) It defines a large number of unnecessary escapes (I listed 10),
some of which are not allowed CIF characters;
(2) It defines both raw and unicode strings, which is excessive for
our requirements
(3) The sequences <backslash><quote> and <backslash><apostrophe> are
ambiguous in raw strings: are they elide sequences, or are they
intended for the string consumer?

Perhaps the supporters of the Python approach would like to explain
why these objections are immaterial, especially given that there are
already about 6 significantly simpler proposals on the table to which
these objections do not apply.

I do not perceive any advantage in adopting the Python approach
wholesale.  For example, Simon's minimalist suggestion would be much
easier to implement, interpret and document than the complete Python
scheme - I estimate about 15 minutes of coding time.

On Sat, Jan 8, 2011 at 9:32 AM, Bollinger, John C
<John.Bollinger@stjude.org> wrote:
> On Friday, January 07, 2011 3:14 PM, Herbert J. Bernstein wrote:
>>We seem not to be communicating effectively.
>>What I am asking for is an _existing_, supported treble quote specification
>>from an _existing_ language with _existing_ documentation and
>>_existing_ software as an alternative to the Python specification,
>>documentation and software to which we all have access, that is being
>>proposed as an alternative
>>to what Ralf has proposed.
> Thank you for that clarification.  You are right, I didn't understand what you were asking for.
> I hope this will likewise clarify my position: I reject the premise that the system we choose must meet those criteria, and I oppose adopting the full Python syntax and semantics.
>>The Python specification is available at
>>with the lexical analysis at
> Thanks, though that is exactly what I was looking at already.  It leaves several details unclear, some of which I discussed in previous messages.  Hence, I consider it slightly short of a *full* specification.  It does, however, provide my grounds for opposing adoption of that scheme for CIF.
>>The complete source code and binaries are available at:
> Unless you propose to append a particular set of Python sources to the CIF specification as a reference, I have no interest in perusing the source code to seek answers to such questions of detail as I have.  Furthermore, I would oppose adding such an appendix on the grounds that it would be exceedingly difficult to use to resolve questions such as mine.
> I am likewise unwilling to rely on the behavior the python binary that happens to be installed on my computer to answer them.  If the correct behavior is not documented independent of the program then there is no particular reason to trust that it won't change in future versions, or that any particular implementation is correct or bug-free.
> 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

T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
ddlm-group mailing list

Reply to: [list | sender only]