Discussion List Archives

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

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

Dear Colleagues,

   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.  3 is not restricted
to ASCII characters.  The main point here is that, because
3 has a default encoding of UTF-8, it always allows
the restriction to be relaxed, while 2.7, when you don't
specify an encoding for the file, defaults to a pure
ASCII encoding, and therefore does not allow you to
go beyond the ASCII character set.  In the earlier
decisions we adopted the approach of defaulting to
UTF-8 so the restriction would be relaxed.  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.

The reason the U and u prefixes are dropped in 3
is precisely because the  \u and \U escapes are
allowed in all string literals inasmuch as the
encoding is UTF-8, and the b prefix was dropped
a long time ago, leaving only the r""" and """
versions that Ralf proposed.

On the question of the mutability of the Python spec,
I agree, it is very, very mutable.  I know because I
have to teach it to students, and we get burned
all the time by the differences among 2.4, 2.6, 2.7
and 3.  I am not thrilled about that, so, yes,
we need to pick one of them (I prefer 2.7), but,
in the spirit of revisting all earier decisions,
I would certainly also be willing to consider other
possibilities.  However, I would hope that whatever
is proposed is clean, reasonably stable, well
supported code, with source and examples available,
much as both Python 2.7 and Python 3 are.

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.



=====================================================
  Herbert J. Bernstein, Professor of Computer Science
    Dowling College, Kramer Science Center, KSC 121
         Idle Hour Blvd, Oakdale, NY, 11769

                  +1-631-244-3035
                  [email protected]
=====================================================

On Thu, 13 Jan 2011, Bollinger, John C wrote:

> On Thursday, January 13, 2011 12:42 PM, Herbert J. Bernstein wrote:
> [I wrote:]
>>> It should also be noted that Python source code, including its string
>>> literals, is restricted to being expressed in the characters of the
>>> 7-bit ASCII character set (though they need not necessarily be encoded
>>> according to US-ASCII).  Unconditional, bidirectional CIF/Python string
>>> compatibility would require that we apply the same restriction to CIF2
>>> triple-quoted strings.  I would oppose that.
>>
>> That started to change in Python 2.5 which allowed explicit encoding
>> declarations, and by Python 3 has vanished even without an
>> encoding declaration.  The Python 3 spec is:
>>
>> "Python reads program text as Unicode code points; the encoding
>> ... defaults to UTF8"
>
> Well and good, then.  You previously pointed us to Python 2.7.1 for 
> documentation of the Python semantics proposed for CIF, but Python 3 
> looks like a better fit.  Python 3 no longer provides the [uU] string 
> prefix, however, so that's different from what Ralf proposed and from 
> what I thought we had been discussing.  That begs the question, *which 
> version of Python* is proposed to provide its string syntax to CIF?
>
> This furthermore demonstrates one of the strategic drawbacks of adopting 
> Python semantics: Python is not static.  We could make CIF semantics 
> well defined by tying them to a specific Python version, perhaps v3.1.3, 
> but does that retain its purported advantages as Python semantics evolve 
> in 3.2, 3.5, 4.0, etc.?  Perhaps it does, but that's not obvious to me.
>
>
> 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 protected]
> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>
_______________________________________________
ddlm-group mailing list
[email protected]
http://scripts.iucr.org/mailman/listinfo/ddlm-group

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.

Useful links