[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't occur without properly re-seeding a PRNG), and it makes bugs easier to catch in unit testing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16500 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16500] Add an 'atfork' module
Changes by Dwayne Litzenberger dl...@dlitz.net: -- nosy: +DLitz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16500 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 below). -- nosy: +DLitz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9974 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 repository in /tmp/repo/.git/ $ touch foo $ git add foo $ git commit -m 'Initial commit' [master (root-commit) cd7dd74] Initial commit 0 files changed create mode 100644 foo $ git describe --tags --always cd7dd74 $ git tag v1.0 $ git describe --tags --always v1.0 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14894 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 nullcontext(): than to read through another level of indirection every time someone wanted some conditional logic on a context manager. Is there any chance that this issue could be reopened? Perhaps a more elegant solution would be to modify the with statement so that any object can be given to it (then we could just use None directly), but I suspect that would be a tad more controversial. ;) -- nosy: +DLitz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10049 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. -- nosy: +DLitz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14894 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 proposal, the first file would decode successfully as \U000f30c0\x00, and the second file would decode unsuccessfully, so it would be mapped to \U000f30c0\x00---the same thing! Under your proposal, you could end up with multiple files having the same filename (from Python's perspective). Python shouldn't break if somebody deliberately created some weird filenames. Your proposal would make it impossible to write a robust remote backup tool in Python 3. Pathnames on ext3/Linux *are not Unicode*. Blindly pretending they're Unicode is a leaky abstraction at best, and a security hole at worst. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3187 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 this area. I wrote some automatic backup software in Python 2 earlier this year. It had to work on ext3/Linux (where filenames are natively octet-strings) and on NTFS/Win32 (where filenames are natively unicode-strings). I had to be ridiculously careful to always use unicode paths on Win32, and to always use str paths on Linux, because otherwise Python would do the conversion automatically---poorly. It was particularly bad on Win32, where if you used os.listdir() with a non-unicode path (Python 2.x str object) in a directory that contained non-ascii filenames, Windows would invent filenames that looked similar but couldn't actually be found when using open(). So, naive (Python 2) code like this would break: for filename in os.listdir(.): f = open(filename, rb) # ... On Linux, it was bad too, since if you used unicode paths, the filenames actually opened would depend on your LANG or LC_CTYPE or LC_ALL environment variables, and those could vary from one system to another, or even from one invocation of the program to another. The simple fact of the matter is that pathnames on Linux are _not_ Unicode, and pathnames on Windows are _not_ octet strings. They're fundamentally incompatible types that can only be reconciled when you make assumptions (e.g. specifying a character encoding) that allow you to convert from one to the other. Ideally, io.open(), os.listdir(), os.path.*, etc. would accept _only_ pathnames in their native format, and it would be the job of a wrapper to provide a portable-but-less-robust interface on top of that. Perhaps the built-in functions would use the wrapper (with reasonable defaults), but the native-only interface should be there for module-writers who want robust pathname handling. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3187 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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://bugs.python.org/issue2384 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 filename as a str object on Linux/ext3 and as a unicode object on Win32/NTFS. os.listdir(.) would return every filename as a str object, and os.listdir(u.) would return every filename as a unicode object---based on the current locale settings---*except* for filenames that couldn't be decoded that way. Consider this bash script (executed on Linux under a UTF-8 locale): export LC_CTYPE=en_CA.UTF-8 # requires the en_CA.UTF-8 locale to be built mkdir /tmp/foo cd /tmp/foo touch $'UTF-8 compatible filename\xc2\xa2' touch $'UTF-8 incompatible filename\xc0' Under Python 2.52, you get this: import os os.listdir(u.) ['UTF-8 incompatible filename\xc0', u'UTF-8 compatible filename\xa2'] os.listdir(.) ['UTF-8 incompatible filename\xc0', 'UTF-8 compatible filename\xc2\xa2'] [open(f, r) for f in os.listdir(u.)] [open file 'UTF-8 incompatible filename�, mode 'r' at 0xb7cee578, open file 'UTF-8 compatible filename¢', mode 'r' at 0xb7cee6e0] Under Python 3.0b3, you get this: import os os.listdir(.) [b'UTF-8 incompatible filename\xc0', 'UTF-8 compatible filename¢'] os.listdir(b.) [b'UTF-8 incompatible filename\xc0', b'UTF-8 compatible filename\xc2\xa2'] [open(f, r) for f in os.listdir(.)] Traceback (most recent call last): File stdin, line 1, in module File stdin, line 1, in listcomp File /home/dwon/python3.0b3/lib/python3.0/io.py, line 284, in __new__ return open(*args, **kwargs) File /home/dwon/python3.0b3/lib/python3.0/io.py, line 184, in open raise TypeError(invalid file: %r % file) TypeError: invalid file: b'UTF-8 incompatible filename\xc0' This behaviour of open() makes it impossible to write code that opens arbitrarily-named files on Linux/ext3. -- components: Windows messages: 71986 nosy: dlitz severity: normal status: open title: open() rejects bytes as filename versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3688 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3688] open() rejects bytes as filename
Changes by Dwayne Litzenberger [EMAIL PROTECTED]: -- components: +Library (Lib) -Windows type: - behavior ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3688 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3187] os.listdir can return byte strings
Changes by Dwayne Litzenberger [EMAIL PROTECTED]: -- nosy: +dlitz ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3187 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. bytes), and *only* the following caveats apply: - a filename/pathname cannot contain the zero-octet (b\x00). - a filename/pathname cannot be empty. - a filename cannot contain the slash (b/); In a pathname, the slash is used to separate filenames. - the filenames b. and b.. have special meanings; They cannot be created, deleted, or renamed. All filenames that meet these criteria are valid, and calling them invalid amounts to plugging one's ears and shouting LA LA LA while imagining Unicode having pre-dated Unix. It is sometimes convenient to imagine filenames on Linux/ext3 as sequences of Unicode code points (where the encoding is specified by LC_CTYPE---it's not necessarily UTF-8), but other times (e.g. in backup tools that need to be robust in the face of mischievous users) it is an unnecessary abstraction that introduces bugs. On Windows/NTFS, the situation is entirely different: Filenames are actually sequences of Unicode code points, and if you pretend they are octet strings, Windows will happily invent phantom filenames for you that will show up in the output of os.listdir(), but that will return File not found if you try to open them for reading (if you open them for writing, you risk clobbering other files that happens to have the same names). To avoid bugs, it should be possible to work exclusively with filenames in the platform's native representation. It was possible in Python 2 (though you had to be very careful). Ideally, Python 3 would recognize and enforce the difference instead of trying to guess the translations; Explicit is better than implicit and all that. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3187 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
