[issue24754] argparse add_argument with action="store_true", type=bool should not crash
Douglas Bagnall added the comment: Thanks paul.j3 and r.david.murray, I see your points. What led me to this was automatically generating command line options from a Gstreamer element, mapping the Gstreamer property types to Python types. Then I special-cased the action="store_true" for the boolean ones and was surprised by the somewhat unclear error message. As you suggest, paul.j3, "type" is in some ways an unfortunate choice of keyword for this, but it too late to change that. -- resolution: -> not a bug status: open -> closed ___ Python tracker <http://bugs.python.org/issue24754> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24754] argparse add_argument with action="store_true", type=bool should not crash
New submission from Douglas Bagnall:
A line like this:
parser.add_argument('--hello', action="store_true", type=bool)
causes a TypeError in 2.7 and 3.4:
File "/usr/lib/python3.4/argparse.py", line 1344, in add_argument
action = action_class(**kwargs)
TypeError: __init__() got an unexpected keyword argument 'type'
It shouldn't really.
--
components: Library (Lib)
files: argparse-crash.py
messages: 247658
nosy: dbagnall
priority: normal
severity: normal
status: open
title: argparse add_argument with action="store_true", type=bool should not
crash
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file40065/argparse-crash.py
___
Python tracker
<http://bugs.python.org/issue24754>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12754] Add alternative random number generators
douglas bagnall added the comment: I am no kind of crypto expert, but from what I read, there are no known attacks on chacha8 or salsa20/12 better than brute-forcing the key, and distinguishing the stream from random or deducing state would be considered an attack. There's a summary of the ESTREAM cipher's security here: http://cr.yp.to/streamciphers/attacks.html -- be aware it was written by the chacha/salsa author, so may be biased. > I'm not sure I follow the notes on state size. Is it 320 bits + 64 bits or > is it 512 bits? Yeah. The state is contained u32[16], so the 512 is sizeof(that). 320 + 64 is the number of states I can see it getting into from the seeds and cycles. I imagine the discrepancy is a convenience, just as the mt19937 struct uses a few more than 19937 bits. > With respect to the SIMD optimizations and longlong to double operations, I'm > curious to take a look at how it was done yet wonder if there is a provable, > portable implementation and also wonder if it is worth it (the speed of > generating a random() tends to be dwarfed by surrounding code that actually > uses the result -- allocating the python object, etc). I agree that it is not worth it. However the dSFMT generator does seem quite portable and fall back to non-SIMD code (which is allegedly still faster), and its distribution is supposedly a bit better -- though not as good as WELL. The bit magic is quite simple: if you set the top 12 bits to 0x7ff and randomise the other 52, you get a double in the range [1, 2). So you subtract 1. It costs one bit relative to the current method, which is equivalent to 53 bit fixed point. They explain it reasonably well in these slides: http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/dSFMT-slide-e.pdf -- ___ Python tracker <http://bugs.python.org/issue12754> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12754] Add alternative random number generators
douglas bagnall added the comment: A bit more on the state size and period of the stream ciphers. Chacha and Salsa use 64 bytes (512 bits) of state (vs ~2.5kB for MT19937). Its counter is 64 bits, and its seed can be 320 bits (in cipher-speak, the seed is split between a 256 bit key and a 64 bit IV). Each counter iteration produces 64 random bytes, or 8 doubles, so for any seed, you get a cycle of 2 ** 67, which would last in the order of 100 thousand years on current PCs. Some of the other ciphers I looked at have smaller seeds and states, and some produce fewer bytes per iteration, but I don't think any of them will result in a cycle of smaller than 2 ** 64. PS: Regarding the discussion of something like Random.getrandbytes(n): +1 -- ___ Python tracker <http://bugs.python.org/issue12754> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12754] Add alternative random number generators
douglas bagnall added the comment:
Earlier this year I wrote Python wrappers for a number of generators:
https://github.com/douglasbagnall/riffle
They are mostly cryptographic stream ciphers from the ESTREAM[1] project, but I
was also interested in dSFMT[2], which is a SIMD optimised descendant of
MT19937 which runs several times faster and directly produces doubles using
cunning bit tricks.
[1]http://www.ecrypt.eu.org/stream/
[2]http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/#dSFMT
Wrapped in Python, the stream ciphers ran about as fast as MT19937 on my
laptop, while dSFMT took about two thirds the time to run a
"random();random();random();..." test. For a slightly more realistic test
("sum(random() for x in range(N))"), the performance levelled right off. As
expected.
The stream cipher generators have some good properties. They generally
generate random bytes using something analogous to hash('%s%s' % seed,
counter), which means different seeds produce well separated streams, and to
skip forward or back in the stream, you just adjust the counter. This would
allow the reinstatement of Random()'s stream-skipping function, which some
people (e.g. L'Ecuyer) think is important. (incidentally, the MT people have
come up with a jump-ahead algorithm for MT
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/JUMP/index.html).
Of the ciphers I tried, the chacha/salsa family and sosemanuk had the best
combination of good testing and portable, reasonably fast, openly licensed C
implementations. HC128 and snow2 also perform well.
The chacha code is shorter than sosemanuk, so I would choose that. It is used
as a primitive in the BLAKE SHA3 candidate, which is a vote of confidence and
an attractor of testing for the algorithm.
--
nosy: +dbagnall
___
Python tracker
<http://bugs.python.org/issue12754>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
