This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author glyph
Recipients glyph
Date 2016-08-08.00:15:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
The purpose of 'seeding' a random number generator is usually to supply a deterministic sequence of values starting from a known point.  This works fine if you seed random.Random with an integer.  Often (for example, see Minecraft's map generation interface) one wants to begin with a human-memorable string as the seed, and superficially it would seem that passing a string to Random.seed would serve exactly this use-case.  In fact in its original incarnation it did.

However, since the introduction of PYTHONHASHSEED in 2.6.8, it's possible that strings now hash to different values, and on 3.2+, they'll _always_ hash to different values unless otherwise configured (which, as per the reason for introducing this feature in the first place, is a security flaw).

Right now the way to work around this is to get some deterministic hash from your string; one mechanism being a truncated SHA256 hash, for example, like this:

Random(struct.unpack("!I", sha256(seed.encode("utf-8")).digest()[:4])[0])

but this strikes me as an obscure trick to require of someone just trying to get their D&D character generator to produce the same values twice in a row for unit testing.

I'm not sure what the resolution should be, but I figured I should report this since I tripped over it.
Date User Action Args
2016-08-08 00:15:15glyphsetrecipients: + glyph
2016-08-08 00:15:14glyphsetmessageid: <>
2016-08-08 00:15:14glyphlinkissue27706 messages
2016-08-08 00:15:12glyphcreate