Python not that wierd

[Alex Martelli]

"Steve Lamb" <grey at despair.rpglink.com> wrote in message
news:slrn8oeobo.5bh.grey at teleute.rpglink.com...
> On Tue, 1 Aug 2000 23:49:17 +0200, Alex Martelli <alex at magenta.com> wrote:
> >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).
>
>     Perl head in me, I'd rather have it explicitely stated.  Whoops, and
that

Actually, the 'explicitness' is supposed to be a Python virtue:-).  But here
I
see 'redundancy' -- stating the same thing twice: .match begins from the
beginning anyway, so restating that with a ^ seems a rendudancy to me.
And one of _my_ core values is 'do things once and once only'...:-).

> should be a search.

You do want to match the RE even when not at the beginning of the
string?  Then the ^ is wrong.  It's only useful when you want to match
a *start-of-line* in multiline mode (but you're not running your RE in
multiline mode, it seems to me?).

> Also, the whole reason I have the {1,2} etc. in the regex
> is to limit the the number of dice rolled.  I know that I could do that in
> logic but, again, perl roots, putting nice logic into the regex.

OK, but the {1,2} (or, since it can be 0, should actually be {0,2}) can
only limit the *number of DIGITS* in the number-of-dice-to-roll.  How
comes all limits fall at  99 or 999?  Seems a strange coincidence to
me.  but OK, whatever.


> >    if not self.compiled_re:
> >        self.compiled_re = re.compile(r'(\d*)[dD](\d*)([-+]\d+)?$')
> >    diematch = re.match(self.compiled_re,self.diecode)
>
>     Hmmm, good idea, hadn't thought of compiling the re in that manner.
Makes
> sense, though.

Yes, and more sense if you use it right -- sorry for my bug above!-(.  It
should be something such as (supposing Klass is your classname,
and putting in the things you're keen about -- again untested, so beware
typos...:-):

class Klass:
    re=re.compile(r'^(\d{0,2})[dD](\d{0,3})([-+]\d{1,2})?$')
    # other class-variables if any
    def thefun(self):
        diematch=self.re.match(self.diecode)
        # etc etc

Note that you can use self.re and have it refer to Klass.re; I consider
self.re to be more advisable because it could be tweaked for specific
class instances (or derived classes) if need be.  But you can also
choose to hardcode
        diematch=Klass.re.match(self.diecode)
if you prefer, to keep it more rigid (I tend to prefer zero-cost
flexibility,
as when I want rigidity there's always C++, but tastes differ:-).


>     Yeah, much cleaner that way with the __init__ setting the defaults for
the
> class.  st_dice (standard) is 1, 6, 0 respectively.  wod_dice (Worlds of
> Darkness) most likely be 1, 10, 0 respectively.  Rather nice way to do it.

Agreed.  And a derived class could also tweak the re if a certain game
should need a slightly different syntax (if you use it as self.re).

Note, by the way, that the defaults should also be set as _class_ variables
(in the class statement) rather than _instance_ variables (in __init__).
It's
a minor issue, but you save keeping a copy of the defaults per-instance
and only get a copy per-class.  If a specific instance needs to have some
of these values changes, no problem; if you ASSIGN to self.sides, etc, it
will only affect that instance's values, Klass.sides will remain untouched.

Do keep _using_ those values in terms of self.sides etc if you want to
keep flexibility this way; but initial _assignments_ can be done in the
class
statement rather than in __init__ for some small advantage in performance
(only one assignment per class rather than one per instance, ditto for
the memory) and functionality (you can change the behaviour of any
instance of the class, present or future, that's not been specifically
"customized", by setting Klass.sides to something different at any time),
with no substantial disadvantage that I can see.


> >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:-)
>
>     Yeah, I'm kinda embarressed about mine after the flaws were pointed
out.

The embarrassment is mutual, given my wrong use of re.match(there,...)
in lieu of there.match(...)!-)


Alex