Guido van Rossum wrote:
> For me personally, the fondest memories are of 1.5.2, which Paul Everitt
> declared, while we were well into 2.x territory, was still the best Python
> ever. (I didn't agree, but 1.5.2 did serve us very well for a long time.)
That makes me feel better about the fact that
Chris Angelico wrote:
>> BUT -- Steve Dower seems to have identified that the wonders of dll hell
>> never cease, and this isn't possible anyway. Oh well.
>
> I'm not entirely grasping what's happening here. There are multiple
> versions of msvcp140.dll floating around out there; what happens if
>
Martin Panter wrote:
>> So, what say you to updating PEP 7 to allow C99 features for Python 3.6
>> (in so much as GCC and MSVC support them)?
>
> Sounds good for features that are well-supported by compilers that
> people use. (Are there other compilers used than just GCC and MSVC?)
clang on OS X
Guido van Rossum wrote:
> If all you need is a random name, why not just use a random number
> generator?
> E.g. I see code like this:
>
> binascii.hexlify(os.urandom(8)).decode('ascii')
I tend to use os.path.join(dir, str(uuid.uuid4())) if I need to
create a random filename to pass to anothe
Nathaniel Smith wrote:
> (This is based on the assumption that the only time that explicitly
> calling os.urandom is the best option is when one cares about the
> cryptographic strength of the result -- I'm explicitly distinguishing
> here between the hash seeding issue that triggered the original
Guido van Rossum wrote:
> I just don't like the potentially blocking behavior, and experts' opinions
> seem to widely vary on how insecure the fallback bits really are, how
> likely you are to find yourself in that situation, and how probable an
> exploit would be.
This is not just a theoretical
David Mertz wrote:
> It feels to me like the correct spelling in 3.6 should probably be
> secrets.getrandom() or something related to that.
Since there already is a secrets.randbits(k), I would keep the
naming similar and suggest something like:
secrets.randbytes(k, *, nonblock=False)
With the
Tim Peters wrote:
> secrets.token_bytes() is already the way to spell "get a string of
> messed-up bytes", and that's the dead obvious (according to me) place
> to add the potentially blocking implementation.
I honestly didn't think that this was the dead obvious function to
use. To me the naming
Steven D'Aprano wrote:
>> it seems to me that you'd want such a solution to have code that
>> causes the initialization of the entropy pool to be sped up so that it
>> happens as quickly as possible (if that is even possible). Is it
>> possible? (E.g. by causing the machine to start doing things
Guido van Rossum wrote:
> Is there some kind of optimized communication possible yet between
> subinterpreters? (Otherwise I still worry that it's no better than
> subprocesses -- and it could be worse because when one
> subinterpreter experiences a hard crash or runs out of memory, all
> others h
10 matches
Mail list logo
