[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] Searching for a compromise on eliding. .
- To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] Searching for a compromise on eliding. .
- From: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
- Date: Fri, 25 Feb 2011 13:25:29 -0500 (EST)
- In-Reply-To: <8F77913624F7524AACD2A92EAF3BFA54168ECD35BB@SJMEMXMBS11.stjude.sjcrh.local>
- References: <AANLkTi=bEDjCpJgyuB07q1FBFZjA_jbG=4jgLsXEvw4g@mail.gmail.com><324958.57741.qm@web87003.mail.ird.yahoo.com><alpine.BSF.2.00.1102250746270.85678@epsilon.pair.com><alpine.BSF.2.00.1102251125010.85678@epsilon.pair.com><8F77913624F7524AACD2A92EAF3BFA54168ECD35BB@SJMEMXMBS11.stjude.sjcrh.local>
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]
- Follow-Ups:
- Re: [ddlm-group] Searching for a compromise on eliding. .. . (Bollinger, John C)
- References:
- [ddlm-group] Searching for a compromise on eliding (James Hester)
- Re: [ddlm-group] Searching for a compromise on eliding (SIMON WESTRIP)
- Re: [ddlm-group] Searching for a compromise on eliding (Herbert J. Bernstein)
- Re: [ddlm-group] Searching for a compromise on eliding (Herbert J. Bernstein)
- Re: [ddlm-group] Searching for a compromise on eliding. . (Bollinger, John C)
- Prev by Date: Re: [ddlm-group] Searching for a compromise on eliding. .
- Next by Date: Re: [ddlm-group] Searching for a compromise on eliding. .. .
- Prev by thread: Re: [ddlm-group] Searching for a compromise on eliding. .
- Next by thread: Re: [ddlm-group] Searching for a compromise on eliding. .. .
- Index(es):