[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] Eliding in triple-quoted strings: Proposals C andD. .. .. .
- To: Group finalising DDLm and associated dictionaries <email@example.com>
- Subject: Re: [ddlm-group] Eliding in triple-quoted strings: Proposals C andD. .. .. .
- From: "Herbert J. Bernstein" <firstname.lastname@example.org>
- Date: Sat, 8 Jan 2011 08:16:42 -0500 (EST)
- In-Reply-To: <AANLkTimWDSp1zOTLTapWErbiBYkkdUaSrUKj0Bemail@example.com>
- References: <AANLkTimWpd1kMZDGcTprEhcJw+uQE4_JtgJ4SbtMPVXt@mail.gmail.com><firstname.lastname@example.org><alpine.BSF.email@example.com><4D271B81.firstname.lastname@example.org><email@example.com><firstname.lastname@example.org><8F77913624F7524AACD2A92EAF3BFA54166D7D1E9B@SJMEMXMBS11.stjude.sjcrh.local><AANLkTimWDSp1zOTLTapWErbiBYkkdUaSrUKj0Bemail@example.com>
First to the important part -- if James can do the complete implementation of the treble quote parsing for CIF2 in 15 minutes, then I respectfully request that he do so, and make the code available to the rest of us as a template for all to follow and understand. Second, what James sees as negative issues in 1 and 2, I see as postive ones, especially for support of imgCIF, but in no case do I understand what harm is done to any user or software developer by allowing the greater generality of the python treble quote with the raw string and the unicode string. The question seems to come down to how early in the parse logic we will be required by the CIF2 standard to issue warnings or error messages about "illegal" data values. Are we to have a mandatory requirement for flsgging this at the lexical level? Why? Some of us are going to have to allow for the suppression on those errors and warnings to be able to process our data (again imgCIF), but even for those who do not have such a need, if the treble quote logic returns a string that contains something "improper" (e.g. some of the disallowed uniocde values) they can still report it. How is it different from someone who is working with a unicode-aware editor who produces a single-quoted version of one of those characters? It is unfortunate that we are having this discussion without Ralf. As I feared, we now seem headed towards a decision by this body that will require a full re-opened discussion at the COMCIFS level and and will further delay CIF2, probably for another 3 years. At least we should be able to take a shot at what we really need, a face-to-face meeting, in Madrid. It is a shame. Ralf really is right. ===================================================== Herbert J. Bernstein, Professor of Computer Science Dowling College, Kramer Science Center, KSC 121 Idle Hour Blvd, Oakdale, NY, 11769 +1-631-244-3035 firstname.lastname@example.org ===================================================== On Sat, 8 Jan 2011, James Hester wrote: > 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 >>> >>> http://docs.python.org/reference/index.html >>> >>> with the lexical analysis at >>> >>> http://docs.python.org/reference/lexical_analysis.html >> >> 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 >> email@example.com >> 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 > firstname.lastname@example.org > http://scripts.iucr.org/mailman/listinfo/ddlm-group >
_______________________________________________ ddlm-group mailing list email@example.com http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- [ddlm-group] Eliding in triple-quoted strings: Proposals C and D (James Hester)
- Re: [ddlm-group] Eliding in triple-quoted strings: Proposals C and D (SIMON WESTRIP)
- Re: [ddlm-group] Eliding in triple-quoted strings: Proposals C and D (Herbert J. Bernstein)
- Re: [ddlm-group] Eliding in triple-quoted strings: Proposals C and D (John Westbrook)
- Re: [ddlm-group] Eliding in triple-quoted strings: Proposals C andD. .. .. . (Bollinger, John C)
- Re: [ddlm-group] Eliding in triple-quoted strings: Proposals C andD. .. .. . (James Hester)
- Prev by Date: Re: [ddlm-group] Eliding in triple-quoted strings: Proposals C andD. .. .. .
- Next by Date: Re: [ddlm-group] Eliding in triple-quoted strings: Proposals C andD. .. .. .
- Prev by thread: Re: [ddlm-group] Eliding in triple-quoted strings: Proposals C andD. .. .. .
- Next by thread: Re: [ddlm-group] Eliding in triple-quoted strings: Proposals C andD. .. .. .. .