Discussion List Archives

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

Re: [ddlm-group] Simon's elide proposal

On Thursday, January 13, 2011 3:28 PM, Herbert J. Bernstein wrote:
>   I do, at present, prefer 2.7 to 3.  That seems to be true
>of most programmers, but at some point we all will
>face the question of making a transition to 3.  2.7 is
>not restricted to ASCII characters.

Quite right, my mistake.  The 2.7.1 docs specify that "program text" is restricted to ASCII, but that string literals and comments may be encoded in other character sets.

> [...] However,
> for the reasons discussed earlier, I think we need
> to revisit _all_ the ealier decisions, so I am willing
> to consider making the default encoding for a CIF2
> be pure ASCII, if that is what John B. is proposing.

No, I'm not proposing that at all.  I am raising technical objections to adopting the full Python syntax.  The one about an ASCII restriction turns out to be unfounded.

Also, thank you for bringing Python 3 changes to my attention.  If we did adopt Python syntax, then I think Python 3.1 provides a better model for CIF's purposes than does Python 2.7.

> [...] and the b prefix was dropped
> a long time ago

The Python 3.1.3 documentation disagrees with you on that point, and the Python 2.7.1 docs describe [bB] as a forward compatibility feature, not an obsolete one.  However, Python 3 seems to use it to leverage the string literal semantics for expressing literals of a new "bytes" type.  It looks like that's some kind of byte sequence (maybe just a different name for the old non-Unicode string type).  Inasmuch as that does not match up with anything in CIF, perhaps you would agree that it should be omitted from the features proposed to be adopted from Python.


>The real problem is that the entire computing world
>is in a major transition, hopefully towards better
>agreement on something sensible in handling strings
>of characters.  Python seems to be in a reasonable
>position with respect to the leading edge of that
>transition, and I suggest we carefully review and
>consider what they are doing, and make use, where
>appropriate, of their efforts.  I think we will
>need to try to track somebody, and Python looks
>like a possibility.

I am entirely in favor of reviewing and considering what Python is doing, and indeed, I have devoted considerable effort to exactly that in the past few days.  I have previously indicated which fruits of their efforts I think may be appropriate for us to use, and which not.

Whatever we end up doing, I think we should avoid any need or expectation of "tracking" anybody, because frequent specification changes would poorly serve CIFs core application as an archive format.


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

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.