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't occur
without
Changes by Dwayne Litzenberger dl...@dlitz.net:
--
nosy: +DLitz
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16500
___
___
Python-bugs-list
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
below).
--
nosy: +DLitz
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 repository in /tmp/repo/.git
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 nullcontext():
than to read through
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.
--
nosy: +DLitz
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 proposal, the first
file would decode
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 this area.
I wrote some
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://bugs.python.org/issue2384
Changes by Dwayne Litzenberger [EMAIL PROTECTED]:
--
nosy: +dlitz
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2384
___
___
Python-bugs-list mailing
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 filename
Changes by Dwayne Litzenberger [EMAIL PROTECTED]:
--
components: +Library (Lib) -Windows
type: - behavior
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3688
Changes by Dwayne Litzenberger [EMAIL PROTECTED]:
--
nosy: +dlitz
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3187
___
___
Python-bugs-list mailing
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. bytes), and
*only
14 matches
Mail list logo
