[issue16500] Add an 'atfork' module

Dwayne Litzenberger added the comment: > The main question is whether a failed prepare callback should prevent the > fork from happenning Yes, I think an exception should prevent the fork from happening. It's fail-safe for the PRNG case (you can guarantee that a fork won'

[issue16500] Add an 'atfork' module

Changes by Dwayne Litzenberger : -- nosy: +DLitz ___ Python tracker <http://bugs.python.org/issue16500> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9974] tokenizer.untokenize not invariant with line continuations

Dwayne Litzenberger added the comment: @amk: I'd appreciate it if you did. :) I ran into this bug while writing some code that converts b"..." into "..." in PyCrypto's setup.py script (for backward compatibility with Python 2.5 and be

[issue14894] distutils.LooseVersion fails to compare number and a word

Dwayne Litzenberger added the comment: "git describe --tags --always" will return a bare commit id if there is no previous tag. This is pretty common to have when you're working on a new package that hasn't been released yet: $ git init Initialized empty Git reposito

[issue10049] Add a "no-op" (null) context manager to contextlib

Dwayne Litzenberger added the comment: After seeing a context manager named like "TempfileIfNeeded(..., cond)", whole sole purpose is to handle the conditional case, I'm firmly +1 on this proposal. It's much easier to just read "with Tempfile() if cond else null

[issue14894] distutils.LooseVersion fails to compare number and a word

Dwayne Litzenberger added the comment: As far as a real-world example is concerned, if you're using git-describe to generate your version numbers, you can pretty easily end up with something like "ab25c6fe95ee92fac3187dcd90e0560ccacb084a".

[issue3187] os.listdir can return byte strings

Dwayne Litzenberger <[EMAIL PROTECTED]> added the comment: Martin, Consider this scenario. On ext3/Linux, assume that UTF-8 is specified in the system locale. What would happen if you have two files, named b"\xf3\xb3\x83\x80\x00" and b"\xc0\x00"? Under your prop

[issue3187] os.listdir can return byte strings

Dwayne Litzenberger <[EMAIL PROTECTED]> added the comment: On Sat, Sep 27, 2008 at 01:15:46AM +, Guido van Rossum wrote: > I don't see the advantage over the existing rule bytes in -> bytes out... Guido, I figure I should say something since I have some experience in th

[issue2384] [Py3k] line number is wrong after encoding declaration

Dwayne Litzenberger <[EMAIL PROTECTED]> added the comment: Could "-*- coding: ascii -*-" and other equivalent encodings be fixed, at least, before the release? ___ Python tracker <[EMAIL PROTECTED]> <http://

[issue3187] os.listdir can return byte strings

Dwayne Litzenberger <[EMAIL PROTECTED]> added the comment: I think Guido already understands this, but I haven't seen it stated very clearly here: ** Different systems use different "things" to identify files. ** On Linux/ext3, all filenames are *octet strings* (i.e. b

[issue3187] os.listdir can return byte strings

Changes by Dwayne Litzenberger <[EMAIL PROTECTED]>: -- nosy: +dlitz ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3187> ___ __

[issue3688] open() rejects bytes as filename

Changes by Dwayne Litzenberger <[EMAIL PROTECTED]>: -- components: +Library (Lib) -Windows type: -> behavior ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.py

[issue3688] open() rejects bytes as filename

New submission from Dwayne Litzenberger <[EMAIL PROTECTED]>: On Linux/ext3, filenames are stored natively as sequences of octets. On Win32/NTFS, they are stored natively as sequences of Unicode code points. In Python 2.x, the way to unambiguously open a particular file was to pass the fi

[issue2384] [Py3k] line number is wrong after encoding declaration

Changes by Dwayne Litzenberger <[EMAIL PROTECTED]>: -- nosy: +dlitz ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2384> ___ __