[Python-Dev] Should we use getentropy() for os.urandom()?
Hi, I followed discussions on the new systems getrandom() on Linux and getentropy() on OpenBSD. I wanted to use them in Python to avoid the need of a file descriptor to read /dev/urandom. Linux getrandom() is also more secure than /dev/urandom because it blocks until /dev/urandom is feeded with enough entropy. getentropy() and getrandom() are now used in Python 2.7.10, Python 3.4 and newer. Today, an issue was reported on Solaris because os.urandom() is much slower with Python 2.7.10: https://bugs.python.org/issue25003 It looks like Solaris has getrandom() and getentropy(), and getentropy() is slow. Now I'm not sure that I understood the purpose of getentropy() even on OpenBSD. Should it be used to feed a PRNG in user-space, or can it be used as a PRNG? http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/getentropy.2?query=getentropy&sec=2 If getentropy() must only be used to feed a PRNG (which only use a few bytes), we should remove the code using getentropy() (but getrandom() should be kept). Note: I didn't know that other operating systems supported getrandom() and getentropy()! The feature looks recent in Solaris: " Solaris 11.3 adds two new system calls, getrandom(2) and getentropy(2), for getting random bit streams or raw entropy." https://blogs.oracle.com/darren/entry/solaris_new_system_calls_getentropy (article published at July, 2015) Note2: There is an open discussion proposing to "Use arc4random under OpenBSD for os.urandom() if /dev/urandom is not present" https://bugs.python.org/issue22542 getentropy() issue in Python (closed): https://bugs.python.org/issue22585 getrandom() issue in Python (closed): https://bugs.python.org/issue22181 Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement
2015-09-05 10:44 GMT+02:00 haypo s : > PEP 498 allows to write >'abc' f'string'< which is replaced with >>'abc' 'string'.__format__()< whereas str+str is a bad practice. Oops, you should read which is replaced with >'abc' + 'string'.__format__()< with a '+' between the two strings. Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement
2015-09-05 5:01 GMT+02:00 Guido van Rossum : > And I'm ready to accept it. I'll wait until Tuesday night (Monday's a > holiday in the US) in case anything unforeseen comes up, but this is really > the Last Call for this PEP. String concatenation is inefficient in Python because strings are immutable. There is a micro-optimization which tried to reduce the bad performances of a+b, but it's better to avoid it. Python replaces >'abc' 'def'< with a single string >'abcdef'<. It's done by the parser, there is no overhead at runtime. PEP 498 allows to write >'abc' f'string'< which is replaced with >'abc' 'string'.__format__()< whereas str+str is a bad practice. I would prefer to force users to write an explicit '+' to remind them that there are more efficient ways to concatenate strings like ''.join((str1, str2)) or putting the first string in the f-string: >f'abcstring'<. Section in the PEP: https://www.python.org/dev/pepsstring/pep-0498/#concatenating-strings Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement
2015-09-05 5:01 GMT+02:00 Guido van Rossum :
> And I'm ready to accept it. I'll wait until Tuesday night (Monday's a
> holiday in the US) in case anything unforeseen comes up, but this is really
> the Last Call for this PEP.
Would it be possible to specify a subset of the Python language
allowed in f-string? For example, __import__ or lambda should not be
used in a f-string. I'm not convinced that a loop or
list/dict/set-comprehension is a good idea neither.
I would prefer to keep as much code as possible *outside* f-string because:
- text editor knows well how to color it
- static analyzers know how to analyze it
- it encourage developers to indent and comment their code correctly,
whereas f-string has more restrictons on indentation (is it possible
to indent and comment code inside a f-string?)
For example, for me it's a common practice to write a complex
list-comprehension on two lines for readability:
newlist = [very_complex_expression(item)
for item in oldlist]
# sorry, it's hard to indent correctly in a mail client, especially Gmail
Well, I'm not convinced that we need a larger subset than what is
allowed currently in str.format(), simple expressions like: obj.attr,
obj[index], etc.
I recall horrible examples in the previous mail threads showing how
much complex code you can put inside f-string.
Even the following example from the PEP seems too complex to me:
print(f"Usage: {sys.argv[0]} [{'|'.join('--'+opt for opt in
valid_opts)}]", file=sys.stderr)
Oh, first I read [...] as a list-comprehension :-p But it's part of
the output string, not of the Python code...
I prefer to build the second parameter outside the f-string:
opts = '|'.join('--'+opt for opt in valid_opts)
print(f"Usage: {sys.argv[0]} [{opts}]", file=sys.stderr)
f-string with complex code remembers me PHP where it was possible to
mix PHP and HTML. I have bad memories such... code? template? (I don't
know how to cal them). Text editors and me were unable to identify
quickly the beginning and end of the code. We have a similar issue
with Python unit test embedding Python code to run subprocesses. My
text editor vim is unable to identify if the current code is the
outter code or the code embedded in a long triple-quoted string
(especially when you open the file at the embedded code).
Maybe we should start with a simple f-string, play with it during one
cycle (Python 3.6), and then discuss again if it's necessary to extend
the allowed Python expresions inside f-string?
If you really want to allow *any* Python inside a f-string, can you
please at least explain in th PEP why you consider that it's a good
thing?
IMHO the main advantage of allowing expressions inside f-string is
that it adds something really new compared to the current str.format()
method. Without it, f-string are less interesting.
Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
