On Sun, Aug 10, 2014 at 9:34 AM, Paul Wolf <paulwolf...@gmail.com> wrote:
> * No one will want to write that expression
We've already established that one to be wrong. ;)
> * The regex expression doesn't work anyway
That's a cheap swipe. The regexp doesn't work because I used a colon
instead of a comma, because I accidentally copied you. :(
Speaking of which, is there a reason you've diverged from regex syntax
in x{8: 15} vs x{8,15}?
Don't mind my suggestion to use existing formats even when it's
inconvenient. It's a knee jerk reaction/question, not a serious
complaint.
> I should also clarify that when I say the strgen template language is the
> converse of regular expressions, this is the case conceptually, not formally.
> Matching text strings is fundamentally different from producing randomized
> strings.
Mmmm, I wouldn't be so quick to dismiss any insights from regexps
here. It depends on your fundamentals. For example, automata-theoretic
approaches do apply, and can let you guarantee that equivalent
templates always generate the same outputs given the same inputs.
(Meaning that the only thing that matters is what the template
matches, not how it's spelled.)
> Whether using SystemRandom is cryptographically weak is not something I'm
> taking up here. Someone already suggested allowing the class to accept a
> different random source provider. That's an excellent idea. I wanted to make
> sure strgen does whatever they would do anyway hand-coding using the Python
> Standard Library except vastly more flexible, easier to edit and shorter.
> strgen is two things: a proposed standard way of expressing a string
> generation specification that relies heavily on randomness and a wrapper
> around the standard library. I specifically did not want to try to write
> better cryptographic routines.
The fallback is what worries me. Falling back from a secure thing to
an insecure thing doesn't sound good.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
