Python not that wierd

[Alex Martelli]

"Steve Lamb" <grey at despair.rpglink.com> wrote in message
news:slrn8ognca.n9u.grey at teleute.rpglink.com...
> On Wed, 2 Aug 2000 18:43:19 +0200, Alex Martelli <alex at magenta.com> wrote:
> >Sorry, I don't understand.  match is optimized for the purpose of
> >matching the whole-line, which seems to be exactly your purpose:
>
>     Stubborness.  I think part of the process is "Well, might change
> later"itos.  I just don't like the idea that the function/method call
dictates
> where the search is when there is regex options to do that.  Why create
one
> regex for one function only to change it later and then have to change the
> function as well?

You can save the bound-method if you want.  The power of Python boggles
the mind sometimes, I know, but try:

matcher1=re.compile('foo').match

matcher2=re.compile('^foo').search

These are bound-methods of RegexObject instances.  You use them like
functions, because they already bind the object-instance they get
applied to... so the regex and the method to be called on it are
defined in the same place, and you can change them together if needed.


> >OK.  Although a long-time RPG'er myself (anybody remembers the Aleax
> >monster in AD&D's monster-manual? no? oh well...),
>
>     Let me look it up when I get home. mine might have it.  Anyone
remember
> the Cthulu mythos in AD&D?  No?  How about D&D in a single, soft-bound,
black
> and while book <100 pages?  :)

Nope.  D&D started out as 3 tiny booklets in a cardboard box.  I should
know -- I brought a copy to Italy (the first one, AFAIK, to reach these
shores) in 1975... (you also needed a mediocre military-miniatures rule
book, 'Chainmail', to make some sense of it... not much... fortunately
soon afterwards I discovered 'Alarums & Excursions' -- one Gary Gygax
was among that apazine's members at the time -- and some explanations
started to arrive...:-).


> >I've been out of touch with the genre for years, after all.  D1000 (three
> >20-sided dice read each as a digit, of course, just an extension of D100)
was
>
>     Don't you mean 3 d10?  I wonder how you grok a 12, an 18 and a 6 into
> something for 1000.  :)

20-side dice at the time had only one digit per face; you inked in (with
felt-tip pens) red into one 0-9 set, black into the other.  Good china
ink from felt-tips persisted well, since it settled in the grooves of the
digits, despite repeated rolling. When you needed a 10-sided die, you
just ignored the red/black distinction; when you needed a 20-sided one,
reds were the teens (1=11 to 0=20), blacks the onesies.  When you needed
a 100-sided die, you rolled 2 icosahedrons, ignoring red-black, and the
lighter-coloured icosahedron was the decades, the darker-one the units.

10-sided solids (which as far as I recall can't be fully regular, i.e.
Platonic) are just not as neat as (fully-regular, platonic) 20-sided
ones (icosahedrons).  Plus, decent non-cubic dice cost a bundle back
then, and not having to own physically-10-sides ones was a plus!


> >base hit-chance, so if you're 24% to hit why get only a 4% chance to
impale
> >when you can have a precise 4.8% by using a "1000-sided dice"...)
>
>     Or one could round up to 5%, but heyyyyyy, let's not let simpler
> mathematics than division ruin it for everyone.  :)

Original RQ did work in multiples of 5%, with 20-sided dice, but it
was soon changed into 1%-granularity with 100-sided dice.  That was
around 1977, or maybe 1978, I'm not sure.


> >guess those refinements didn't make it into the mainstream (although, if
I
> >were you, I'd pose the question on some general RPG discussion group;
> >the 1000-sided die is such a natural that I'm surprised it's utterly
> >unknown).
>
>     To be honest, yours is the first mention of it I've run across, ever.

We were pretty weird back in the '70s, I guess.


> >Keep a reference to the class itself, rather than to its name, and your
life
> >is simpler:
>
>     Ahhhhhh, good show there, Dangermouse!  So having classes st_dice,
sw_dice
> and wod_dice I could map those into a directory and then have:
> dice = sets{"wod"}()
>
>     Or am I off on that?  BTW, that is most likely wrong, I've not done a
> directory yet in Python so the syntax isn't in my brain.

Yes, the syntax is slightly off -- you always use [] to index in Python
(the object knows whether it's a dictionary or a list, no need for the
operator to remind it:=), so it would be

    dice = sets['wod']()

but you were really pretty close!


> >Yep, it's fun, innit?  The pervasive use of dictionaries ('hashes' to
> >Perlists:-), so you can generally supply your own dictionary in lieu
> >of vars(), or use vars() as a dictionary, etc, etc, is also lots of fun.
> >Each class-instance has its dict, so has the class as a whole, ...
>
>     Slight tangent, I'm surprised that more people don't handle arrays
like
> PHP does.  An array in PHP is just a hash that happens to have numerical
keys
> in order.  :)

As far as I recall, awk and Rexx (originally Rex with just one X, but
that was back when it was an IBM-internal-use-only language, around
1982 maybe) were among the first widespread languages to use "generalized
arrays" only (I forget which kind Snobol had, actually).  The distinction
has its uses though (keys in a dictionary are in arbitrary order, for
example -- this allows speedy hashtable implementation, rather than
slightly slowed red-black-trees &c; crucial for Python, whose dicts MUST
be super-fast, since they're used so widely).  But, yes, conceptually
there may be no strict need for sequences if you have mappings: they're
there just for convenience & performance.


> >Well, there ARE cases where you want to roll and sum two different
> >kind of dice, surely.  Even in bad old D&D first edition, in certain
cases
> >you had D8+D4, for example...
>
>     For those I'd issue two rolls.  The server allows comments to be used.
So
> something like this would work:
>
> co: Here's Blorg snafu roll (d8+d4)
> d8
> d4

OK.  A sum of arbitrary dice would no doubt be slightly awkward to handle
anyway -- syntax is easy, but then you have to apply it.  Having more
generality than is actually used is often fine, but simplicity must never
be allowed to suffer for that...


Alex