[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: "Bollinger, John C" <John.Bollinger@STJUDE.ORG>
- Date: Fri, 25 Feb 2011 11:34:56 -0600
- Accept-Language: en-US
- acceptlanguage: en-US
- In-Reply-To: <alpine.BSF.2.00.1102251125010.85678@epsilon.pair.com>
- 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>
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
Reply to: [list | sender only]
- Follow-Ups:
- Re: [ddlm-group] Searching for a compromise on eliding. . (Herbert J. Bernstein)
- 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)
- 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):