Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Stephen Hansen <me+python@ixokai.io>
Newsgroups: comp.lang.python
Subject: Re: Whittle it on down
Date: Thu, 05 May 2016 00:34:29 -0700
Lines: 49
Message-ID: <mailman.401.1462433672.32212.python-list@python.org>
References: <ngejmj$gc4$1@dont-email.me> <572ae25f$0$2821$c3e8da3$76491128@news.astraweb.com> <1462430766.25079.598726825.1B90C7A1@webmail.messagingengine.com> <mailman.398.1462430769.32212.python-list@python.org> <572af09d$0$1508$c3e8da3$5496439d@news.astraweb.com> <1462433669.32454.598751585.63AF2D12@webmail.messagingengine.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <572af09d$0$1508$c3e8da3$5496439d@news.astraweb.com>
Precedence: list
Xref: csiph.com comp.lang.python:108165

On Thu, May 5, 2016, at 12:04 AM, Steven D'Aprano wrote:
> On Thursday 05 May 2016 16:46, Stephen Hansen wrote:
> > > On Wed, May 4, 2016, at 11:04 PM, Steven D'Aprano wrote:
> >> Start by writing a function or a regex that will distinguish strings t=
hat
> >> match your conditions from those that don't. A regex might be faster, =
but
> >> here's a function version.
> >> ... snip ...
> >=20
> > Yikes. I'm all for the idea that one shouldn't go to regex when Python's
> > powerful string type can answer the problem more clearly, but this seems
> > to go out of its way to do otherwise.
> >=20
> > I don't even care about faster: Its overly complicated. Sometimes a
> > regular expression really is the clearest way to solve a problem.
>=20
> You're probably right, but I find it easier to reason about matching in=20
> Python rather than the overly terse, cryptic regular expression mini-
> language.
>=20
> I haven't tested my function version, but I'm 95% sure that it is
> correct.=20
> It trickiest part of it is the logic about splitting around ampersands.
> And=20
> I'll cheerfully admit that it isn't easy to extend to (say) "ampersand,
> or=20
> at signs". But your regex solution:
>=20
> r"^[A-Z\s&]+$"
>=20
> is much smaller and more compact, but *wrong*. For instance, your regex=20
> wrongly accepts both "&&&&&" and "      " as valid strings, and wrongly=20
> rejects "=CE=94=CE=A3=CE=98=CE=9B". Your Greek customers will be sad...

Meh. You have a pedantic definition of wrong. Given the inputs, it
produced right output. Very often that's enough. Perfect is the enemy of
good, it's said.=20

There's no situation where "&&&&&" and "     " will exist in the given
dataset, and recognizing that is important. You don't have to account
for every bit of nonsense.=20

If the OP needs a unicode-aware solution that redefines "A-Z" as perhaps
"\w" with an isupper call. Its still far simpler then you're suggesting.

--=20
Stephen Hansen
  m e @ i x o k a i . i o