Python not that wierd

[Alex Martelli]

"Steve Lamb" <grey at despair.rpglink.com> wrote in message
news:slrn8oe1qf.tml.grey at teleute.rpglink.com...
>     OK, work finally let me go long enough for me to apply the lessons
that
> were plowed into my head by this newsgroup over the discussion of "Perl is
> Worse".  First off, I want to thank everyone for the conversation.  I did

It's been a mutual pleasure.

>   def parse_diecode(self):
>     diematch =
re.match(r'^(?:(\d{1,2})|)d(\d{1,3})(?:([\+\-]\d{1,2})|)$',self.diecode,re.I
)

I think that, to parse '0 or more digits', a \d* might perhaps be better.
You don't normally need the '^' when you're using re.match (re.search is
different, in multi line mode).

I.e., I suspect a more efficacious R.E. for your match might be:
    if not self.compiled_re:
        self.compiled_re = re.compile(r'(\d*)[dD](\d*)([-+]\d+)?$')
    diematch = re.match(self.compiled_re,self.diecode)
without the re.I (and expressed more concisely, solely for purposes
of readability, e.g. '[-+]' versus '[\+\-]', the non-grouping parens,
etc).  Not a huge difference, of course.  The explicit re.compile
(enabled by the fact that this is in a class so we can add stuff to
it:-) is more likely to matter in terms of performance (it might as
well be a class-member, just use Klaz.compiled_re if your class is
named Klaz -- big further gain if many instances of the class are
used; and I'd set it in the class-statement, to avoid the if here).

>     if diematch:
>       self.number = int(diematch.group(1) or self.number)
>       self.sides = int(diematch.group(2) or self.sides)
>       self.modifier = int(diematch.group(3) or self.modifier)
>     else:
>       raise BadDieCode

This part seems quite OK, as do the following remarks.


>     Anyway, thanks again for the discussion to all.  I might post being
grumpy
> about something I stumbled across but hopefully it won't be anything that
> lengthy.

You're definitely welcome.  And don't worry about your Perl roots
showing -- so do mine (finetuning RE's is _not_ the average
Pythonista's hobby:-) as do, also, mine in C++ (reliance on
destructors/reluctance about exceptions), SQL (penchant for tables
and subsetting thereof), etc.

Such roots in other languages are all to the good, if they're used to
'flavour' one's Python with not-too-inappropriate patterns and idioms
rather than end up interfering with the slow maturation of one's style
towards one of the several that Python supports so well (TMTOWTDI in
Python too, we just don't brag about it:-).


Alex