Discussion List Archives

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

Re: [ddlm-group] Searching for a compromise on eliding. .

Allow me to clarify the choices involved among the 2.7 and 3 treble
uoted strings.  The Python 3 bytes strings (b""" or B""" or b''' or B''')
are essentially the Python 2.7 treble quoted strings, and are ASCII
oriented.  The Python 2.7 unicode strings (u""" or U""" or u''' or U''')
are essentially the Python 3 treble quoted strings) and are unicode
oriented.  The difference arises because 2.7 is based on 7-bit ASCII
and 3 is UTF8 oriented.  Thus 2.7 is a better design fit for compatibility
with CIF1.1 data, while 3 is a better design for compatibility
with CIF2 data.  The transition between CIF1.1 and CIF2 will go more
smoorthly with both ASCII and Unicode supported in the string context,
i.e. with proposal P using both the ASCII-oriented treble quoted strings
_and_ the Unicode oriented unicode treble-quoted strings from 2.7 or
the functionally equivalent ASCII-oriented bytes trebble quoted strings
_and_ Unicode oriented treble-quoted string from 3.  As I said, I am
willing to accept proposal P-prime to achieve consensus if John W. and
Ralf are, but I certainly hope we will join the Python community
before too long in providing full support for this important transition.

I don't see what is bad about using LGPL'd libraries.  That allows you
to kick start your application fast using other people's code and when
you have a version with better performance or features to swap in you own 
improved version.  It is a powerful and effective software development
model.  As long s you stick to operating-system level libraries (and mine
are) there are absolutely no negative license implications for proprietary
software development, witness the use of CBFlib in proprietary 
applications.

Regards,
    Herbert

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

                  +1-631-244-3035
                  yaya@dowling.edu
=====================================================

On Fri, 25 Feb 2011, Bollinger, John C wrote:

>
> On Friday, February 25, 2011 10:39 AM, Herbert J. Bernstein wrote:
>
>> I just checked the Uncode 5.2.0 names "database" that Python 2.7 uses.
>> I has 21829 names.  There is a well-documented Python reference implementation of an API for translation at:
>>
>> http://docs.python.org/library/unicodedata.html
>>
>> If nobody has done it yet, at first glance it does not look too 
>> difficult to make matching LGPL'd C/C++/Java APIs.  I am not saying it 
>> is a trivial task, but is does look doable as part of making a full 
>> UTF8 support package for CIF2.
>>
>> Would having that make a Python 3 version of proposal P-prime 
>> acceptable?
>
> No.
>
> In no way do I object to having support libraries available for CIF2, 
> but as far as support for \N{name} goes, providing and promoting such 
> libraries would just be a mitigation strategy for a poor design 
> decision.  Developers would then have the choice of being tied to 
> specific third-party libraries (with their particular licenses, 
> performance characteristics, and bugs), or facing all the 
> implementation, testing, and compatibility problems that the libraries 
> are intended to avoid.  It would be far better to omit complex, unneeded 
> features in the first place.
>
> As long as we're discussing the details of this Python feature, consider 
> that the \N{name} elide is problematic not only from an implementation 
> and runtime perspective, but also from a stability and compatibility 
> perspective.  Python 2.6 relies on UCD 5.1.0, Python 2.7 relies on UCD 
> 5.2.0, Python 3.2 relies on UCD 6.0.0, etc..  We can of course choose a 
> Python version and along with it get a particular UCD version.  We would 
> need to do so to make CIF well-defined.  However, that would then 
> provide full compatibility only with a specific major.minor version of 
> Python.
>
> I also prefer leaving out the \u and \U elides if we must adhere 
> precisely to Python behavior, for in those cases the Python 
> implementation does not follow its laudible, documented practice of 
> ignoring escape sequences that it doesn't recognize.  Or is that fixed 
> in Python 3?  If so, then what a confusing difference that is!
>
> Overall, I don't much care for P', but I prefer it as-is over both P and 
> P'{Python3}.  I have elsewhere described other alternatives that I like 
> better.
>
>
> 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
>
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
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