[issue3864] 26.rc1: test_signal issue on FreeBSD 6.3
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: The tests are passing on FreeBSD 7.0 (only checked amd64 at this point). I came across a reference to an errata notice for FreeBSD 6.x which appears pertinent: http://security.freebsd.org/advisories/FreeBSD-EN-08:01.libpthread.asc As I read the above notice, the underlying issue is a FreeBSD bug which will be fixed in FreeBSD 6.4 (expected to be released in the next couple of months. On this basis, I suggest closing this as Won't fix. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3864 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
Nick Coghlan [EMAIL PROTECTED] added the comment: Jesse, how much (if any) of the rest of the package will work without the synchronize module? If it isn't a lot, then it may be a matter of just making this a cleaner ImportError and an expected test suite skip on OpenBSD and FreeBSD. (Unfortunately, our OpenBSD and FreeBSD buildbots are so unreliable that they don't get much attention when they go red - it looks to me like the OpenBSD buildbot isn't even managing to build _multiprocessing at the moment, because HAVE_SEM_OPEN is incorrectly set to 1). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3770 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: I've done some more digging into this for the FreeBSD case. FreeBSD 6.3 and 7.0 both have sem_open, and the man pages suggest it should be fully functional. (see http://www.freebsd.org/cgi/man.cgi?query=sem_openapropos=0sektion=0manpath=FreeBSD+6.3-RELEASEformat=html) There is a caveat on the length of the name, which I think could trigger if the counter variable passed into SEM_CREATE() is . But as that variable seems like it can only ever be 0 (not sure this is intended!) this shouldn't happen as it stands. If I change HAVE_SEM_OPEN to 1 in setup.py, the _multiprocessing module builds, but test_multiprocessing provokes a core dump in both cases. The backtrace (on 6.3 i386) looks like: #0 0x2820ef17 in ksem_open () from /lib/libc.so.6 #1 0x2820592c in sem_open () from /lib/libc.so.6 #2 0x284494a0 in semlock_new (type=0x2844b380, args=0x836443c, kwds=0x0) at /home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c:439 #3 0x0809e710 in type_call (type=0x2844b380, args=0x836443c, kwds=0x0) at Objects/typeobject.c:731 #4 0x0806042a in PyObject_Call (func=0x2844b380, arg=0x836443c, kw=0x0) at Objects/abstract.c:2487 #5 0x080cc367 in PyEval_EvalFrameEx (f=0x84dd00c, throwflag=0) at Python/ceval.c:3890 #6 0x080cf9ac in PyEval_EvalCodeEx (co=0x8478800, globals=0x4e, locals=0xa00, args=0x819b02c, argcount=4, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2942 #7 0x08123f84 in function_call (func=0x8486ca4, arg=0x82e107c, kw=0x0) at Objects/funcobject.c:524 #8 0x0806042a in PyObject_Call (func=0x8486ca4, arg=0x82e107c, kw=0x0) at Objects/abstract.c:2487 #9 0x08069c15 in instancemethod_call (func=0x4e, arg=0x82e107c, kw=0x0) at Objects/classobject.c:2579 #10 0x0806042a in PyObject_Call (func=0x84857ac, arg=0x82e107c, kw=0x0) at Objects/abstract.c:2487 #11 0x080cc367 in PyEval_EvalFrameEx (f=0x826140c, throwflag=0) at Python/ceval.c:3890 ---Type return to continue, or q return to quit--- On 7.0 amd64, the top of the backtrace scrolls off screen so I can't get the start of the trace (X not installed...). To try and remove threads from the equation, due to FreeBSD 6.3 having an issue with fork() in a threaded build (see issue3864 for more info), I configured without threads (ie ./configure --without-threads) and the _multiprocessing module fails to build: gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall-Wstrict-prototypes -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=0 -IModules/_multiprocessing -I. -I/home/andymac/build/python-svn/trunk-r66550/./Include -I. -IInclude -I./Include -I/usr/local/include -I/home/andymac/build/python-svn/trunk-r66550/Include -I/home/andymac/build/python-svn/trunk-r66550 -c /home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c -o build/temp.freebsd-6.3-RELEASE-i386-2.6/home/andymac/build/python-svn/trunk-r66550/Modules/_mult iprocessing/semaphore.o /home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c: In function `semlock_acquire': /home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c:314: error: `_save' undeclared (first use in this function) /home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c:314: error: (Each undeclared identifier is reported only once /home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c:314: error: for each function it appears in.) It appears that some support is there for a single threaded build, but is incomplete (there's a similar problem in socket_connections.c, but the module build bails before then). If its not to be supported on single threaded builds (which would be a big shame in my opinion!) then the code should make this explicit, otherwise the single threaded build case needs to be fixed. I'm still trying to understand the core dump in the multithreaded build - unfortunately I'm not terribly familiar with gdb or with debugging from cores (and the actual failure appears to be triggering in the C library for which I currently don't appear to have symbols...) Any suggests on how/where to dig further on this? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3770 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
Andrew I MacIntyre [EMAIL PROTECTED] added the comment: Oops - meant to add that the actual reported cause of the core dump is Bad system call. Also, the OpenBSD man pages make clear that shared semaphores aren't supported and sem_open() doesn't exist: http://www.openbsd.org/cgi-bin/man.cgi?query=sem_openapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=html ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3770 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3983] Typos in Documentation
New submission from Bk [EMAIL PROTECTED]: Hello, I would like to contribute to the development of the Python documentation so I am reporting two typos. The first one is in the documentation and the second one is in the module ntpath. 1) There's a typo under The Python Tutorial Using the Python Interpreter Invoking the Interpreter. The sentence with the typo is positioned almost at the top, and starts like this: On Windows machines, the Python installation is usually placed in C:Python30 ... The above text lacks a backslash in the path C:Python30. Please add a backslash to this path so that it would be written as C:\Python30. The text should be written like this: On Windows machines, the Python installation is usually placed in C:\Python30 ... 2) Please take a look at the source code of the module ntpath. The line 63 has a typo in the comment: # set to 1 iff b makes path irrelevant which should be # set to 1 if b makes path irrelevant Please note that the word 'iff' is fixed to 'if'. Maybe just two little questions at the end... Please see the source code of the module ntpath and note the line 72. Since the word in the comment (i.e. 'But') is a continuation of the same sentence, doesn't it suppose to be written with the lower-case initial as 'but'? And also, why do some comments in modules start with the lower-case initial and end without the dot, and others with the upper-case initial and end with a dot? It would be nice if those things would be conventionalized. I really don't understand when a comment must be written as a sentence with its full orthographical rules. Please explain. -- assignee: georg.brandl components: Documentation messages: 73960 nosy: Bk, georg.brandl severity: normal status: open title: Typos in Documentation versions: Python 3.0, Python 3.1 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3983 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3956] turtle.py - bug in Screen.__init__()
Martin v. Löwis [EMAIL PROTECTED] added the comment: I'll demonstrate here in a short interactive session (which you can reproduce using IDLE with the -n switch as usual), why the solution Martin proposes doesn't meet the requirements I tried to accomplish with my code. This session 'simulates' a student curiously playing around and experimenting with *the* Screen(): from turtle import Screen, Turtle class YellowScreen(Screen): def __init__(self): Screen.__init__(self) self.bgcolor(yellow) Hmm. Why is it important to be able to inherit from Screen? I don't think inheritance from a singleton is a meaningful concept, and I believe that students are misguided when they are told that this is the way to produce yellow screen. Instead, they should write def YellowScreen(): s = Screen() s.bgcolor(yellow) return s This much better captures the notion of a singleton object: you can not *create* them, but you have to *modify* them. s1 = Screen() s1.bgcolor(pink) This is really confusing. It does *not* create a new screen, but modifies the existing one. How can you tell your students the meaning of object creation in the light of this strange behavior? So I urge you to reconsider that inheritance from Screen should be deliberately dropped. It is a flawed, undesirable concept. Nevertheless I decisively propose to accept this behaviour in order to be able do things like the ones demonstrated above. You can do the things you want to just as fine with functions. Morover I also consider it to be a benefit to use spezialized and/or reusable screens derived from the Screen() class in scripts, what would not be possible with a Screen()-function returning *the* single _Screen() object. (All this meant in the context of teaching and learning OOP). Not at all. It would be very easy with a Screen function. But if you think, that there is no way around and it has to be observed strictly, one had to leave everything as is and find a better solution (with the desired behaviour) for 2.6.1. I propose that Screen is change to a function for 2.6. This is the more restrictive solution (not allowing inheritance). If inheritance would be allowed now, it could be taken back for backwards compatibility. However, if it is changed to a function now, it can be changed back to a class later. Anyway I'd like to express my hope that this controversial implementation of the last element in the class hierarchy for a very special purpose is *not* a hint at a design bug of the entire class hierarchy. Perhaps not of the entire hierarchy, but certainly of the Screen class and its potential subclasses. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3983] Typos in Documentation
Georg Brandl [EMAIL PROTECTED] added the comment: Fixed typo 1) in r9, thanks for that. For 2), iff is a usual abbreviation for if and only if. About your two questions, comments in modules are written in whatever way the author likes to write his comments. There are no rules for that, other than that a comment should explain the code it comments on. (PEP 8 has some examples of unhelpful comments.) -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3983 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3960] Section permalink html anchors are wrong
Georg Brandl [EMAIL PROTECTED] added the comment: I don't see that inter-document links *wouldn't* work, except on antique browsers that insist on a name tags only for defining anchors. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3960 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3984] python interpreter import dependency with disutils/util
New submission from Tarek Ziadé [EMAIL PROTECTED]: I am trying to write a patch in distutils to make use the standard logging module, and I had a weird problem: if I add import logging at the top of Lib/distutils/log.py file to start my work, it just brakes the interpreter. Python does not find cStringIO and time modules anymore. It seems that this is because Lib/site.py calls distutils.util.get_platform when main() is launched I have run it with -v to get more info (see the file) -- files: tb.txt messages: 73964 nosy: tarek severity: normal status: open title: python interpreter import dependency with disutils/util type: crash versions: Python 2.6 Added file: http://bugs.python.org/file11638/tb.txt ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3984 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3984] python interpreter import dependency with disutils/util
Changes by Tarek Ziadé [EMAIL PROTECTED]: -- components: +Distutils, Interpreter Core ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3984 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3985] removed string module from distutils
New submission from Tarek Ziadé [EMAIL PROTECTED]: This patch removes string usage from dist.py, so the module uses modern syntax. -- components: Distutils files: dist-no-string.diff keywords: patch messages: 73965 nosy: tarek severity: normal status: open title: removed string module from distutils versions: Python 2.6 Added file: http://bugs.python.org/file11639/dist-no-string.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3985 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3985] removed string module from distutils [patch]
Changes by Tarek Ziadé [EMAIL PROTECTED]: -- title: removed string module from distutils - removed string module from distutils [patch] ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3985 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3939] Patch to implement a real ftplib test suite
Giampaolo Rodola' [EMAIL PROTECTED] added the comment: I think the patch in attachment could solve the problem. Note: done against the 2.x trunk; changes for 3.x are the same. Added file: http://bugs.python.org/file11640/test_ftplib.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3939 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3986] removed string and type usage from distutils.cmd [patch]
New submission from Tarek Ziadé [EMAIL PROTECTED]: I am removing in this patch the usage of string and type. 1/ I have remove string import, and used the proper modern syntax 2/ Type was used to check for object types, and sometimes isinstance() was called. I have replaced all the calls by isinstance() and removed types import. -- components: Distutils files: cmd.no-string-no-type.diff keywords: patch messages: 73967 nosy: tarek severity: normal status: open title: removed string and type usage from distutils.cmd [patch] versions: Python 2.6 Added file: http://bugs.python.org/file11641/cmd.no-string-no-type.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3986 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3987] removed types from distutils.core [patch]
New submission from Tarek Ziadé [EMAIL PROTECTED]: types is not used, the import shall be removed -- components: Distutils files: core-no-types.diff keywords: patch messages: 73968 nosy: tarek severity: normal status: open title: removed types from distutils.core [patch] versions: Python 2.6 Added file: http://bugs.python.org/file11642/core-no-types.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3987 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3988] Byte warning mode and b'' != ''
New submission from Christian Heimes [EMAIL PROTECTED]: In byte warning mode (-b or -bb command line argument) b'' == '' raises an exception but b'' != '' doesn't. ./python -bb b'' == '' Traceback (most recent call last): File stdin, line 1, in module BytesWarning: Comparison between bytes and string b'' != '' True I can't recall why I implemented the byte warning mode this way. But nowadays I think it could hide bugs in code like while egg != '' where egg is a byte instance. -- assignee: barry components: Interpreter Core messages: 73969 nosy: barry, christian.heimes priority: release blocker severity: normal status: open title: Byte warning mode and b'' != '' type: behavior versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3988 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3984] python interpreter import dependency with disutils/util
Christian Heimes [EMAIL PROTECTED] added the comment: site.py uses distutils to include the lib directories when Python is run from the development directory. -- nosy: +christian.heimes ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3984 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3984] python interpreter import dependency with disutils/util
Tarek Ziadé [EMAIL PROTECTED] added the comment: Ok thanks, I could make it work by removing the call to distutils.util.get_platform() in site.addbuilddir() and harcode the name of my platform there, Maybe a solution would be to : * move get_platform out of distutils.util * move sysconfig out of distutils as well and to create a sysconfig module at the root of Lib/ that doesn't depend on any other module besides os and sys. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3984 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3956] turtle.py - bug in Screen.__init__()
Martin v. Löwis [EMAIL PROTECTED] added the comment: Here is a patch that takes the alternative route, of making Screen a singleton function, and renaming the class to _Screen. Added file: http://bugs.python.org/file11643/singleton.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3988] Byte warning mode and b'' != ''
Benjamin Peterson [EMAIL PROTECTED] added the comment: +1 I was just confused by this fact yesterday. :) -- nosy: +benjamin.peterson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3988 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3989] Tools\Scripts\2to3.py broken under 3.0 rc1 Windows
New submission from arnaud.faucher [EMAIL PROTECTED]: Under Windows (using the MSI), 2to3.py is outdated. http://svn.python.org/view/sandbox/trunk/2to3/ contains the working version (rev. 66173) -- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 73974 nosy: arnaud.faucher, collinwinter severity: normal status: open title: Tools\Scripts\2to3.py broken under 3.0 rc1 Windows versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3989] Tools\Scripts\2to3.py broken under 3.0 rc1 Windows
Benjamin Peterson [EMAIL PROTECTED] added the comment: Could you explain what you mean be outdated please? It looks correct to me in the tag. http://svn.python.org/view/python/tags/r30rc1/Tools/scripts/2to3?rev=66500view=markup -- nosy: +benjamin.peterson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3981] Python 3, IDLE does not start
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: IDLE won't start with 3.0rc1 because of issue #3628. This has been corrected in r66518. -- nosy: +amaury.forgeotdarc resolution: - out of date status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3981 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3989] Tools\Scripts\2to3.py broken under 3.0 rc1 Windows
arnaud.faucher [EMAIL PROTECTED] added the comment: On a fresh win32 installation (using the 3.0rc1 MSI), the C:\Python30 \Tools\Scripts\2to3.py file contents is as follows: -- #!/usr/bin/env python from lib2to3 import refactor import sys sys.exit(refactor.main()) -- This version throws an error as follows: -- C:\Python30\Tools\ScriptsC:\Python30\python.exe 2to3.py Traceback (most recent call last): File 2to3.py, line 5, in module sys.exit(refactor.main()) AttributeError: 'module' object has no attribute 'main' -- It seems that the '.py' extendion of the 2to3 script was removed some time ago. Perhaps the MSI build process uses an old version of '2to3.py' and not the newer version of '2to3' (without the '.py' extension) ? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3990] The Linux2 platform definition is incorrect for alpha, hppa, mips, sparc
New submission from Thiemo Seufer [EMAIL PROTECTED]: The linux2 platform definition is incorrect for several architectures, namely Alpha, PA-RISC(hppa), MIPS and SPARC. On these architectures, Linux inherited some of the socket and dlfcn constants from the proprietary OS provided by the hardware manufacturer, which means they differ from the usual Linux constants. The appended patch against current SVN adresses this by introducing linux2-alpha, linux2-hppa, linux2-mips and linux2-sparc platforms. I changed only the incorrect constants on each platform and kept everything else the same. Bugs in the Debian Bugtracker related to this problem are: http://bugs.debian.org/499132 http://bugs.debian.org/500383 http://bugs.debian.org/500417 http://bugs.debian.org/500418 The first two bug reports carry patches for Python 2.5 and Python 2.4, respectively. The patch probably fixes also spurious python segfaults seen on the Debian Autobuilders for MIPS, since the RTLD_* constants for dlopen were incorrect. (That said, those segfaults are hard to reproduce, so this is a somewhat speculative conclusion.) -- components: Library (Lib) files: linux2-plat-upstream.diff keywords: patch messages: 73978 nosy: doko, ths severity: normal status: open title: The Linux2 platform definition is incorrect for alpha, hppa, mips, sparc type: behavior versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file11644/linux2-plat-upstream.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3990 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3988] Byte warning mode and b'' != ''
Antoine Pitrou [EMAIL PROTECTED] added the comment: +1 as well. Lib/pty.py had a line like that (while buf != '') and I wondered why no exception was thrown with -bb while the variable was a bytes object. -- nosy: +pitrou ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3988 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3956] turtle.py - bug in Screen.__init__()
Changes by Martin v. Löwis [EMAIL PROTECTED]: Added file: http://bugs.python.org/file11645/singleton.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3956] turtle.py - bug in Screen.__init__()
Changes by Martin v. Löwis [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file11643/singleton.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3989] Tools\Scripts\2to3.py broken under 3.0 rc1 Windows
Martin v. Löwis [EMAIL PROTECTED] added the comment: It was indeed the case that I had been packaging an unversioned file. I don't recall the details; most likely, it was a quick work-around for 2to3 not having a .py extension, yet the MSI generator only incorporating .py files from Scripts. I'll look into it. -- nosy: +loewis ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3255] [proposal] alternative for re.sub
Jeffrey C. Jacobs [EMAIL PROTECTED] added the comment: Implementing Issue 3482 should solve this problem, and I will try to add it to issue 2636 so that it is captured in the general Regexp 2.7 redesign. -- nosy: +timehorse versions: +Python 2.7 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3255 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3991] urllib.request.urlopen does not handle non-ASCII characters
New submission from Toshio Kuratomi [EMAIL PROTECTED]:
Tested on python-3.0rc1 -- Linux Fedora 9
I wanted to make sure that python3.0 would handle url's in different
encodings. So I created two files on an apache server which were named
½ñ.html. One of the filenames was encoded in utf-8 and the other in
latin-1. Then I tried the following::
from urllib.request import urlopen
url = 'http://localhost/u/½ñ.html'
urlopen(url.encode('utf-8')).read()
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python3.0/urllib/request.py, line 122, in urlopen
return _opener.open(url, data, timeout)
File /usr/lib/python3.0/urllib/request.py, line 350, in open
req.timeout = timeout
AttributeError: 'bytes' object has no attribute 'timeout'
The same thing happens if I give None for the two optional arguments
(data and timeout).
Next I tried using a raw Unicode string:
urlopen(url).read()
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python3.0/urllib/request.py, line 122, in urlopen
return _opener.open(url, data, timeout)
File /usr/lib/python3.0/urllib/request.py, line 359, in open
response = self._open(req, data)
File /usr/lib/python3.0/urllib/request.py, line 377, in _open
'_open', req)
File /usr/lib/python3.0/urllib/request.py, line 337, in _call_chain
result = func(*args)
File /usr/lib/python3.0/urllib/request.py, line 1082, in http_open
return self.do_open(http.client.HTTPConnection, req)
File /usr/lib/python3.0/urllib/request.py, line 1068, in do_open
h.request(req.get_method(), req.get_selector(), req.data, headers)
File /usr/lib/python3.0/http/client.py, line 843, in request
self._send_request(method, url, body, headers)
File /usr/lib/python3.0/http/client.py, line 860, in _send_request
self.putrequest(method, url, **skips)
File /usr/lib/python3.0/http/client.py, line 751, in putrequest
self._output(request.encode('ascii'))
UnicodeEncodeError: 'ascii' codec can't encode characters in position
7-8: ordinal not in range(128)
So, in python-3.0rc1, this method is badly broken.
--
components: Unicode
messages: 73982
nosy: a.badger
severity: normal
status: open
title: urllib.request.urlopen does not handle non-ASCII characters
versions: Python 3.0
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3991
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2650] re.escape should not escape underscore
Changes by Jeffrey C. Jacobs [EMAIL PROTECTED]: -- versions: +Python 2.7, Python 3.1 -Python 2.6, Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2650 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2650] re.escape should not escape underscore
Changes by Jeffrey C. Jacobs [EMAIL PROTECTED]: -- nosy: +timehorse ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2650 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1721518] Small case which hangs
Changes by Jeffrey C. Jacobs [EMAIL PROTECTED]: -- nosy: +timehorse versions: +Python 2.7 -Python 2.4 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1721518 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1721518] Small case which hangs
Jeffrey C. Jacobs [EMAIL PROTECTED] added the comment: Tested on 2.6rc2 and slow but successful. Issue 1662851 may be related. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1721518 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1693050] \w not helpful for non-Roman scripts
Changes by Jeffrey C. Jacobs [EMAIL PROTECTED]: -- nosy: +timehorse versions: +Python 2.7 -Python 2.4 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1693050 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2537] re.compile(r'((x|y+)*)*') should fail
Changes by Jeffrey C. Jacobs [EMAIL PROTECTED]: -- nosy: +timehorse versions: +Python 2.7 -Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2537 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1633953] re.compile((.*$){1,4}, re.MULTILINE) fails
Changes by Jeffrey C. Jacobs [EMAIL PROTECTED]: -- nosy: +timehorse versions: +Python 2.7 -Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1633953 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3988] Byte warning mode and b'' != ''
STINNER Victor [EMAIL PROTECTED] added the comment: Here is a patch for this issue. -- keywords: +patch nosy: +haypo Added file: http://bugs.python.org/file11646/bytes_ne_warning.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3988 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1282] re module needs to support bytes / memoryview well
Changes by Jeffrey C. Jacobs [EMAIL PROTECTED]: -- nosy: +timehorse ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1282 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue214033] re incompatibility in sre
Changes by Jeffrey C. Jacobs [EMAIL PROTECTED]: -- nosy: +timehorse ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue214033 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1708652] Exact matching
Changes by Jeffrey C. Jacobs [EMAIL PROTECTED]: -- nosy: +timehorse versions: +Python 2.7 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1708652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3988] Byte warning mode and b'' != ''
Christian Heimes [EMAIL PROTECTED] added the comment:
Thanks for the patch but you've missed a spot in bytearrayobject.c:
Objects/bytearrayobject.c:if (Py_BytesWarningFlag op == Py_EQ) {
Objects/bytesobject.c: if (Py_BytesWarningFlag (op == Py_EQ)
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3988
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1456280] Traceback error when compiling Regex
Changes by Jeffrey C. Jacobs [EMAIL PROTECTED]: -- nosy: +timehorse ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1456280 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3988] Byte warning mode and b'' != ''
Benjamin Peterson [EMAIL PROTECTED] added the comment: It would also be nice to have tests. (in test_bytes) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3988 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3939] Patch to implement a real ftplib test suite
Benjamin Peterson [EMAIL PROTECTED] added the comment: Thanks. That seems to have done the trick. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3939 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3990] The Linux2 platform definition is incorrect for alpha, hppa, mips, sparc
Martin v. Löwis [EMAIL PROTECTED] added the comment: I dislike the brute-force approach of this patch. IMO, a less intrusive solution should be found. -- nosy: +loewis ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3990 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3988] Byte warning mode and b'' != ''
STINNER Victor [EMAIL PROTECTED] added the comment: @christian.heimes: Oops, i totally forget the bytearray() type. Here is a new patch. Added file: http://bugs.python.org/file11647/bytes_ne_warning-2.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3988 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3988] Byte warning mode and b'' != ''
Changes by STINNER Victor [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file11646/bytes_ne_warning.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3988 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3988] Byte warning mode and b'' != ''
STINNER Victor [EMAIL PROTECTED] added the comment: I don't know how to activate BytesWarning as error (as python3 -bb does). Here is an patch for tests only working with python3 -bb. Added file: http://bugs.python.org/file11648/test_bytes.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3988 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3988] Byte warning mode and b'' != ''
Benjamin Peterson [EMAIL PROTECTED] added the comment: warnings.simplefilter(always, BytesWarning) should do the trick. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3988 ___ ___ 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
Martin v. Löwis [EMAIL PROTECTED] added the comment: I'd like to propose yet another approach: make sure that conversion according to the file system encoding always succeeds. If an unconvertable byte is detected, map it into some private-use character. To reduce the chance of conflict with other people's private-use characters, we can use some of the plane 15 private-use characters, e.g. map byte 0xPQ to U+F30PQ (in two-byte Unicode mode, this would result in a surrogate pair). This would make all file names accessible to all text processing (including glob and friends); UI display would typically either report an encoding error, or arrange for some replacement glyph to be shown. There are certain variations of the approach possible, in case there is objection to a specific detail. -- nosy: +loewis ___ 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
[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
Jesse Noller [EMAIL PROTECTED] added the comment: I've been thinking about this - Right now, having a working mp.synchronize module, and thread support is key to package currently. For 2.6 - it's really too late to try to mock up a working mp.synchronize module, or significantly change the package. My recommendation (I'm going to work on a patch to do this) is to not support fbsd/openbsd in this release cycle, which is unfortunate. Any other thoughts? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3770 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3941] Help in IDLE should open the chm file
Gregor Lingl [EMAIL PROTECTED] added the comment: I just found out, that this doesn't work correctly, because the Windows-helpfile in Python26rc2 is strangely named Python26c2.chm . It works correctly however if one renames this file to Python26.chm (as this is what the code in EditorWindow.py expects). So this will (almost certainly) be no problem in the final release. Regards, Gregor ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3941 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3956] turtle.py - bug in Screen.__init__()
Gregor Lingl [EMAIL PROTECTED] added the comment: I agree to Martin's patch for 2.6, because it seems to provide a more clean solution. And, as he states, there will be time and opportunity to discuss it more thoroughly later to possibly find another approach. As I remarked before I know that singleton+inheritance is a controversial subject. However the gang of four state in their book that one should use the singleton design pattern if one needs exactly one instance af a class and this should be extensible by subclassing ... (And there are reasons why I'd like to have Screen() subclassable.) Anyway, I think there are two more things to do: 1) Add a docstring to the Screen() function 2) Insert (at least) one sentence in the docs, 9.th paragraph of the Introduction. Something like: ... so there can exist only one instance of Screen at a time. *Notice that consequently Screen cannot be sublassed.* It should be used when turtle is used as a standalone tool for doing graphics. ... Perhaps one should also note, that the singleton object is returned by a function. I've applied the proposed patch (file11645) to a working copy and I've tested it in interactive mode as well as with turtleDemo and all the supplied demoscripts and found it to work well. Last, but not least: thanks Martin for your contribution. Regards, Gregor ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3981] Python 3, IDLE does not start
bahiminin [EMAIL PROTECTED] added the comment: Hi Thank you. I found that file. r66518. My IDLE work now. Take care. On Sun, Sep 28, 2008 at 9:38 AM, Amaury Forgeot d'Arc [EMAIL PROTECTED] wrote: Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: IDLE won't start with 3.0rc1 because of issue #3628. This has been corrected in r66518. -- nosy: +amaury.forgeotdarc resolution: - out of date status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3981 ___ Added file: http://bugs.python.org/file11649/unnamed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3981 ___div dir=ltrHibrThank you. I found that file. r66518. My IDLE work now. Take care.brbrdiv class=gmail_quoteOn Sun, Sep 28, 2008 at 9:38 AM, Amaury Forgeot d#39;Arc span dir=ltrlt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt;/span wrote:br blockquote class=gmail_quote style=border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;br Amaury Forgeot d#39;Arc lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt; added the comment:br br IDLE won#39;t start with 3.0rc1 because of issue #3628.br This has been corrected in r66518.br br --br nosy: +amaury.forgeotdarcbr resolution: nbsp;-gt; out of datebr status: open -gt; closedbr divdiv/divdiv class=Wj3C7cbr ___br Python tracker lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt;br lt;a href=http://bugs.python.org/issue3981; target=_blankhttp://bugs.python.org/issue3981/agt;br ___br /div/div/blockquote/divbr/div ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3992] removed custom log from distutils
New submission from Tarek Ziadé [EMAIL PROTECTED]: This patch removes the custom log implementation from distutils. It keeps the compatibility with the previous logger and its specific CONSTANTE names. It add a sys.stdout stream handler so it produces the same output. It is based on logging now, and a logger for distutils is created at the root of the package. The patch does not introduce any deprecation warning though, on distutils.log usage, but maybe that could be a good idea, so the people that use distutils.log know they should use distutils.logger. (I don't know how the deprecation process works in Python) -- components: Distutils files: remove-custom-log.diff keywords: patch messages: 73997 nosy: tarek severity: normal status: open title: removed custom log from distutils versions: Python 2.6 Added file: http://bugs.python.org/file11650/remove-custom-log.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3992] removed custom log from distutils
Christian Heimes [EMAIL PROTECTED] added the comment: Hey Tarek! I fear most of your revisions - including this - can make it into 2.6 and 3.0. Python 2.6 and 3.0 are now in maintenance mode. Your patch doesn't fall under the category bug fix. You have to target 2.7 and 3.1. -- nosy: +christian.heimes ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3992 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3947] configure --with-threads on cygwin = crash on thread related tests
Changes by Hirokazu Yamamoto [EMAIL PROTECTED]: -- components: +Extension Modules priority: - critical versions: +Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3947 ___ ___ 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
Guido van Rossum [EMAIL PROTECTED] added the comment: You can call it a leaky abstraction all you want, but most people think of filenames as text strings most of the time, and we need to somehow support this, at least for users who agree . I agree we also need to support bytes strings (at least on Unix) in order to support backup routines, and support for bytes in - bytes out in os.listdir() is meant for this. The open() function should also support a pure bytes filename (and almost does so -- _fileio does, but io.py doesn't yet). os.getcwd() is a weird case and will probably need to be given a flag to make it return bytes (I don't like that style of API much, but the alternative is perhaps worse -- os.getcwd_bytes()). Conclusion: I support patches that make the I/O library work with either bytes or strings. (It's OK if the bytes don't actually work on Windows, where the native type is apparently strings -- though it has a bytes API too, doesn't it?) ___ 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
[issue3984] python interpreter import dependency with disutils/util
Brett Cannon [EMAIL PROTECTED] added the comment: I can't find the bug right now, but this has been brought up before. Since it is only on posix systems and only when running in a code checkout, no one has worried about it enough to change it. And I am not sure if it is necessarily worth pulling out of distutils just for this one use-case. But if a patch came about that might help push it forward. -- nosy: +brett.cannon ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3984 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3984] python interpreter import dependency with disutils/util
Benjamin Peterson [EMAIL PROTECTED] added the comment: Brett, are you looking for #586680? -- nosy: +benjamin.peterson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3984 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3895] _lsprof issue
Changes by Brett Cannon [EMAIL PROTECTED]: -- assignee: - brett.cannon ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3895 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3895] _lsprof issue
Brett Cannon [EMAIL PROTECTED] added the comment: 2.6 is fixed in r66677 and 2.5 in r66678. 3.0 has not been applied yet as test_cProfile is still currently listed as a broken test. So I am blocking 66677 on py3k for now. -- priority: release blocker - deferred blocker versions: -Python 2.5, Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3895 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3910] 2.6 regression in socket.ssl method
Brett Cannon [EMAIL PROTECTED] added the comment: It looks like no one objected. Can you check this in, Bill? -- nosy: +brett.cannon ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3910 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
Brett Cannon [EMAIL PROTECTED] added the comment: Well, even if 2.6 slipped (which it is looking probably won't happen), how much time would you need to deal with this? Sounds like you just won't be able to get to it even with an extra week. So that means multiprocessing is just not supported on FreeBSD and OpenBSD at this moment. Sucks, but hopefully it can get fixed in the future. And if people complain, bug them to get a reliable buildbot going. -- nosy: +brett.cannon ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3770 ___ ___ 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
Martin v. Löwis [EMAIL PROTECTED] added the comment: 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! Correct. 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. I'm not so sure about that. Practicality beats purity. Your proposal would make it impossible to write a robust remote backup tool in Python 3. There could be an option to set the file system encoding via an API to some known safe value, such as Latin-1, or ASCII. If you set the file system encoding to Latin-1, this escaping would never happen; if you set it to ASCII, it would happen uniformly for all non-ASCII bytes. The robust backup tool would have to know to set this option on POSIX systems. Pathnames on ext3/Linux *are not Unicode*. Blindly pretending they're Unicode is a leaky abstraction at best, and a security hole at worst. I think most Linux users would disagree, and claim that file names are indeed character strings (which is synonym to being Unicode). It is technically true that it's possible to create file names which are not text, but that's really a bug, not a feature - Unix and POSIX were never intended to work this way. Also, in the overwhelming majority of Python applications, consistent support for practically-existing systems matters more than robustness against malicious users. ___ 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
Martin v. Löwis [EMAIL PROTECTED] added the comment: I agree we also need to support bytes strings (at least on Unix) in order to support backup routines How about letting such applications set the file system encoding to Latin-1? ___ 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
Martin v. Löwis [EMAIL PROTECTED] added the comment: James Knight points out that UTF-8b can be used to give unambiguous round-tripping of characters in a UTF-8 locale. So I would like to amend my previous proposal: - for a non-UTF-8 encoding, use private-use characters for roundtripping - if the locale's charset is UTF-8, use UTF-8b as the file system encoding. ___ 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
[issue3993] Convert documentation to python 3.
New submission from David W. Lambert [EMAIL PROTECTED]: http://docs.python.org/dev/3.0/library/multiprocessing.html#module- multiprocessing uses print statement in pre-version 3 form. I can easily imagine that this and similar 2to3 bugs pervade the manual. (If I insisted on foolish consistency I'd point out also that the multiprocessing guidelines recommend joining all processes started, but that a few items later under joining processes that use queues hides the parenthetical remark ... (or simply remove the p.join() line).) At any rate, I'm looking forward to the 3.0 release. And I'm thrilled that the library modules seem to be evolving toward lumps that are commonly used together. -- assignee: georg.brandl components: Documentation messages: 74009 nosy: LambertDW, georg.brandl severity: normal status: open title: Convert documentation to python 3. versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3993 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
