Path: csiph.com!usenet.pasdenom.info!aioe.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Newsgroups: comp.lang.python
Date: Thu, 20 Dec 2012 11:42:03 -0800 (PST)
In-Reply-To: <mailman.1074.1355952227.29569.python-list@python.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=178.198.163.217; posting-account=ung4FAoAAAC46zhHJ0Nsnuox7M5gDvs_
References: <2adb4a25-8ea3-441f-b8c0-ee6c87e4b19f@googlegroups.com> <mailman.1051.1355928746.29569.python-list@python.org> <890ee58d-e93e-42ac-b17e-59b05c6ecacb@googlegroups.com> <mailman.1074.1355952227.29569.python-list@python.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Subject: Re: Py 3.3, unicode / upper()
From: wxjmfauth@gmail.com
To: comp.lang.python@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Python <python-list@python.org>
Precedence: list
Message-ID: <mailman.1114.1356038437.29569.python-list@python.org>
Lines: 112
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:35231

Le mercredi 19 d=E9cembre 2012 22:23:15 UTC+1, Ian a =E9crit=A0:
> On Wed, Dec 19, 2012 at 1:55 PM,  <wxjmfauth@gmail.com> wrote:
>=20
> > Yes, it is correct (or can be considered as correct).
>=20
> > I do not wish to discuss the typographical problematic
>=20
> > of "Das Grosse Eszett". The web is full of pages on the
>=20
> > subject. However, I never succeeded to find an "official
>=20
> > position" from Unicode. The best information I found seem
>=20
> > to indicate (to converge), U+1E9E is now the "supported"
>=20
> > uppercase form of U+00DF. (see DIN).
>=20
>=20
>=20
> Is this link not official?
>=20
>=20
>=20
> http://unicode.org/cldr/utility/character.jsp?a=3D00DF
>=20
>=20
>=20
> That defines a full uppercase mapping to SS and a simple uppercase
>=20
> mapping to U+00DF itself, not U+1E9E.  My understanding of the simple
>=20
> mapping is that it is not allowed to map to multiple characters,
>=20
> whereas the full mapping is so allowed.
>=20
>=20
>=20
> > What is bothering me, is more the implementation. The Unicode
>=20
> > documentation says roughly this: if something can not be
>=20
> > honoured, there is no harm, but do not implement a workaroud.
>=20
> > In that case, I'm not sure Python is doing the best.
>=20
>=20
>=20
> But this behavior is per the specification, not a workaround.  I think
>=20
> the worst thing we could do in this regard would be to start diverging
>=20
> from the specification because we think we know better than the
>=20
> Unicode Consortium.
>=20
>=20
>=20
>=20
>=20
> > If "wrong", this can be considered as programmatically correct
>=20
> > or logically acceptable (Py3.2)
>=20
> >
>=20
> >>>> 'Stra=DFe'.upper().lower().capitalize() =3D=3D 'Stra=DFe'
>=20
> > True
>=20
> >
>=20
> > while this will *always* be problematic (Py3.3)
>=20
> >
>=20
> >>>> 'Stra=DFe'.upper().lower().capitalize() =3D=3D 'Stra=DFe'
>=20
> > False
>=20
>=20
>=20
> On the other hand (Py3.2):
>=20
>=20
>=20
> >>> 'Stra=DFe'.upper().isupper()
>=20
> False
>=20
>=20
>=20
> vs. Py3.3:
>=20
>=20
>=20
> >>> 'Stra=DFe'.upper().isupper()
>=20
> True
>=20
>=20
>=20
> There is probably no one clearly correct way to handle the problem,
>=20
> but personally this contradiction bothers me more than the example
>=20
> that you posted.

----

At least, we agree on the problematic of this very special case.

jmf