Control Centre

\n \n \n \n The GNOME Control Centre provides a central place for the user to setup their GNOME experience. It can let you configure anything from the behaviour of your window borders to the default font type.\n ' >>> import xml.etree.ElementTree as etree >>> xml = etree.parse(file) >>> temp = "temp.xml" >>> xml.write("temp.xml", encoding="utf-8") >>> open(temp).read()[:500] '

\n \n \n \n The GNOME Control Centre provides a central place for the user to setup their GNOME experience. It can let you configure anything from the behaviour of your window borders to the default font type.\n \n Control Centre\n \n \n\tKevinBreit\n \n \n \n >> ---------- components: Library (Lib) messages: 112961 nosy: mark priority: normal severity: normal status: open title: xml.etree.ElementTree strips XML declaration and procesing instructions type: behavior versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 5 11:32:10 2010 From: report at bugs.python.org (Mark Summerfield) Date: Thu, 05 Aug 2010 09:32:10 +0000 Subject: [New-bugs-announce] [issue9522] xml.etree.ElementTree forgets the encoding In-Reply-To: <1281000730.31.0.804989593298.issue9522@psf.upfronthosting.co.za> Message-ID: <1281000730.31.0.804989593298.issue9522@psf.upfronthosting.co.za> New submission from Mark Summerfield : If you read in an XML file that specifies its encoding and then later on use xml.etree.ElementTree.write(), it is always written using US-ASCII. I think the behaviour should be different: (1) If the XML that was read included an encoding, that encoding should be remembered and used when writing. (2) If there is no encoding the default for writing should be UTF-8 (which is the standard for XML files). (3) For non-XML files use US-ASCII. Naturally, any of these could be overridden using an encoding argument to the write() method. ---------- components: Library (Lib) messages: 112962 nosy: mark priority: normal severity: normal status: open title: xml.etree.ElementTree forgets the encoding type: behavior versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 5 17:23:57 2010 From: report at bugs.python.org (Ray.Allen) Date: Thu, 05 Aug 2010 15:23:57 +0000 Subject: [New-bugs-announce] [issue9523] Improve dbm module In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za> Message-ID: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za> New submission from Ray.Allen : During the patching work of issue8634, I found several problems about the module dbm.gnu and dbm.ndbm, I feel it's better to address them on a separate issue. 1. As issue8634 said, the dbm.gnu, dbm.ndbm and dbm.dumb should have the similar interface, since they are intended to use the general dbm module as a common interface. If some methods only appears in one or two of them, like the "get()" method, it will be not convenient for users. Making all the three ones follow the collections.MutableMapping interface could be a better choice. Since the dbm.dumb is already collections.MutableMapping, I implemented missing methods of collections.MutableMapping in dbm.gnu and dbm.ndbm, and register the dbm object type in dbm.gnu and dbm.ndbm to the ABC. The missing methods mainly include get(), values(), items(), pop(), popitem(), clear() 2. I fix the dbm_contains() function which implement the "in" operator to accept all buffer object, just like the dbm_subscript() fuction which implment the "[]" slice operator. I feel it's wearied that if "dbm['a']" yields the expected result but at the same time "'a' in dbm" raises TypeError. 3. The type of dbm object in dbm.gnu is not iterable, and there is no way to iterate on it sufficiently because the only way we can iterate over it is to get all the keys first using keys() and then iter on the keys list. So I implemented a iterator type for dbm.gnu. Besides the dbm object in dbm.ndbm is also not iterable, and I implemented its tp_iter by get an iterator from its keys list instead of implementing a "real" iterator since the ndbm c api for get all the keys one by one is thread specific and I could not found a way to implement a real iterator to avoid the problem which occurred in the case we get tow iterators from one db object in the same thread and iterate over both at the same time. The patch contains also unittest and doc. ---------- files: issue8634.diff keywords: patch messages: 112989 nosy: ysj.ray priority: normal severity: normal status: open title: Improve dbm module Added file: http://bugs.python.org/file18402/issue8634.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 5 20:21:47 2010 From: report at bugs.python.org (Valentine Gogichashvili) Date: Thu, 05 Aug 2010 18:21:47 +0000 Subject: [New-bugs-announce] [issue9524] CTRL_C_EVENT and CTRL_BREAK_EVENT cannot be registered by signal.signal() method on windows In-Reply-To: <1281032507.28.0.881221183962.issue9524@psf.upfronthosting.co.za> Message-ID: <1281032507.28.0.881221183962.issue9524@psf.upfronthosting.co.za> New submission from Valentine Gogichashvili : When executing the following code on Windows 7 64-bit :: import sys import signal import time print 'Version:' print sys.executable or sys.platform, sys.version print print def h(s, f): print s signal.signal(signal.CTRL_BREAK_EVENT, h) we get the following output:: Version: C:\Python27\python.exe 2.7 (r27:82525, Jul 4 2010, 07:43:08) [MSC v.1500 64 bit (AMD64)] Traceback (most recent call last): File "signal_ctrl_break_event.py", line 14, in signal.signal(signal.CTRL_BREAK_EVENT, h) RuntimeError: (0, 'Error') When trying to register a handler for a signal.CTRL_C_EVENT the exception is as follows:: File "signal_ctrl_c_event.py", line 6, in signal.signal(signal.CTRL_C_EVENT, h) ValueError: signal number out of range ---------- components: Library (Lib), Windows messages: 113005 nosy: valgog priority: normal severity: normal status: open title: CTRL_C_EVENT and CTRL_BREAK_EVENT cannot be registered by signal.signal() method on windows type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 5 21:55:12 2010 From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=) Date: Thu, 05 Aug 2010 19:55:12 +0000 Subject: [New-bugs-announce] [issue9525] webbrowser: open new tab in unobtrusive way In-Reply-To: <1281038112.98.0.544015088878.issue9525@psf.upfronthosting.co.za> Message-ID: <1281038112.98.0.544015088878.issue9525@psf.upfronthosting.co.za> New submission from Filip Gruszczy?ski : webbrowser module doesn't allow to open url in an unobtrusive way. Right now if browser is minimized it is brought to the top. Furthermore if you browser is already in the top, new tab is opened and user is moved to this top. It would be useful, if tab could be opened in background (just like when you open a link in chrome in new tab, new tab is created, but you stay in current window). ---------- components: Library (Lib) messages: 113034 nosy: gruszczy priority: normal severity: normal status: open title: webbrowser: open new tab in unobtrusive way type: feature request versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 6 04:20:54 2010 From: report at bugs.python.org (Martin Frith) Date: Fri, 06 Aug 2010 02:20:54 +0000 Subject: [New-bugs-announce] [issue9526] 2 GB limit in array module In-Reply-To: <1281061254.05.0.356539300127.issue9526@psf.upfronthosting.co.za> Message-ID: <1281061254.05.0.356539300127.issue9526@psf.upfronthosting.co.za> New submission from Martin Frith : The array module does not seem to work for arrays > 2 GB. >>> import sys, array >>> sys.maxsize 9223372036854775807 >>> x = array.array('c', ('a' for i in xrange(300000000))) (seems to work OK) >>> x = array.array('c', ('a' for i in xrange(3000000000))) (runs forever: memory usage increases to 2GB and then stops) I think the cause is: casting to int in arraymodule.c, in array_iter_extend() and array_append(). My uname -a: Linux c016 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux ---------- components: Extension Modules messages: 113061 nosy: mcfrith priority: normal severity: normal status: open title: 2 GB limit in array module type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 6 05:48:20 2010 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 06 Aug 2010 03:48:20 +0000 Subject: [New-bugs-announce] [issue9527] Add aware local time support to datetime module In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za> Message-ID: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za> New submission from Alexander Belopolsky : See python-dev post for motivation. http://mail.python.org/pipermail/python-dev/2010-August/102842.html I am attaching a patch implementing the proposed method in datetime.py. I will also paste the code below. Note that this is only prototype. Real implementation will use tm_zone and tm_gmtoff components of tm structure on platforms that supply them. @classmethod def localtime(cls, t=None, isdst=-1): """Return local time as an aware datetime object. If called without arguments, return current time. Otherwise *t* is converted to local time zone according to the system time zone database. If *t* is naive (i.e. t.tzinfo is None), it is assumed to be in local time. In this case, a positive or zero value for *isdst* causes localtime to presume initially that summer time (for example, Daylight Saving Time) is or is not (respectively) in effect for the specified time. A negative value for *isdst* causes the localtime() function to attempt to divine whether summer time is in effect for the specified time. """ if t is None: t = _time.time() else: if t.tzinfo is None: tm = t.timetuple()[:-1] + (isdst,) t = _time.mktime(tm) else: delta = t - datetime(1970, 1, 1, tzinfo=timezone.utc) t = delta.total_seconds() tm = _time.localtime(t) if _time.daylight: if tm.tm_isdst: offset = _time.altzone tzname = _time.tzname[1] else: offset = _time.timezone tzname = _time.tzname[0] tz = timezone(timedelta(seconds=-offset), tzname) return cls.fromtimestamp(t, tz) ---------- assignee: belopolsky components: Extension Modules, Library (Lib) files: datetime-localtime-proto.diff keywords: patch messages: 113067 nosy: belopolsky priority: normal severity: normal status: open title: Add aware local time support to datetime module type: feature request versions: Python 3.2 Added file: http://bugs.python.org/file18410/datetime-localtime-proto.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 6 06:33:23 2010 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 06 Aug 2010 04:33:23 +0000 Subject: [New-bugs-announce] [issue9528] Add pure Python implementation of time module to CPython In-Reply-To: <1281069203.79.0.816772507809.issue9528@psf.upfronthosting.co.za> Message-ID: <1281069203.79.0.816772507809.issue9528@psf.upfronthosting.co.za> New submission from Alexander Belopolsky : The original RFE at issue 7989 was: """ After discussion on numerous issues, python-dev, and here at the PyCon sprints, it seems to be a good idea to move timemodule.c to _timemodule.c and convert as much as possible into pure Python. The same change seems good for datetime.c as well. """ See msg99774. I have changed issue 7989 to cover datetime only because I argued that as a thin wrapper around C library calls, this module is an exception to the general rule that pure python implementations are a good idea. See msg107303. No I realize that in order to break circular dependency between time and datetime modules, it will be helpful to create an _time module that would provide lower than time module access to system facilities and datetime and time modules would be use _time module to implement higher level interfaces either in C or in Python. I believe _time module should become the home of the gettimeofday() method and pure python implementation of time.time() will be def time() s, us = _time.gettimeofday() return s + 1e-6 * us Similarly time.sleep() can be implemented in terms of lower level POSIX nanosleep() method. Lower level localtime() function can provide access to tm_zone and tm_gmtoff members of struct tm (where available) without concerns about backward compatibility. ---------- assignee: belopolsky components: Extension Modules, Library (Lib) messages: 113073 nosy: amaury.forgeotdarc, belopolsky, brett.cannon, brian.curtin, davidfraser, durban, giampaolo.rodola, haypo, lemburg, mark.dickinson, merwok, pitrou, r.david.murray, rhettinger, techtonik, tim_one priority: normal severity: normal status: open title: Add pure Python implementation of time module to CPython type: feature request versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 6 07:41:04 2010 From: report at bugs.python.org (MizardX) Date: Fri, 06 Aug 2010 05:41:04 +0000 Subject: [New-bugs-announce] [issue9529] Converge re.findall and re.finditer In-Reply-To: <1281073264.71.0.30355123146.issue9529@psf.upfronthosting.co.za> Message-ID: <1281073264.71.0.30355123146.issue9529@psf.upfronthosting.co.za> New submission from MizardX : re.findall and re.finditer has very different signature. One iterates over match objects, the other returns a list of tuples. I can think of two ways to make them more similar: 1) Make match objects iterable over their captures. With this, you could write something like the following: for key,value in re.finditer(r'(\w+):(\w+)', text): data[key] = value 2) Make re.findall return an iterator over tuples. This would decrease the memory footprint. ---------- components: Regular Expressions messages: 113074 nosy: MizardX priority: normal severity: normal status: open title: Converge re.findall and re.finditer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 6 08:16:26 2010 From: report at bugs.python.org (John Regehr) Date: Fri, 06 Aug 2010 06:16:26 +0000 Subject: [New-bugs-announce] [issue9530] integer undefined behaviors In-Reply-To: <1281075386.13.0.164742828093.issue9530@psf.upfronthosting.co.za> Message-ID: <1281075386.13.0.164742828093.issue9530@psf.upfronthosting.co.za> New submission from John Regehr : I ran "make test" for today's Python3k snapshot under a tool which detects math operations that the C language considers to have undefined behavior. This was on x86 Linux. The list of undefined behaviors is attached. Hopefully they are self-explanatory, but please let me know if more details are needed. ---------- files: python-errors.txt messages: 113079 nosy: regehr priority: normal severity: normal status: open title: integer undefined behaviors type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file18412/python-errors.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 6 09:05:25 2010 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 06 Aug 2010 07:05:25 +0000 Subject: [New-bugs-announce] [issue9531] test_complex.py fails In-Reply-To: <1281078325.63.0.509083627436.issue9531@psf.upfronthosting.co.za> Message-ID: <1281078325.63.0.509083627436.issue9531@psf.upfronthosting.co.za> New submission from Eli Bendersky : eliben at eliben-desktop:~/python_src/svn-27-maint/Lib/test$ py27 regrtest.py test_complex.py test_complex test test_complex failed -- Traceback (most recent call last): File "/home/eliben/python_src/27-maint/Lib/test/test_complex.py", line 563, in test_format self.assertEqual(format(z, '-'), str(z)) AssertionError: '(+3j)' != '3j' 1 test failed: test_complex [36603 refs] ---------- messages: 113081 nosy: eli.bendersky priority: normal severity: normal status: open title: test_complex.py fails versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 6 11:30:12 2010 From: report at bugs.python.org (denny) Date: Fri, 06 Aug 2010 09:30:12 +0000 Subject: [New-bugs-announce] [issue9532] pipe.read hang, when calling commands.getstatusoutput in multi-threading code of python 2.4 In-Reply-To: <1281087012.75.0.995842004424.issue9532@psf.upfronthosting.co.za> Message-ID: <1281087012.75.0.995842004424.issue9532@psf.upfronthosting.co.za> New submission from denny : Hi all My environment is python 2.4.4 on linux. I am encountering hang of pipe.read() in commands.getstatusoutput for multi-threading code. I have spawned several threads which will call commands.getstatusoutput to run cli. However, pipe.read may hang sometimes. >From lsof, we know some pipe handles are not closed in the parent process, after the child process is stopped. ;; -------------------------- Reproduce steps -------------------------- Below are reproduce steps. # Create a python script of /tmp/hang.py, whose content is given below. # Run "service crond stop; python /tmp/hang.py" several times. # The script may probably hang. From lsof of main.py and crond service, we may find one pipe existing in both processes. # If we stop crond to close the pipe, the hang of hang.py will be resolved. ;; -------------------------- Code of hang.py -------------------------- #!/usr/bin/python import commands import datetime import time import os import thread import threading def thread_run1(): cmd = "hostname" print "begin to run command:%s" % (cmd) status, output = commands.getstatusoutput(cmd) print "pid:%d, name:%s, status:%d, output:%s" % \ (os.getpid(), threading.currentThread().getName(), status, output) cmd = "ifconfig eth0" print "begin to run command:%s" % (cmd) status, output = commands.getstatusoutput(cmd) print "pid:%d, name:%s, status:%d, output:%s" % \ (os.getpid(), threading.currentThread().getName(), status, output) cmd = "ifconfig eth1" print "begin to run command:%s" % (cmd) status, output = commands.getstatusoutput(cmd) print "pid:%d, name:%s, status:%d, output:%s" % \ (os.getpid(), threading.currentThread().getName(), status, output) # cmd = "sh /tmp/subprocess.sh" cmd = "echo here1; sleep 2; echo here2; sleep 5" print "begin to run command:%s" % (cmd) status, output = commands.getstatusoutput(cmd) print "pid:%d, name:%s, status:%d, output:%s" % \ (os.getpid(), threading.currentThread().getName(), status, output) def thread_run2(): cmd = "service crond start" print "begin to run command:%s" % (cmd) status, output = commands.getstatusoutput(cmd) print "pid:%d, name:%s, status:%d, output:%s" % \ (os.getpid(), threading.currentThread().getName(), status, output) if __name__=='__main__': print "main function begins." thread_list = [] for i in xrange(1, 10): my_thread = threading.Thread(target = thread_run1) thread_list.append(my_thread) my_thread = threading.Thread(target = thread_run2) thread_list.append(my_thread) for t in thread_list: t.start() time.sleep(10) for t in thread_list: t.join() print "main function ends." ---------- components: Library (Lib) messages: 113086 nosy: denny priority: normal severity: normal status: open title: pipe.read hang, when calling commands.getstatusoutput in multi-threading code of python 2.4 type: behavior versions: 3rd party _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 6 12:33:39 2010 From: report at bugs.python.org (Roald de Vries) Date: Fri, 06 Aug 2010 10:33:39 +0000 Subject: [New-bugs-announce] [issue9533] metaclass can't derive from ABC In-Reply-To: <1281090819.15.0.255356922996.issue9533@psf.upfronthosting.co.za> Message-ID: <1281090819.15.0.255356922996.issue9533@psf.upfronthosting.co.za> New submission from Roald de Vries : Exception raised:: Traceback (most recent call last): File "bug.py", line 5, in class derived(type, Sized): File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/abc.py", line 85, in __new__ for name in getattr(base, "__abstractmethods__", set()): TypeError: Error when calling the metaclass bases 'getset_descriptor' object is not iterable ---------- files: bug.py messages: 113094 nosy: roalddevries priority: normal severity: normal status: open title: metaclass can't derive from ABC type: compile error versions: Python 2.6 Added file: http://bugs.python.org/file18414/bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 6 13:48:06 2010 From: report at bugs.python.org (Valentine Gogichashvili) Date: Fri, 06 Aug 2010 11:48:06 +0000 Subject: [New-bugs-announce] [issue9534] OrderedDict.__del__ destructor throws AttributeError when process ends up with the exception trace In-Reply-To: <1281095286.81.0.328749516858.issue9534@psf.upfronthosting.co.za> Message-ID: <1281095286.81.0.328749516858.issue9534@psf.upfronthosting.co.za> New submission from Valentine Gogichashvili : When the process is dying with the exception trace dump, I am getting the following notification from the destructor of the OrderedDict class:: Exception AttributeError: "'NoneType' object has no attribute 'print_exc'" in ignored In the source of the OrderedDict the only operation that is not included in the try..catch is the dict.clear(self) actually. So I suppose that this problem is in dict.clear() implementation... ---------- components: Library (Lib), Windows messages: 113096 nosy: valgog priority: normal severity: normal status: open title: OrderedDict.__del__ destructor throws AttributeError when process ends up with the exception trace type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 6 16:43:15 2010 From: report at bugs.python.org (Greg Brockman) Date: Fri, 06 Aug 2010 14:43:15 +0000 Subject: [New-bugs-announce] [issue9535] Pending signals are inherited by child processes In-Reply-To: <1281105795.17.0.408658965128.issue9535@psf.upfronthosting.co.za> Message-ID: <1281105795.17.0.408658965128.issue9535@psf.upfronthosting.co.za> New submission from Greg Brockman : Upon os.fork(), pending signals are inherited by the child process. This can be demonstrated by pressing C-c in the middle of the following program: """ import os, sys, time, threading def do_fork(): while True: if not os.fork(): print 'hello from child' sys.exit(0) time.sleep(0.5) t = threading.Thread(target=do_fork) t.start() t.join() """ Right after os.fork(), each child will raise a KeyboardInterrupt exception. This behavior is different from the semantics of POSIX fork(), where child processes do not inherit their parents' pending signals. Attached is a first stab at a patch to fix this issue. Please let me know what you think! ---------- components: Extension Modules files: signals.patch keywords: patch messages: 113104 nosy: gdb priority: normal severity: normal status: open title: Pending signals are inherited by child processes type: behavior versions: Python 2.5, Python 2.6, Python 2.7 Added file: http://bugs.python.org/file18416/signals.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 6 16:55:28 2010 From: report at bugs.python.org (John Posner) Date: Fri, 06 Aug 2010 14:55:28 +0000 Subject: [New-bugs-announce] [issue9536] defaultdict doc makes incorrect reference to __missing__ method In-Reply-To: <1281106528.37.0.0435364267174.issue9536@psf.upfronthosting.co.za> Message-ID: <1281106528.37.0.0435364267174.issue9536@psf.upfronthosting.co.za> New submission from John Posner : The documentation for collections.defaultdict is confusing with respect to the __missing__ method. The fact is that a programmer using defaultdict does not need to know anything about __missing__. The attached patch contains a rewrite of the entire section (but not the "defaultdict Examples" section, which is fine. ---------- assignee: docs at python components: Documentation files: defaultdict.patch keywords: patch messages: 113105 nosy: docs at python, jjposner priority: normal severity: normal status: open title: defaultdict doc makes incorrect reference to __missing__ method versions: Python 2.7 Added file: http://bugs.python.org/file18417/defaultdict.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 6 21:31:33 2010 From: report at bugs.python.org (Denver Coneybeare) Date: Fri, 06 Aug 2010 19:31:33 +0000 Subject: [New-bugs-announce] [issue9537] argparse: use OrderedDict to store subparsers In-Reply-To: <1281123093.44.0.485972410524.issue9537@psf.upfronthosting.co.za> Message-ID: <1281123093.44.0.485972410524.issue9537@psf.upfronthosting.co.za> New submission from Denver Coneybeare : Currently, when a subparser is added to an argparse.ArgumentParser the list of subparsers are stored in the built-in dict type. When these subparsers are listed when -h is given on the command line they are showed in the order returned from the dictionary's keys() method, which is undefined order. Instead of showing them in undefined order, it would be preferred to show them at least in the order in which they were added. This can be done trivially be replacing the dict with a collections.OrderedDict. A patch is attached. ---------- components: Library (Lib) files: argparse.patch keywords: patch messages: 113124 nosy: benjamin.peterson, denversc priority: normal severity: normal status: open title: argparse: use OrderedDict to store subparsers type: behavior versions: Python 2.7, Python 3.3 Added file: http://bugs.python.org/file18418/argparse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 7 22:04:39 2010 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 07 Aug 2010 20:04:39 +0000 Subject: [New-bugs-announce] [issue9538] Replace confusing pseudoname 'object' in special methods section. In-Reply-To: <1281211479.21.0.733519342396.issue9538@psf.upfronthosting.co.za> Message-ID: <1281211479.21.0.733519342396.issue9538@psf.upfronthosting.co.za> New submission from Terry J. Reedy : In 3.3. Special method names, 'object' is used as a pseudo class name to prefix all the special method entries. This conflicts with the usual two Python meanings. 1. 'object' is the name of a specific class. So the entry for object.__getattribute__(self, name) says to avoid circularity by calling object.__getattribute__(self, name), which looks circular and requires a bit a mental work by the reader to properly understand. Ditto for object.__setattr__(self, name, value) calling object.__setattr__(self, name, value) 2. Non-specifically, 'object' is usually understood to mean any Python object, not just a class. But the signatures as written require that 'object' specifically be a class and 'object' does not convey that. So for both reasons, I propose that the pseudoname 'object' be replaces with 'class' or 'someclass' ---------- assignee: docs at python components: Documentation messages: 113194 nosy: docs at python, georg.brandl, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Replace confusing pseudoname 'object' in special methods section. versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 8 01:13:15 2010 From: report at bugs.python.org (Valeo de Vries) Date: Sat, 07 Aug 2010 23:13:15 +0000 Subject: [New-bugs-announce] [issue9539] python-2.6.4: test failure in test_distutils due to linking to system libpython2.6 In-Reply-To: <1281222795.64.0.211558756173.issue9539@psf.upfronthosting.co.za> Message-ID: <1281222795.64.0.211558756173.issue9539@psf.upfronthosting.co.za> New submission from Valeo de Vries : I'm under the impression that this is issue is known about, however I couldn't find an existing bug, so I'm creating a new one for the following test failure: test_distutils /usr/lib/gcc/i686-pc-linux-gnu/4.4.4/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lpython2.6 collect2: ld returned 1 exit status test test_distutils failed -- Traceback (most recent call last): File "/var/tmp/paludis/build/dev-lang-python-2.6.4-r1/work/Python-2.6.4/Lib/distutils/tests/test_build_ext.py", line 258, in test_get_outputs cmd.run() File "/var/tmp/paludis/build/dev-lang-python-2.6.4-r1/work/Python-2.6.4/Lib/distutils/command/build_ext.py", line 340, in run self.build_extensions() File "/var/tmp/paludis/build/dev-lang-python-2.6.4-r1/work/Python-2.6.4/Lib/distutils/command/build_ext.py", line 449, in build_extensions self.build_extension(ext) File "/var/tmp/paludis/build/dev-lang-python-2.6.4-r1/work/Python-2.6.4/Lib/distutils/command/build_ext.py", line 531, in build_extension target_lang=language) File "/var/tmp/paludis/build/dev-lang-python-2.6.4-r1/work/Python-2.6.4/Lib/distutils/ccompiler.py", line 848, in link_shared_object extra_preargs, extra_postargs, build_temp, target_lang) File "/var/tmp/paludis/build/dev-lang-python-2.6.4-r1/work/Python-2.6.4/Lib/distutils/unixccompiler.py", line 265, in link raise LinkError, msg LinkError: command 'i686-pc-linux-gnu-gcc' failed with exit status 1 Perhaps I'm missing something here, but surely trying to link against the system (i.e. already installed, pre-existing) libpython2.6 defeats the purpose of having a testsuite, if you're not actually going to be testing what you're actually installing? Any enlightenment here would be appreciated. ---------- components: Tests messages: 113217 nosy: valeo priority: normal severity: normal status: open title: python-2.6.4: test failure in test_distutils due to linking to system libpython2.6 versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 8 03:26:45 2010 From: report at bugs.python.org (=?utf-8?q?Michael=2EElsd=C3=B6rfer?=) Date: Sun, 08 Aug 2010 01:26:45 +0000 Subject: [New-bugs-announce] [issue9540] argparse: combine subparsers with global positional args In-Reply-To: <1281230805.22.0.0952279078785.issue9540@psf.upfronthosting.co.za> Message-ID: <1281230805.22.0.0952279078785.issue9540@psf.upfronthosting.co.za> New submission from Michael.Elsd?rfer : >>> parser = argparse.ArgumentParser() >>> subparsers = parser.add_subparsers(title="commands") >>> subparser = subparsers.add_parser('make') >>> parser.add_argument('jobs', nargs='*') >>> parser.print_help() usage: [-h] {make} ... [jobs [jobs ...]] While the printed usage looks innocuous enough, argparser isn't actually able to parse this the way I expect: The positional argument never get's to handle any jobs given, as apparently everything after the command is handled by the subparser: >>> parser.parse_args(['make', 'something']) usage: make [-h] make: error: unrecognized arguments: something It seems that argparse, upon determining that the subparser can't handle a positional argument, could break out of the subparser, and let the parent parser continue. If necessary, as further help for argparse on how to resolve such situations, a parameter could be added to add_subparsers() which would allow the user to indicate that this group of subparsers should not support positional arguments. The usage string should then print as: >>> parser.print_help() usage: [-h] {make} [jobs [jobs ...]] That is, without the "..." after the command. Finally, if it is decided that the feature will not be added, argparse should not allow the user to add positional arguments after a subparser. ---------- components: Library (Lib) messages: 113229 nosy: elsdoerfer priority: normal severity: normal status: open title: argparse: combine subparsers with global positional args type: feature request versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 8 06:08:19 2010 From: report at bugs.python.org (Joe Amenta) Date: Sun, 08 Aug 2010 04:08:19 +0000 Subject: [New-bugs-announce] [issue9541] node.pre_order() does not do preorder traversal In-Reply-To: <1281240499.35.0.988494777631.issue9541@psf.upfronthosting.co.za> Message-ID: <1281240499.35.0.988494777631.issue9541@psf.upfronthosting.co.za> New submission from Joe Amenta : In Lib/lib2to3/pytree.py, Node.pre_order() calls the post_order() method of its children, instead of pre_order(). As a result, the only difference between the two orderings is that pre_order() yields the original node first, whereas post_order() yields the original node last. It seems highly unlikely to me that any code would depend on this behavior. The fix, of course, is trivial: change the call to child.post_order() on line 289 into a call to child.pre_order(). ---------- components: 2to3 (2.x to 3.0 conversion tool) messages: 113233 nosy: joe.amenta priority: normal severity: normal status: open title: node.pre_order() does not do preorder traversal type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 9 01:56:49 2010 From: report at bugs.python.org (STINNER Victor) Date: Sun, 08 Aug 2010 23:56:49 +0000 Subject: [New-bugs-announce] [issue9542] Create PyUnicode_FSDecoder() function In-Reply-To: <1281311809.81.0.46043022196.issue9542@psf.upfronthosting.co.za> Message-ID: <1281311809.81.0.46043022196.issue9542@psf.upfronthosting.co.za> New submission from STINNER Victor : For my work on #9425 (Rewrite import machinery to work with unicode paths), I need a PyArg_Parse converter converting bytes and str to str. PyUnicode_FSConverter() is the opposite because it encodes str to bytes. To handle (input) filenames in a function, we have 3 choices: 1/ use bytes: that's the current choice for most Python functions. It gives full unicode support for POSIX OSes (FS using a bytes API), but it is not enough for Windows (Windows uses mbcs encoding which is a very small subset of Unicode) 2/ use str with the PEP 383 (surrogateescape): it begins to be used in Python 3.1, and more seriously in Python 3.2. It offers full unicode support on all OSes (POSIX and Windows) 3/ use the native type for each OS (bytes on POSIX, str on Windows): I dislike this solution because it implies code duplication PyUnicode_FSConverter() is the converter for solution (1). PyUnicode_FSDecoder() will be the converter for the solution (2). ---------- components: Interpreter Core, Unicode files: PyUnicode_FSDecoder.patch keywords: patch messages: 113352 nosy: haypo, lemburg, loewis priority: normal severity: normal status: open title: Create PyUnicode_FSDecoder() function versions: Python 3.2 Added file: http://bugs.python.org/file18447/PyUnicode_FSDecoder.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 9 03:35:24 2010 From: report at bugs.python.org (David I. Lehn) Date: Mon, 09 Aug 2010 01:35:24 +0000 Subject: [New-bugs-announce] [issue9543] 2.6.6 rc1 socket.py flush() calls del on unbound 'view' variable In-Reply-To: <1281317724.88.0.544391829079.issue9543@psf.upfronthosting.co.za> Message-ID: <1281317724.88.0.544391829079.issue9543@psf.upfronthosting.co.za> New submission from David I. Lehn : An error was introduced in 2.6.6 rc1 in the socket flush() call where del is called on the unbound 'view' variable. Associated commit and diff: http://svn.python.org/view?view=rev&revision=83624 http://svn.python.org/view/python/tags/r266rc1/Lib/socket.py?r1=81488&r2=83624 Tail end of the runtime stack trace: File "/usr/lib/python2.6/socket.py", line 318, in write self.flush() File "/usr/lib/python2.6/socket.py", line 302, in flush del view, data # explicit free UnboundLocalError: local variable 'view' referenced before assignment ---------- components: Library (Lib) messages: 113357 nosy: dil priority: normal severity: normal status: open title: 2.6.6 rc1 socket.py flush() calls del on unbound 'view' variable type: crash versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 9 07:51:26 2010 From: report at bugs.python.org (Paul Arnold) Date: Mon, 09 Aug 2010 05:51:26 +0000 Subject: [New-bugs-announce] [issue9544] xdrlib.Packer().pack_fstring throws a TypeError when called with a str() In-Reply-To: <1281333086.43.0.820305754452.issue9544@psf.upfronthosting.co.za> Message-ID: <1281333086.43.0.820305754452.issue9544@psf.upfronthosting.co.za> New submission from Paul Arnold : In Python 3.1, xdrlib.Packer().pack_fstring() throws a TypeError if called with a str() (an encoded string bytes() works just fine). >>> xdrlib.Packer().pack_fstring(6, "foobar") Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.1/xdrlib.py", line 81, in pack_fstring data = data + (n - len(data)) * b'\0' TypeError: Can't convert 'bytes' object to str implicitly ---------- components: None messages: 113386 nosy: arnoldp priority: normal severity: normal status: open title: xdrlib.Packer().pack_fstring throws a TypeError when called with a str() type: crash versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 9 09:01:25 2010 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 09 Aug 2010 07:01:25 +0000 Subject: [New-bugs-announce] [issue9545] Adding _collections to static build In-Reply-To: <1281337285.37.0.116366194764.issue9545@psf.upfronthosting.co.za> Message-ID: <1281337285.37.0.116366194764.issue9545@psf.upfronthosting.co.za> New submission from Senthil Kumaran : As a fix for issue9396 in r83874, functools was included in re module and this caused a build failure. This was reverted in r83875, with the following message by Raymond: The problem is that the re module is imported by sysconfig and re needs functools which uses collections.OrderedDict() but the _collectionsmodule.c code is not yet constructed at this point in the build. The likely best solution will be to include _collections as part of the static build before the rest of the boot-strapping. We discussed it in IRC, I am including the _collections module to the static build. After this the r83874 can be reapplied. ---------- files: _collections.patch keywords: patch messages: 113392 nosy: orsenthil priority: normal severity: normal status: open title: Adding _collections to static build type: crash Added file: http://bugs.python.org/file18450/_collections.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 9 14:51:30 2010 From: report at bugs.python.org (Florent Xicluna) Date: Mon, 09 Aug 2010 12:51:30 +0000 Subject: [New-bugs-announce] [issue9546] buildbot: if a compile error occurs, the "clean" step is skipped In-Reply-To: <1281358290.29.0.0758314656394.issue9546@psf.upfronthosting.co.za> Message-ID: <1281358290.29.0.0758314656394.issue9546@psf.upfronthosting.co.za> New submission from Florent Xicluna : When the buildbot fails to compile, the "clean" step is not run. http://www.python.org/dev/buildbot/builders/i386%20Ubuntu%203.x/builds/1838/ This is a problem for issue #9545 where the Modules/Setup.dist cannot be copied to Modules/Setup on next run (file already exist). Normally, "clean" step takes care to remove "Modules/Setup": http://www.python.org/dev/buildbot/builders/i386%20Ubuntu%203.x/builds/1820/steps/clean/logs/stdio ---------- components: Tests keywords: buildbot messages: 113409 nosy: flox, orsenthil, pitrou, rhettinger priority: normal severity: normal status: open title: buildbot: if a compile error occurs, the "clean" step is skipped type: resource usage versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 9 18:16:01 2010 From: report at bugs.python.org (=?utf-8?q?Alexandru_Mo=C8=99oi?=) Date: Mon, 09 Aug 2010 16:16:01 +0000 Subject: [New-bugs-announce] [issue9547] iterator length In-Reply-To: <1281370561.47.0.585215134028.issue9547@psf.upfronthosting.co.za> Message-ID: <1281370561.47.0.585215134028.issue9547@psf.upfronthosting.co.za> New submission from Alexandru Mo?oi : Sometimes it's useful to get the number of elements yield by an iterator. For example (if ilen is the name of the function): def pi(n): return ilen(for e in xrange(n) if isprime(e)) def count_pred(pred, iterator): return ilen(itertools.ifilter(pred, iterator)) Two notable solutions are discussed here http://stackoverflow.com/questions/3393431/how-to-counting-not-0-elements-in-an-iterable 1) sum(1 for e in iterator) 2) len(list(iterator)) First solution is slow, the second solution uses O(N) extra memory. I propose the addition of a new function ilen() which is functionally equivalent to: def ilen(iterator): return sum(1 for e in iterator) This function should be different from len() because it's time complexity is O(N) (most people assume that len() takes O(1)) and it consumes the iterator. ---------- messages: 113421 nosy: Alexandru.Mo?oi priority: normal severity: normal status: open title: iterator length type: feature request versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 9 21:09:31 2010 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Aug 2010 19:09:31 +0000 Subject: [New-bugs-announce] [issue9548] locale can be imported at startup but relies on too many library modules In-Reply-To: <1281380971.62.0.695264636628.issue9548@psf.upfronthosting.co.za> Message-ID: <1281380971.62.0.695264636628.issue9548@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Consider the two following commands, from an SVN working copy: $ ./python -c 'import heapq; print(heapq.heapify)' $ cat | ./python -c 'import heapq; print(heapq.heapify)' In the second case, the "from _heapq import *" in heapq fails silently. The reason was a bit difficult to find, but it goes as following: - when run from a non-pty, initializing the standard streams imports Lib/locale.py - Lib/locale.py import collections which import heapq - heapq tries to import _heapq but, at this point, the build dir (such as "build/lib.linux-x86_64-3.2/") hasn't been added to sys.path, since site.py does it: the import fails - heapq silences the ImportError, and this early loaded copy of the module is then made available to all subsequent consumers of heapq, without C accelerators The issue might seem rather exotic, but it is a more general symptom of the problem that importing Lib/locale.py when initializing std{in,out,err} brings too many import dependencies. A possible solution is to define a subset of locale.py that is used for bootstrap and rely on as little modules as possible. ---------- components: Library (Lib) messages: 113457 nosy: haypo, pitrou priority: normal severity: normal status: open title: locale can be imported at startup but relies on too many library modules type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 9 21:50:53 2010 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Aug 2010 19:50:53 +0000 Subject: [New-bugs-announce] [issue9549] Remove sys.setdefaultencoding() In-Reply-To: <1281383453.04.0.233452795116.issue9549@psf.upfronthosting.co.za> Message-ID: <1281383453.04.0.233452795116.issue9549@psf.upfronthosting.co.za> New submission from Antoine Pitrou : The use of sys.setdefaultencoding() has always been discouraged, and it has become a no-op in py3k (the encoding is hard-wired to utf-8 and changing it raises an error). It is time to remove this function entirely. The state of PyUnicode_SetDefaultEncoding() should be also considered, since it has become useless for the same reasons. ---------- components: Interpreter Core, Library (Lib) messages: 113461 nosy: pitrou priority: low severity: normal stage: needs patch status: open title: Remove sys.setdefaultencoding() type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 10 00:09:00 2010 From: report at bugs.python.org (Jason V. Miller) Date: Mon, 09 Aug 2010 22:09:00 +0000 Subject: [New-bugs-announce] [issue9550] BufferedReader may issue additional read, may cause hang when backed by blocking socket In-Reply-To: <1281391740.65.0.539097127829.issue9550@psf.upfronthosting.co.za> Message-ID: <1281391740.65.0.539097127829.issue9550@psf.upfronthosting.co.za> New submission from Jason V. Miller : While reading, BufferedReader can cause an additional read() to the underlying I/O object after the entire upper-layer byte count has been satisfied. This is unnecessary and troublesome in some cases. In the event that the BufferedReader sits on top of a blocking socket (see the included test case,) certain network protocols (HTTP) can cause the server to hang in recv/recvfrom trying to read more data than will be available, causing a hang. I first ran into this issue running bottle on top of the core Python wsgi server. It looks as though this may be present in 2.x as well, however an associate of mine wasn't able to trigger the issue in 2.x (even after implementing the makefile() code from 3.x) To run the test case, start the server and then run the client against it. bufio.py server bufio.py client I successfully patched this issue locally with the following: --- Modules/_io/bufferedio.c: self->pos = 0; self->raw_pos = 0; self->read_end = 0; + if ( remaining == 0 ) + return res; + while (self->read_end < self->buffer_size) { --- Which aborts execution of the second loop in the event that the last block-sized read satisfied the upper layer call exactly. ---------- components: IO files: bufio.py messages: 113489 nosy: jvmiller priority: normal severity: normal status: open title: BufferedReader may issue additional read, may cause hang when backed by blocking socket type: behavior versions: Python 3.1 Added file: http://bugs.python.org/file18459/bufio.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 10 00:13:40 2010 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Mon, 09 Aug 2010 22:13:40 +0000 Subject: [New-bugs-announce] [issue9551] ConfigParser.SafeConfigParser.set fails when no value provided In-Reply-To: <1281392020.18.0.197979738235.issue9551@psf.upfronthosting.co.za> Message-ID: <1281392020.18.0.197979738235.issue9551@psf.upfronthosting.co.za> New submission from ?ukasz Langa : Title says it all. ---------- assignee: fdrake files: ConfigParser.diff keywords: easy, needs review, patch, patch messages: 113490 nosy: fdrake, lukasz.langa priority: normal severity: normal stage: patch review status: open title: ConfigParser.SafeConfigParser.set fails when no value provided type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file18460/ConfigParser.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 10 01:04:52 2010 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 09 Aug 2010 23:04:52 +0000 Subject: [New-bugs-announce] [issue9552] ssl build under Windows always rebuilds OpenSSL In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za> Message-ID: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za> New submission from Antoine Pitrou : The build steps for _ssl and _hashlib under Windows always rebuild the same intermediate files, even if no change was recorded since the last build. This makes building the whole project longer than it should be. Here is the (trimmed) log: ------ D?but de la g?n?ration?: Projet?: _ssl, Configuration?: Debug Win32 ------ Ex?cution d'un ?v?nement avant g?n?ration... Found a working perl at 'C:\Perl\bin\perl.exe' Found an SSL directory at '..\..\openssl-1.0.0a' Executing ssl makefiles: nmake /nologo -f "ms\nt.mak" Building OpenSSL copy ".\crypto\buildinf.h" "tmp32\buildinf.h" 1 fichier(s) copi?(s). copy ".\crypto\opensslconf.h" "inc32\openssl\opensslconf.h" 1 fichier(s) copi?(s). nasmw -f win32 -o tmp32\x86cpuid.obj tmp32\x86cpuid.asm nasmw -f win32 -o tmp32\md5-586.obj tmp32\md5-586.asm [... snip many asm files ...] nasmw -f win32 -o tmp32\wp-mmx.obj tmp32\wp-mmx.asm lib /nologo /out:out32\libeay32.lib @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\nm92.tmp link /nologo /subsystem:console /opt:ref /debug /out:out32\md4test.exe @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\nm97.tmp IF EXIST out32\md4test.exe.manifest mt -nologo -manifest out32\md4test.exe.manifest -outputresource:out32\md4test.exe;1 link /nologo /subsystem:console /opt:ref /debug /out:out32\md5test.exe @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\nm99.tmp IF EXIST out32\md5test.exe.manifest mt -nologo -manifest out32\md5test.exe.manifest -outputresource:out32\md5test.exe;1 link /nologo /subsystem:console /opt:ref /debug /out:out32\shatest.exe @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\nm9B.tmp [... snip many exe files ...] IF EXIST out32\openssl.exe.manifest mt -nologo -manifest out32\openssl.exe.manifest -outputresource:out32\openssl.exe;1 [44763 refs] Compilation en cours... _ssl.c ..\Modules\_ssl.c(583) : warning C4090: '='?: qualificateurs 'const' diff?rents ..\Modules\_ssl.c(930) : warning C4090: '='?: qualificateurs 'const' diff?rents ?dition des liens en cours... Cr?ation de la biblioth?que Z:\py3k\__svn__\PCbuild\\_ssl_d.lib et de l'objet Z:\py3k\__svn__\PCbuild\\_ssl_d.exp Le journal de g?n?ration a ?t? enregistr? ? l'emplacement "file://Z:\py3k\__svn__\PCbuild\Win32-temp-Debug\_ssl\BuildLog.htm" _ssl - 0 erreur(s), 2 avertissement(s) ---------- components: Build, Windows messages: 113497 nosy: brian.curtin, loewis, pitrou, tim.golden priority: low severity: normal status: open title: ssl build under Windows always rebuilds OpenSSL type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 10 04:03:22 2010 From: report at bugs.python.org (Denver Coneybeare) Date: Tue, 10 Aug 2010 02:03:22 +0000 Subject: [New-bugs-announce] [issue9553] test_argparse.py: 80 failures if COLUMNS env var set to a value other than 80 In-Reply-To: <1281405802.56.0.0746900619959.issue9553@psf.upfronthosting.co.za> Message-ID: <1281405802.56.0.0746900619959.issue9553@psf.upfronthosting.co.za> New submission from Denver Coneybeare : If the COLUMNS environment variable is set to a value other than 80 then test_argparse.py yields 80 failures. The value of the COLUMNS environment variable affects line wrapping of the help output and the test cases assume line wraps at 80 columns. So setting COLUMNS=160, for example, then running the tests will reproduce the failures. The fix is to invoke: os.environ["COLUMNS"] = "80". A proposed patch for py3k/Lib/test/test_argparse.py is attached (test_argparse.py.COLUMNS.patch) ---------- components: Tests files: test_argparse.py.COLUMNS.patch keywords: patch messages: 113504 nosy: benjamin.peterson, bethard, denversc, eric.smith priority: normal severity: normal status: open title: test_argparse.py: 80 failures if COLUMNS env var set to a value other than 80 versions: Python 3.3 Added file: http://bugs.python.org/file18462/test_argparse.py.COLUMNS.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 10 04:53:47 2010 From: report at bugs.python.org (Denver Coneybeare) Date: Tue, 10 Aug 2010 02:53:47 +0000 Subject: [New-bugs-announce] [issue9554] test_argparse.py: use new unittest features In-Reply-To: <1281408827.47.0.183260667114.issue9554@psf.upfronthosting.co.za> Message-ID: <1281408827.47.0.183260667114.issue9554@psf.upfronthosting.co.za> New submission from Denver Coneybeare : Some of the unit testing code in test_argparse.py could be modified to take advantage of the new unittest features in Python 2.7 and 3.x. My suggested changes are attached in the patch file test_argparse.py.unittest2.patch One big one is that assertEquals() now prints a "diff" when multi-line strings compare unequal, so the manual "diffing" logic from the unit tests can be removed. Also, assertIsNone() is slightly better than assertEquals(None, x). Finally, there is a tiny fix where parse_args() was expected to throw ArgumentParserError but the test would not fail if it threw no exceptions. ---------- components: Tests files: test_argparse.py.unittest2.patch keywords: patch messages: 113505 nosy: benjamin.peterson, bethard, denversc, eric.smith priority: normal severity: normal status: open title: test_argparse.py: use new unittest features type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file18463/test_argparse.py.unittest2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 10 12:33:43 2010 From: report at bugs.python.org (Florent Xicluna) Date: Tue, 10 Aug 2010 10:33:43 +0000 Subject: [New-bugs-announce] [issue9555] transient crashes on "x86 XP-4" buildbot: test_file, test_file2k, test_bsddb3 In-Reply-To: <1281436423.56.0.916363064932.issue9555@psf.upfronthosting.co.za> Message-ID: <1281436423.56.0.916363064932.issue9555@psf.upfronthosting.co.za> New submission from Florent Xicluna : There's frequent crashes on the "x86 XP-4" buildbot. On 2.6: 83915: # something crashed: test_file 83913: success 83743: # something crashed: test_file 83738: success 83721: success 83718: # something crashed: test_file 83704: success 83691: # something crashed: test_file 83688: # something crashed: test_file 83687: # something crashed: test_file 83674: # something crashed: test_file 83657: # something crashed: test_file 83656: # 1 failed: test_os 83648: # 2 failed: test_os test_struct 83642: # something crashed: test_bsddb3 83637: # 1 failed: test_struct 83634: # 1 failed: test_struct 83632: success 83628: success 83627: # something crashed: test_bsddb3 83626: # something crashed: test_file 83625: # 1 failed: test_builtin 83624: # 1 failed: test_builtin 83623: success 83539: # something crashed: test_bsddb3 83532: success 83520: success 83519: # something crashed: test_file 83518: # something crashed: test_file 83517: # something crashed: test_file 83515: success 83512: # something crashed: test_file 83502: ? something crashed: test_file 83487: success 83443: ? exception clean 83420: # something crashed: test_file 83414: ? exception svn 83382: success 83379: # something crashed: test_file 83377: # something crashed: test_file 83242: success 83200: # something crashed: test_file 83194: success 83147: success 83136: # something crashed: test_file 83128: # something crashed: test_file 83119: success On 2.7: 83928: # something crashed: test_bsddb3 83925: success 83920: success 83917: success 83909: success 83907: success 83893: # 1 failed: test_bsddb3 83879: success 83873: ? exception svn 83858: success 83856: # something crashed: test_bsddb3 83836: # hung for 20 min: test_file2k 83832: # something crashed: test_file2k 83824: ? exception svn 83820: # something crashed: test_file2k 83806: success 83782: # something crashed: test_bsddb3 83773: success 83769: success 83765: ? exception svn 83760: # something crashed: test_file2k 83757: # failed slave lost 83749: # something crashed: test_file2k 83746: success 83737: # something crashed: test_bsddb3 83734: ? exception svn The test is interrupted on the "crash", and the last message is: - program finished with exit code -1073741819 elapsedTime=184.398000 - program finished with exit code -1073741819 elapsedTime=383.852000 - program finished with exit code -1073741819 elapsedTime=1003.798000 - program finished with exit code -1073741819 elapsedTime=453.802000 (reports created with bbreport) ---------- components: Tests keywords: buildbot messages: 113522 nosy: flox priority: normal severity: normal status: open title: transient crashes on "x86 XP-4" buildbot: test_file, test_file2k, test_bsddb3 type: crash versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 10 13:57:37 2010 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 10 Aug 2010 11:57:37 +0000 Subject: [New-bugs-announce] [issue9556] Specifying the time a TimedRotatingFileHandler rotates In-Reply-To: <1281441457.15.0.524451784963.issue9556@psf.upfronthosting.co.za> Message-ID: <1281441457.15.0.524451784963.issue9556@psf.upfronthosting.co.za> New submission from Ronald Oussoren : The logging module contains a TimedRotatingFileHandler that automaticly rotates the logfile after a specified interval. This class misses an important feature: it is not possible to specify at what time the file should be rotated, unless that time is midnight. My usecase: one of our customers works night shifts which means that rotating logfiles at midnight means that files get rotated halfway through a shift instead of at the end of one. We'd like to be able to specify that logfiles get rotated at a specific time (such as 7:00AM). ---------- components: Library (Lib) messages: 113527 nosy: ronaldoussoren priority: normal severity: normal stage: needs patch status: open title: Specifying the time a TimedRotatingFileHandler rotates type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 10 15:46:11 2010 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 10 Aug 2010 13:46:11 +0000 Subject: [New-bugs-announce] [issue9557] test_mailbox failure under a Windows VM In-Reply-To: <1281447971.09.0.314164589839.issue9557@psf.upfronthosting.co.za> Message-ID: <1281447971.09.0.314164589839.issue9557@psf.upfronthosting.co.za> New submission from Antoine Pitrou : I get this failure in test_mailbox under Windows XP running in a qemu virtual machine: ====================================================================== FAIL: test_reread (test.test_mailbox.TestMaildir) ---------------------------------------------------------------------- Traceback (most recent call last): File "Z:\py3k\debug\lib\test\test_mailbox.py", line 764, in test_reread assert not refreshed() AssertionError ---------------------------------------------------------------------- ---------- assignee: akuchling components: Library (Lib), Tests messages: 113538 nosy: akuchling, pitrou priority: low severity: normal status: open title: test_mailbox failure under a Windows VM type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 10 16:35:35 2010 From: report at bugs.python.org (Hirokazu Yamamoto) Date: Tue, 10 Aug 2010 14:35:35 +0000 Subject: [New-bugs-announce] [issue9558] build_ext fails on VS8.0 In-Reply-To: <1281450935.69.0.209009694295.issue9558@psf.upfronthosting.co.za> Message-ID: <1281450935.69.0.209009694295.issue9558@psf.upfronthosting.co.za> New submission from Hirokazu Yamamoto : test_build_ext fails on VS8.0. ====================================================================== ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "e:\python-dev\release26-maint\lib\distutils\tests\test_build_ext.py", li ne 58, in test_build_ext cmd.run() File "e:\python-dev\release26-maint\lib\distutils\command\build_ext.py", line 340, in run self.build_extensions() File "e:\python-dev\release26-maint\lib\distutils\command\build_ext.py", line 449, in build_extensions self.build_extension(ext) File "e:\python-dev\release26-maint\lib\distutils\command\build_ext.py", line 531, in build_extension target_lang=language) File "e:\python-dev\release26-maint\lib\distutils\ccompiler.py", line 769, in link_shared_object extra_preargs, extra_postargs, build_temp, target_lang) File "e:\python-dev\release26-maint\lib\distutils\msvc9compiler.py", line 648, in link raise LinkError(msg) LinkError: command '"C:\Program Files\Microsoft Visual Studio 8\VC\BIN\link.exe" ' failed with exit status 1104 ---------- assignee: tarek components: Distutils, Windows files: py3k_distutils_build_ext_on_VS8.patch keywords: easy, patch messages: 113541 nosy: ocean-city, tarek priority: release blocker severity: normal stage: patch review status: open title: build_ext fails on VS8.0 versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file18467/py3k_distutils_build_ext_on_VS8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 10 18:40:08 2010 From: report at bugs.python.org (Chris Green) Date: Tue, 10 Aug 2010 16:40:08 +0000 Subject: [New-bugs-announce] [issue9559] mailbox.mbox creates new file when adding message to mbox In-Reply-To: <1281458408.75.0.432136903483.issue9559@psf.upfronthosting.co.za> Message-ID: <1281458408.75.0.432136903483.issue9559@psf.upfronthosting.co.za> New submission from Chris Green : When you call mailbox.mbox.add() the old mbox file is copied, the new file is modified and then renamed to the name of the'old' mbox file. This breaks the way that many MUAs detect and manage new mail in an mbox, in particular I discovered this with mutt. If the python process writing the mbox and mutt are on the same system writing a local file then you get the message "Mailbox was externally modified. Flags may be wrong." from mutt (and various odd things can happen). If mutt is reading the mbox over NFS then you get a "Stale NFS file handle" error. This should be strongly noted in the documentation for mailbox.mbox, in addition it would be really nice if there was a mailbox.mbox.append() method which *really* appends the data to the end of the mbox rather than changing it completely. Most MDAs (all?) do just append new mail to the end of the mbox and I feel that python should really try and do the same. ---------- components: Library (Lib) messages: 113547 nosy: chrisisbd priority: normal severity: normal status: open title: mailbox.mbox creates new file when adding message to mbox type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 10 19:21:34 2010 From: report at bugs.python.org (STINNER Victor) Date: Tue, 10 Aug 2010 17:21:34 +0000 Subject: [New-bugs-announce] [issue9560] platform.py: use -b option for file command in _syscmd_file() In-Reply-To: <1281460894.18.0.756161940799.issue9560@psf.upfronthosting.co.za> Message-ID: <1281460894.18.0.756161940799.issue9560@psf.upfronthosting.co.za> New submission from STINNER Victor : Lib/platform.py was created 7 years ago by r32391. _syscmd_file() docstring was never changed whereas it is inconsistent with the implementation: --- def _syscmd_file(target,default=''): """ Interface to the system's file command. The function uses the -b option of the file command to have it ommit the filename in its output and if possible the -L option to have the command follow symlinks. It returns default in case the command should fail. """ ... target = _follow_symlinks(target).replace('"', '\\"') ... f = os.popen('file "%s" 2> %s' % (target, DEV_NULL)) ... --- It doesn't use -L option but use Python to follow the link, and use an regex to remove the filename. Attached patch enables -b option to avoid problem with non-ascii filenames but ascii locale encoding (see #8611 and #9425) and updates the docstring. -- To fix the non-ascii problem, I tried a different approach by using subprocess API which gives a bytes version of stdout and so avoid the encoding issue. But I commited the patch on python trunk (2.7) which had a bootstrap issue. py3k had no bootstrap issue, but the new patch (use -b option) is simpler. Commits: r80166 (trunk), r80167 (py3k). Reverted: r80171+r80189 (trunk) and r80190 (py3k). More details in the following mail thread: http://mail.python.org/pipermail/python-checkins/2010-April/092092.html ---------- files: _syscmd_file.patch keywords: patch messages: 113549 nosy: haypo, lemburg, pitrou priority: normal severity: normal status: open title: platform.py: use -b option for file command in _syscmd_file() versions: Python 3.2 Added file: http://bugs.python.org/file18470/_syscmd_file.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 10 19:51:39 2010 From: report at bugs.python.org (STINNER Victor) Date: Tue, 10 Aug 2010 17:51:39 +0000 Subject: [New-bugs-announce] [issue9561] distutils: set encoding to utf-8 for input and output files In-Reply-To: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za> Message-ID: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za> New submission from STINNER Victor : While working on #9425 (support non-ascii characters in python directory name with ascii locale), I wrote a patch for distutils.file_util(): set encoding to utf-8 and errors to surrogateescape. See the patch with comments at: http://codereview.appspot.com/1874048/patch/1/9 (the patch is not enough, it should also patch *all* functions reading files) I discussed with takek who told me that it is documented that distutils files have to be utf-8. I didn't found the documentation. I checked read_manifest() in sdist command: in Python2 and Python3, it uses open(name) syntax. It means that Python2 uses the binary API (bytes), whereas Python3 uses the text API (unicode characters) and Python3 relies on open() (TextIOWrapper) heuristic to *guess* the file encoding. I think that it will be better to specify the encoding in Python3, and maybe use the text API in Python2. Anyway, before going futher (work on patches), I would like the approval of distutils maintainer(s). ---------- assignee: tarek components: Distutils, Distutils2, Unicode messages: 113552 nosy: haypo, merwok, tarek priority: normal severity: normal status: open title: distutils: set encoding to utf-8 for input and output files versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 10 22:50:03 2010 From: report at bugs.python.org (Mitchell Model) Date: Tue, 10 Aug 2010 20:50:03 +0000 Subject: [New-bugs-announce] [issue9562] Slightly misleading wording in documentation of dict.update In-Reply-To: <1281473403.13.0.50491902338.issue9562@psf.upfronthosting.co.za> Message-ID: <1281473403.13.0.50491902338.issue9562@psf.upfronthosting.co.za> New submission from Mitchell Model : The documentation of dict.update says that it "accepts either another dictionary object or an iterable of key/value pairs (as a tuple or other iterable of length two)" The parenthesized phrase is slightly misleading in that it could be interpreted as requiring the argument to be an iterable of length two, whereas the argument should be an iterable of iterables of length 2 (if not a dictionary). Suggest rewriting in the plural: (as tuples or other iterables of length two) ---------- assignee: docs at python components: Documentation messages: 113557 nosy: MLModel, docs at python priority: normal severity: normal status: open title: Slightly misleading wording in documentation of dict.update versions: Python 2.6, Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 10 23:25:28 2010 From: report at bugs.python.org (Gwendal LE BIHAN) Date: Tue, 10 Aug 2010 21:25:28 +0000 Subject: [New-bugs-announce] [issue9563] bad exception handling when giving no value to an option requiring one In-Reply-To: <1281475528.51.0.829723304896.issue9563@psf.upfronthosting.co.za> Message-ID: <1281475528.51.0.829723304896.issue9563@psf.upfronthosting.co.za> New submission from Gwendal LE BIHAN : Having created the parser this way: optparser=OptionParser() optparser.add_option("--share-dir",dest="share_dir",default="/usr/share") options,args=optparser.parse_args() And calling the program this way: appname --share-dir I get the following exception, which is not caught: options,args=optparser.parse_args() File "/usr/lib/python2.6/optparse.py", line 1394, in parse_args stop = self._process_args(largs, rargs, values) File "/usr/lib/python2.6/optparse.py", line 1434, in _process_args self._process_long_opt(rargs, values) File "/usr/lib/python2.6/optparse.py", line 1509, in _process_long_opt option.process(opt, value, values, self) UnboundLocalError: local variable 'value' referenced before assignment ---------- components: Library (Lib) messages: 113560 nosy: Gwendal.LE.BIHAN priority: normal severity: normal status: open title: bad exception handling when giving no value to an option requiring one type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 11 00:06:51 2010 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 10 Aug 2010 22:06:51 +0000 Subject: [New-bugs-announce] [issue9564] Test issue. In-Reply-To: <1281478011.71.0.148947311328.issue9564@psf.upfronthosting.co.za> Message-ID: <1281478011.71.0.148947311328.issue9564@psf.upfronthosting.co.za> New submission from Mark Dickinson : Testing autonosy. Please close as invalid. ---------- assignee: tarek components: Distutils messages: 113562 nosy: mark.dickinson, merwok, tarek priority: normal severity: normal status: open title: Test issue. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 11 00:56:05 2010 From: report at bugs.python.org (Hasan) Date: Tue, 10 Aug 2010 22:56:05 +0000 Subject: [New-bugs-announce] [issue9565] socket : accept() method not working In-Reply-To: <1281480965.46.0.164319565216.issue9565@psf.upfronthosting.co.za> Message-ID: <1281480965.46.0.164319565216.issue9565@psf.upfronthosting.co.za> New submission from Hasan : hi, i am use the socket module in python. But accept() method not working and its not give me an error about this problem. for example i run the my scipt. When it comes to accept() method line, python is locks. i use the ubuntu os. and python 2.6.5 pls, help me. ---------- components: IDLE files: server.py messages: 113567 nosy: cmuse priority: normal severity: normal status: open title: socket : accept() method not working versions: Python 2.6 Added file: http://bugs.python.org/file18471/server.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 11 01:59:46 2010 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 10 Aug 2010 23:59:46 +0000 Subject: [New-bugs-announce] [issue9566] Compilation warnings under x64 Windows In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za> Message-ID: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za> New submission from Antoine Pitrou : A 64-bit build under Windows produces many compilation warnings, mostly related to lossy conversions between different int sizes. Some of these warnings appear harmless after analysis (are MS 64 bit compilers pickier than their 32 bit counterparts?). It would probably be spammy to open a separate issue per file. 5>..\Python\pythonrun.c(1210) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(3403) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(3409) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(3439) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(3445) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(3498) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(3504) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(3608) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(3614) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(3633) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(3639) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(3699) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(3705) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(3724) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(3730) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(3771) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(3777) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(3796) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(3802) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(3855) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(3861) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(3892) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(3898) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4016) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4022) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4041) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4047) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4092) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4098) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4117) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4123) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4167) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4173) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4192) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4198) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4253) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4259) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4326) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4332) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4351) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4357) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4376) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4382) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4414) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4420) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4439) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4445) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4510) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4516) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4559) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4565) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4607) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4613) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4643) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4649) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4791) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4797) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(4998) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5004) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5023) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5029) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5059) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5065) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5108) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5114) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5157) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5163) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5219) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5225) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5269) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5275) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5341) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5347) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5366) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5372) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5419) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5425) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5444) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5450) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5753) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5759) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5802) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5808) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5979) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(5985) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(6356) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(6362) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(6456) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(6462) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(6508) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(6514) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(6555) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(6561) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(6602) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(6608) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(6627) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\Python-ast.c(6633) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\dtoa.c(1529) : warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data 5>..\Python\dtoa.c(1539) : warning C4244: '-=' : conversion from '__int64' to 'int', possible loss of data 5>..\Python\dtoa.c(1545) : warning C4244: '+=' : conversion from '__int64' to 'int', possible loss of data 5>..\Python\pystrtod.c(902) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\pystrtod.c(1023) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\peephole.c(84) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data 5>..\Python\peephole.c(184) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data 5>..\Python\peephole.c(237) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data 5>..\Python\peephole.c(309) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data 5>..\Python\peephole.c(352) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\peephole.c(403) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data 5>..\Python\peephole.c(418) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data 5>..\Python\peephole.c(459) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\peephole.c(544) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\peephole.c(555) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data 5>..\Python\peephole.c(587) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\peephole.c(601) : warning C4244: '-=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\peephole.c(632) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\peephole.c(661) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data 5>..\Python\peephole.c(671) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data 5>..\Python\getargs.c(390) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\getargs.c(502) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\getargs.c(876) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\getargs.c(931) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\getargs.c(939) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\getargs.c(983) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\getargs.c(1133) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\getargs.c(1476) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\getargs.c(1477) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>z:\py3k\__svn__\python\../Objects/stringlib/formatter.h(984) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>z:\py3k\__svn__\python\../Objects/stringlib/formatter.h(1161) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>z:\py3k\__svn__\python\../Objects/stringlib/formatter.h(1165) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\compile.c(339) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'long', possible loss of data 5>..\Python\compile.c(384) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'long', possible loss of data 5>..\Python\compile.c(479) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\compile.c(533) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\compile.c(947) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'long', possible loss of data 5>..\Python\compile.c(962) : warning C4244: 'return' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\compile.c(1254) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\compile.c(1399) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\compile.c(3678) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\compile.c(3704) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\compile.c(3730) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\compile.c(3898) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\compile.c(3902) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\compile.c(3942) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\compile.c(3949) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\ceval.c(3967) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Python\ceval.c(4155) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\PC\winreg.c(769) : warning C4267: '=' : conversion from 'size_t' to 'DWORD', possible loss of data 5>..\PC\winreg.c(801) : warning C4267: '+=' : conversion from 'size_t' to 'DWORD', possible loss of data 5>..\PC\winreg.c(851) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'DWORD', possible loss of data 5>..\PC\winreg.c(1186) : warning C4133: '=' : incompatible types - from 'wchar_t *' to 'BYTE *' 5>..\PC\_subprocess.c(345) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\PC\_subprocess.c(368) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\PC\_subprocess.c(369) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\PC\_subprocess.c(371) : warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data 5>..\PC\_subprocess.c(373) : warning C4244: 'initializing' : conversion from '__int64' to 'int', possible loss of data 5>..\Parser\tokenizer.c(658) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data 5>..\Parser\tokenizer.c(689) : warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data 5>..\Parser\parsetok.c(199) : warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data 5>..\Parser\grammar.c(66) : warning C4244: 'return' : conversion from '__int64' to 'int', possible loss of data 5>..\Parser\grammar.c(108) : warning C4244: 'return' : conversion from '__int64' to 'int', possible loss of data 5>..\Objects\typeobject.c(6173) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Objects\setobject.c(743) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'long', possible loss of data 5>..\Objects\setobject.c(772) : warning C4244: '*=' : conversion from 'Py_ssize_t' to 'long', possible loss of data 5>..\Objects\setobject.c(819) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'long', possible loss of data 5>..\Objects\obmalloc.c(904) : warning C4244: '=' : conversion from '__int64' to 'unsigned int', possible loss of data 5>..\Objects\funcobject.c(633) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Objects\funcobject.c(634) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Objects\funcobject.c(634) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Objects\frameobject.c(480) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Objects\frameobject.c(513) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Objects\frameobject.c(871) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Objects\frameobject.c(872) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Objects\frameobject.c(918) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Objects\frameobject.c(919) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Objects\fileobject.c(401) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'unsigned int', possible loss of data 5>..\Objects\descrobject.c(891) : warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data 5>..\Objects\codeobject.c(495) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Objects\codeobject.c(517) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Objects\bytesobject.c(786) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Objects\bytesobject.c(795) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Objects\bytesobject.c(1755) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Objects\bytesobject.c(1947) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Objects\bytesobject.c(2620) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'char', possible loss of data 5>..\Objects\bytesobject.c(2641) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'char', possible loss of data 5>..\Objects\bytesobject.c(2696) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'char', possible loss of data 5>..\Objects\bytearrayobject.c(1222) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Objects\bytearrayobject.c(1231) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Objects\bytes_methods.c(454) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'char', possible loss of data 5>..\Modules\_io\fileio.c(483) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'unsigned int', possible loss of data 5>..\Modules\_io\fileio.c(566) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned int', possible loss of data 5>..\Modules\_io\fileio.c(622) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'unsigned int', possible loss of data 5>..\Modules\_io\fileio.c(662) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'unsigned int', possible loss of data 5>..\Modules\zlibmodule.c(127) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\zlibmodule.c(211) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\zlibmodule.c(217) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data 5>..\Modules\zlibmodule.c(271) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data 5>..\Modules\zlibmodule.c(422) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\zlibmodule.c(434) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data 5>..\Modules\zlibmodule.c(451) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data 5>..\Modules\zlibmodule.c(505) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\zlibmodule.c(526) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data 5>..\Modules\zlibmodule.c(556) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data 5>..\Modules\zlibmodule.c(935) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data 5>..\Modules\zlibmodule.c(938) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data 5>..\Modules\zlibmodule.c(963) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data 5>..\Modules\zlibmodule.c(966) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'uInt', possible loss of data 5>..\Modules\sha512module.c(558) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\sha512module.c(710) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\sha512module.c(751) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\sha256module.c(492) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\sha256module.c(644) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\sha256module.c(685) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\sha1module.c(399) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'unsigned long', possible loss of data 5>..\Modules\sha1module.c(520) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'unsigned long', possible loss of data 5>..\Modules\posixmodule.c(394) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data 5>..\Modules\posixmodule.c(3708) : warning C4133: 'function' : incompatible types - from 'int *' to 'Py_ssize_t *' 5>..\Modules\posixmodule.c(4886) : warning C4244: 'function' : conversion from 'Py_intptr_t' to 'long', possible loss of data 5>..\Modules\posixmodule.c(5593) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned int', possible loss of data 5>..\Modules\mmapmodule.c(881) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'char', possible loss of data 5>..\Modules\md5module.c(423) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'unsigned long', possible loss of data 5>..\Modules\md5module.c(544) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'unsigned long', possible loss of data 5>..\Modules\binascii.c(667) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'unsigned char', possible loss of data 5>..\Modules\audioop.c(332) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\audioop.c(354) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\audioop.c(376) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\audioop.c(398) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\audioop.c(423) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\audioop.c(632) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\audioop.c(687) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\audioop.c(737) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\audioop.c(763) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\audioop.c(810) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\audioop.c(868) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\audioop.c(928) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\audioop.c(984) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\audioop.c(1018) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\audioop.c(1053) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\audioop.c(1284) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\audioop.c(1316) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\audioop.c(1353) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\audioop.c(1385) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\audioop.c(1424) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\audioop.c(1530) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>z:\py3k\__svn__\modules\_sre.c(1898) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>z:\py3k\__svn__\modules\_sre.c(1901) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>z:\py3k\__svn__\modules\_sre.c(1935) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>z:\py3k\__svn__\modules\_sre.c(1938) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>z:\py3k\__svn__\modules\_sre.c(2082) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>z:\py3k\__svn__\modules\_sre.c(2085) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>z:\py3k\__svn__\modules\_sre.c(2212) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>z:\py3k\__svn__\modules\_sre.c(2215) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>z:\py3k\__svn__\modules\_sre.c(2364) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>z:\py3k\__svn__\modules\_sre.c(2367) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>z:\py3k\__svn__\modules\_sre.c(3753) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>z:\py3k\__svn__\modules\_sre.c(3756) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>z:\py3k\__svn__\modules\_sre.c(3786) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>z:\py3k\__svn__\modules\_sre.c(3789) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\_pickle.c(284) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\_pickle.c(301) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\_pickle.c(461) : warning C4244: '+=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\_pickle.c(628) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'long', possible loss of data 5>..\Modules\_pickle.c(647) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data 5>..\Modules\_pickle.c(1320) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\_pickle.c(1558) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\_pickle.c(1806) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\_csv.c(971) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\_csv.c(1100) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\_csv.c(1105) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\_csv.c(1133) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 5>..\Modules\_collectionsmodule.c(1124) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'long', possible loss of data ---------- components: Extension Modules, Interpreter Core messages: 113573 nosy: pitrou priority: low severity: normal status: open title: Compilation warnings under x64 Windows type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 11 04:37:15 2010 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 11 Aug 2010 02:37:15 +0000 Subject: [New-bugs-announce] [issue9567] Add attribute pointing to wrapped function to partial objects In-Reply-To: <1281494235.56.0.666889184643.issue9567@psf.upfronthosting.co.za> Message-ID: <1281494235.56.0.666889184643.issue9567@psf.upfronthosting.co.za> New submission from ?ric Araujo : Raymond in #9396: ?I was just about to propose that functools.wraps add a standard attribute to point at the underlying function (on the theory that objects should be introspectable). This would allow a standard way to get to the underlying unwrapped functions.? ---------- components: Library (Lib) messages: 113579 nosy: eric.araujo, r.david.murray, rhettinger priority: normal severity: normal stage: unit test needed status: open title: Add attribute pointing to wrapped function to partial objects type: feature request versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 11 10:11:36 2010 From: report at bugs.python.org (Ned Deily) Date: Wed, 11 Aug 2010 08:11:36 +0000 Subject: [New-bugs-announce] [issue9568] test_urllib2_localnet fails on OS X 10.3 In-Reply-To: <1281514296.56.0.121028925935.issue9568@psf.upfronthosting.co.za> Message-ID: <1281514296.56.0.121028925935.issue9568@psf.upfronthosting.co.za> New submission from Ned Deily : Issue8455 documents a problem which resulted in test_urllib2_libnet failing on OS X with "Connection refused" errors. r82150, r82280, r82281, and r82282 eliminated the test failures for all active branches when running on OS X 10.4 through 10.6. However, the fixes overlooked a different code path which is only used on OS X 10.3. The attached one-line patches for 2.6/2.7 and for py3k/3.1 correct that problem for 10.3 as well. Since the patch is low-risk and corrects a failing test case, I recommend that it be applied for the 2.6.6 release. ---------- assignee: ronaldoussoren components: Macintosh files: issue-proxy-10-3-27-26.txt messages: 113592 nosy: barry, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: test_urllib2_localnet fails on OS X 10.3 versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file18475/issue-proxy-10-3-27-26.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 11 20:11:40 2010 From: report at bugs.python.org (David Watson) Date: Wed, 11 Aug 2010 18:11:40 +0000 Subject: [New-bugs-announce] [issue9569] Add tests for posix.mknod() and posix.mkfifo() In-Reply-To: <1281550300.21.0.724215266655.issue9569@psf.upfronthosting.co.za> Message-ID: <1281550300.21.0.724215266655.issue9569@psf.upfronthosting.co.za> New submission from David Watson : Attaching simple tests for these functions, which aren't currently tested. ---------- components: Extension Modules files: test-mknod-mkfifo-3.x.diff keywords: patch messages: 113609 nosy: baikie priority: normal severity: normal status: open title: Add tests for posix.mknod() and posix.mkfifo() type: feature request Added file: http://bugs.python.org/file18478/test-mknod-mkfifo-3.x.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 11 20:16:28 2010 From: report at bugs.python.org (David Watson) Date: Wed, 11 Aug 2010 18:16:28 +0000 Subject: [New-bugs-announce] [issue9570] PEP 383: os.mknod() and os.mkfifo() do not accept surrogateescape arguments In-Reply-To: <1281550588.4.0.722092515628.issue9570@psf.upfronthosting.co.za> Message-ID: <1281550588.4.0.722092515628.issue9570@psf.upfronthosting.co.za> New submission from David Watson : These functions still use the "s" format for their arguments; the attached patch fixes them to use PyUnicode_FSConverter() in 3.2. Some simple tests for these functions (not for PEP 383 behaviour) are at issue #9569. ---------- components: Extension Modules files: mknod-mkfifo-pep383-3.2.diff keywords: patch messages: 113611 nosy: baikie priority: normal severity: normal status: open title: PEP 383: os.mknod() and os.mkfifo() do not accept surrogateescape arguments type: behavior versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file18480/mknod-mkfifo-pep383-3.2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 11 21:21:27 2010 From: report at bugs.python.org (=?utf-8?q?Michael=2EElsd=C3=B6rfer?=) Date: Wed, 11 Aug 2010 19:21:27 +0000 Subject: [New-bugs-announce] [issue9571] argparse: Allow the use of -- to break out of nargs and into subparser In-Reply-To: <1281554487.14.0.725527410465.issue9571@psf.upfronthosting.co.za> Message-ID: <1281554487.14.0.725527410465.issue9571@psf.upfronthosting.co.za> New submission from Michael.Elsd?rfer : argparse already seems to support -- to indicate that what follows are positional arguments. However, I would like to parse something like: ./script.py --ignore one two -- COMMAND I.e., --ignore is an nargs='+' argument, and I need a way to break out of --ignore and have argparse consider what follows on it's own merits. If COMMAND in the above example refers to a subparser, this won't work: error: invalid choice: '--' (choose from 'command1', 'command2', 'command3') I'm not sure what's the best solution here. Allowing -- here would change the semantics of forcing everything that follows to be positional arguments, since the subparser might have flags. I'm not sure if that is what is required by Unix conventions, but if not, then I think it makes sense to allow -- to be followed by a subparser. ---------- components: Library (Lib) messages: 113616 nosy: elsdoerfer priority: normal severity: normal status: open title: argparse: Allow the use of -- to break out of nargs and into subparser type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 11 22:09:15 2010 From: report at bugs.python.org (Florent Xicluna) Date: Wed, 11 Aug 2010 20:09:15 +0000 Subject: [New-bugs-announce] [issue9572] IOError in test_multiprocessing In-Reply-To: <1281557355.31.0.33043228103.issue9572@psf.upfronthosting.co.za> Message-ID: <1281557355.31.0.33043228103.issue9572@psf.upfronthosting.co.za> New submission from Florent Xicluna : This error occurred on "x86 Ubuntu 3.x" buildbot. This is the 1st test on this run. http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%203.x/builds/1699/steps/test/logs/stdio ./python -Wd -E -bb ./Lib/test/regrtest.py -uall -rwW -l == CPython 3.2a1+ (py3k:83951, Aug 11 2010, 15:26:40) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu4)] == Linux-2.6.31.5-linode21-i686-with-debian-lenny-sid little-endian == /srv/buildbot/buildarea/3.x.bolen-ubuntu/build/build/test_python_8258 Using random seed 426296 [ 1/346] test_multiprocessing Process Process-22: Traceback (most recent call last): File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/process.py", line 233, in _bootstrap self.run() File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/process.py", line 88, in run self._target(*self._args, **self._kwargs) File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_multiprocessing.py", line 1253, in _putter manager.connect() File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/managers.py", line 478, in connect dispatch(conn, None, 'dummy') File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/managers.py", line 79, in dispatch kind, result = c.recv() File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 408, in recv s = self._conn.recv_bytes() EOFError test test_multiprocessing failed -- Traceback (most recent call last): File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/importlib/_bootstrap.py", line 486, in set_data with _closing(_io.FileIO(path, 'wb')) as file: IOError: [Errno 2] No such file or directory: '/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/xmlrpc/__pycache__/__init__.cpython-32.pyc' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_multiprocessing.py", line 1266, in test_rapid_restart queue = manager.get_queue() File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/managers.py", line 644, in temp token, exp = self._create(typeid, *args, **kwds) File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/managers.py", line 542, in _create conn = self._Client(self._address, authkey=self._authkey) File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 427, in XmlClient import xmlrpc.client as xmlrpclib File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/importlib/_bootstrap.py", line 450, in load_module return self._load_module(fullname) File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/importlib/_bootstrap.py", line 155, in decorated return fxn(self, module, *args, **kwargs) File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/importlib/_bootstrap.py", line 344, in _load_module code_object = self.get_code(name) File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/importlib/_bootstrap.py", line 437, in get_code self.set_data(bytecode_path, data) File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/importlib/_bootstrap.py", line 498, in set_data _os.mkdir(directory) OSError: [Errno 17] File exists: '/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/xmlrpc/__pycache__' Re-running test test_multiprocessing in verbose mode ... ---------------------------------------------------------------------- Ran 127 tests in 34.091s OK (skipped=9) ---------- components: Library (Lib), Tests keywords: buildbot messages: 113626 nosy: flox priority: normal severity: normal status: open title: IOError in test_multiprocessing type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 12 01:42:04 2010 From: report at bugs.python.org (Alex Roitman) Date: Wed, 11 Aug 2010 23:42:04 +0000 Subject: [New-bugs-announce] [issue9573] imporing a module that executes fork() raises RuntimeError In-Reply-To: <1281570124.9.0.596338600617.issue9573@psf.upfronthosting.co.za> Message-ID: <1281570124.9.0.596338600617.issue9573@psf.upfronthosting.co.za> New submission from Alex Roitman : Importing the module with the following contents results in RuntimeError: ================== import os pid = os.fork() if pid == 0: print "In the child" else: print "In the parent" print "Done\n" ================== Running the same module as main works just fine, so it seems to be a purely import issue. I looked into the 2.6.6rc1 source. This is what I think happens in Python/import.c file: 1. After the fork() call, _PyImport_ReInitLock() is run. It sets import_lock_thread to -1 in the child, line 310. 2. In _PyImport_ReleaseLock() line 290 compares import_loc_thread to the current thread id, and if they are not the same then -1 is returned, which results in RuntimeError in PyImport_ImportModuleLevel (line 2186-2189) So this is guaranteed to happen in the child, every time fork() is executed inside the module being imported. If I change line 290 to be: if (import_lock_thread != me && import_lock_thread != -1) then import proceeds fine, although I'm not sure this is a proper solution. This happens on Linux, Darwin, and Cygwin, with python 2.6.5 and higher. I'd be happy to assist solving this, please let me know how I can help. ---------- components: Interpreter Core messages: 113643 nosy: Alex.Roitman priority: normal severity: normal status: open title: imporing a module that executes fork() raises RuntimeError type: behavior versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 12 09:12:42 2010 From: report at bugs.python.org (Jervis Whitley) Date: Thu, 12 Aug 2010 07:12:42 +0000 Subject: [New-bugs-announce] [issue9574] complex does not parse strings containing decimals In-Reply-To: <1281597162.74.0.823446392009.issue9574@psf.upfronthosting.co.za> Message-ID: <1281597162.74.0.823446392009.issue9574@psf.upfronthosting.co.za> New submission from Jervis Whitley : complex() raises ValueError when parsing a string argument containing both real and imaginary where one of the real or imaginary is a decimal. To reproduce: >>> complex("1.1 + 2.1j") ValueError: complex() arg is a malformed string >>> complex("2.1j") 2.1j >>> complex("1.1 + 2j") ValueError: complex() arg is a malformed string >>> complex("1 + 2.1j") ValueError: complex() arg is a malformed string Expected results: >>> complex("1.1 + 2.1j") (1.1 + 2.1j) >>> complex("2.1j") 2.1j >>> complex("1.1 + 2j") (1.1 + 2j) >>> complex("1 + 2.1j") (1 + 2.1j) This affects all versions up to Python 3.1.2. I haven't tested any of the development builds. Tests were conducted on a Windows XP 32 bit machine. ---------- components: Interpreter Core messages: 113661 nosy: jdwhitley priority: normal severity: normal status: open title: complex does not parse strings containing decimals type: behavior versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 12 13:02:38 2010 From: report at bugs.python.org (Heejin) Date: Thu, 12 Aug 2010 11:02:38 +0000 Subject: [New-bugs-announce] [issue9575] os.listdir() crashes on some long and deep paths in Windows 7 In-Reply-To: <1281610958.98.0.583662665804.issue9575@psf.upfronthosting.co.za> Message-ID: <1281610958.98.0.583662665804.issue9575@psf.upfronthosting.co.za> New submission from Heejin : As far as I have seen, this bug only appears in Windows 7. I tested with Python 2.5, 2.6, and 2.7 and they all seem to have this bug. I tested with Windows 7 Korean version. I'm not sure if other language versions have the same problem. Reproduction steps: 1. Run a command shell 'cmd'. 2. Run following commands in order: cd c:\ mkdir rpcc\build cd rpcc\build mkdir customs\llvm2dre\llvm-2.6\tools\clang\test\CXX\over\over.match\over.match.best\over.best.ics\over.ics.ellipsis\.svn\tmp\prop-base 3. Create a python script file temp.py with the contents below import os path = 'customs\\llvm2dre\\llvm-2.6\\tools\\clang\\test\\CXX\\over\\over.match\\over.match.best\\over.best.ics\\over.ics.ellipsis\\.svn\\tmp\\prop-base' os.listdir(path) (I attached this file in this post) 4. Run the script. python temp.py 5. Then you can see it crashes. ---------- components: Library (Lib), Windows files: temp.py messages: 113672 nosy: aheejin priority: normal severity: normal status: open title: os.listdir() crashes on some long and deep paths in Windows 7 type: crash versions: Python 2.5, Python 2.6, Python 2.7 Added file: http://bugs.python.org/file18483/temp.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 12 17:44:53 2010 From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=) Date: Thu, 12 Aug 2010 15:44:53 +0000 Subject: [New-bugs-announce] [issue9576] logging.addLevelName in file-based configurations In-Reply-To: <1281627893.73.0.657800338781.issue9576@psf.upfronthosting.co.za> Message-ID: <1281627893.73.0.657800338781.issue9576@psf.upfronthosting.co.za> New submission from Tarek Ziad? : It's not possible to use a custom level in a file-based configuration unless you programatically call logging.addLevelName('LEVEL', VALUE) It would be nice to be able to declare new levels in config files ---------- assignee: vinay.sajip components: Library (Lib) messages: 113686 nosy: tarek, vinay.sajip priority: normal severity: normal status: open title: logging.addLevelName in file-based configurations versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 12 17:53:05 2010 From: report at bugs.python.org (Arman) Date: Thu, 12 Aug 2010 15:53:05 +0000 Subject: [New-bugs-announce] [issue9577] html parser bug related with CDATA sections In-Reply-To: <1281628385.29.0.0117705176523.issue9577@psf.upfronthosting.co.za> Message-ID: <1281628385.29.0.0117705176523.issue9577@psf.upfronthosting.co.za> New submission from Arman : When HTMLParser reaches CDATA element it enters cdata mode by calling set_cdata_mode (file html/parser.py line 270). this method assigns self.interesting member new value r'<(/|\Z)'. But this is not correct. Consider following case matches with r'<(/|\Z)' and parser gets confused and produce wrong results. You can see such real htmls in www.ahram.org.eg www.chefkoch.de www.chemieonline.de www.eip.gov.eg www.rezepte.li www.scienceworld.com The solution can be to keep interesting_cdata_script = re.compile(r'<(/|\z)script') interesting_cdata_style = re.compile(r'<(/|\z)style') instead of interesting_cdata = re.compile(r'<(/|\Z)') and depending on what tag is begins (script or style) set_cdata_mode can assign correct regexp to self.interesting member. Please contact with me via email if you need more details. arman.hunanyan at gmail.com ---------- components: Library (Lib) messages: 113688 nosy: Hunanyan priority: normal severity: normal status: open title: html parser bug related with CDATA sections type: behavior versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 12 19:52:38 2010 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 12 Aug 2010 17:52:38 +0000 Subject: [New-bugs-announce] [issue9578] int() raises UnicodeDecodeError when called on malformed string In-Reply-To: <1281635558.42.0.560480502776.issue9578@psf.upfronthosting.co.za> Message-ID: <1281635558.42.0.560480502776.issue9578@psf.upfronthosting.co.za> New submission from Alexander Belopolsky : >>> int('\xA11') Traceback (most recent call last): File "", line 1, in UnicodeDecodeError: 'utf8' codec can't decode byte 0xa1 in position 0: invalid start byte This is inconsistent with other number types' behavior: >>> float(b'\xA1') Traceback (most recent call last): File "", line 1, in ValueError: could not convert string to float: ? ---------- messages: 113694 nosy: belopolsky, mark.dickinson priority: normal severity: normal status: open title: int() raises UnicodeDecodeError when called on malformed string _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 12 21:12:14 2010 From: report at bugs.python.org (David Watson) Date: Thu, 12 Aug 2010 19:12:14 +0000 Subject: [New-bugs-announce] [issue9579] In 3.x, os.confstr() returns garbage if value is longer than 255 bytes In-Reply-To: <1281640334.52.0.33251169247.issue9579@psf.upfronthosting.co.za> Message-ID: <1281640334.52.0.33251169247.issue9579@psf.upfronthosting.co.za> New submission from David Watson : It may be hard to find a configuration string this long, but you can see the problem if you apply the attached confstr-reduce-bufsize.diff to reduce the size of the local array buffer that posix_confstr() uses. With it applied: >>> import os >>> print(ascii(os.confstr("CS_PATH"))) '\x00\ucbcb\ucbcb\ucbcb\ucbcb\ucbcb\ucbcb\ucbcb\ucbcb\ucbcb\ucbcb\ucbcb\ucbcb' The problem arises because the code first tries to receive the configuration string into the local buffer (char buffer[256], reduced to char buffer[1] above), but then tries to receive it directly into a string object if it doesn't fit. You can see what's gone wrong by comparing the working code in 2.x: if ((unsigned int)len >= sizeof(buffer)) { result = PyString_FromStringAndSize(NULL, len-1); if (result != NULL) confstr(name, PyString_AS_STRING(result), len); } else result = PyString_FromStringAndSize(buffer, len-1); with the code in 3.x: if ((unsigned int)len >= sizeof(buffer)) { result = PyUnicode_FromStringAndSize(NULL, len-1); if (result != NULL) confstr(name, _PyUnicode_AsString(result), len); } else result = PyUnicode_FromStringAndSize(buffer, len-1); Namely, that in 3.x it tries to receive the string into the bytes object returned by _PyUnicode_AsString(), not the str object it has just allocated (which has the wrong format anyway - Py_UNICODE as opposed to char). The attached confstr-long-result.diff fixes this by allocating a separate buffer when necessary to receive the result, before creating the string object from it. By putting the confstr() call and allocation in a loop, it also handles the possibility that the value's length might change between calls. ---------- components: Extension Modules files: confstr-reduce-bufsize.diff keywords: patch messages: 113699 nosy: baikie priority: normal severity: normal status: open title: In 3.x, os.confstr() returns garbage if value is longer than 255 bytes type: behavior versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file18486/confstr-reduce-bufsize.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 12 21:16:56 2010 From: report at bugs.python.org (David Watson) Date: Thu, 12 Aug 2010 19:16:56 +0000 Subject: [New-bugs-announce] [issue9580] os.confstr() doesn't decode result according to PEP 383 In-Reply-To: <1281640616.02.0.101199550238.issue9580@psf.upfronthosting.co.za> Message-ID: <1281640616.02.0.101199550238.issue9580@psf.upfronthosting.co.za> New submission from David Watson : The attached patch applies on top of the patch from issue #9579 to make it use PyUnicode_DecodeFSDefaultAndSize(). (You could use it in the existing code, but until that issue is fixed, there is sometimes nothing to decode!) ---------- components: Extension Modules files: confstr-pep383.diff keywords: patch messages: 113700 nosy: baikie priority: normal severity: normal status: open title: os.confstr() doesn't decode result according to PEP 383 type: behavior versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file18488/confstr-pep383.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 12 22:47:22 2010 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 12 Aug 2010 20:47:22 +0000 Subject: [New-bugs-announce] [issue9581] PosixGroupsTester fails as root In-Reply-To: <1281646042.28.0.438449918806.issue9581@psf.upfronthosting.co.za> Message-ID: <1281646042.28.0.438449918806.issue9581@psf.upfronthosting.co.za> New submission from Antoine Pitrou : I get the following test_posix failures when run as root (Mandriva Linux): ====================================================================== ERROR: test_initgroups (test.test_posix.PosixGroupsTester) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/antoine/py3k/__svn__/Lib/test/test_posix.py", line 418, in test_initgroups g = g2 + 1 UnboundLocalError: local variable 'g2' referenced before assignment ====================================================================== FAIL: test_setgroups (test.test_posix.PosixGroupsTester) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/antoine/py3k/__svn__/Lib/test/test_posix.py", line 428, in test_setgroups self.assertListEqual(groups, posix.getgroups()) AssertionError: First sequence is not a list: range(0, 16) Under 2.6, there's another failure: ====================================================================== ERROR: test_setgroups (test.test_posix.PosixGroupsTester) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/antoine/cpython/26/Lib/test/test_posix.py", line 356, in test_setgroups self.assertListEqual(groups, posix.getgroups()) AttributeError: 'PosixGroupsTester' object has no attribute 'assertListEqual' ---------- assignee: ronaldoussoren components: Tests messages: 113705 nosy: exarkun, pitrou, ronaldoussoren priority: normal severity: normal stage: needs patch status: open title: PosixGroupsTester fails as root type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 13 00:03:42 2010 From: report at bugs.python.org (Robert Mohr) Date: Thu, 12 Aug 2010 22:03:42 +0000 Subject: [New-bugs-announce] [issue9582] documentation line needs rewording In-Reply-To: <1281650622.86.0.310513887463.issue9582@psf.upfronthosting.co.za> Message-ID: <1281650622.86.0.310513887463.issue9582@psf.upfronthosting.co.za> New submission from Robert Mohr : The last line of http://docs.python.org/faq/programming.html#is-there-a-scanf-or-sscanf-equivalent is not proper English: For more complicated input parsing, regular expressions more powerful than C?s sscanf() and better suited for the task. This also shows up in the 3.2 docs. ---------- assignee: docs at python components: Documentation messages: 113711 nosy: docs at python, mohrr priority: normal severity: normal status: open title: documentation line needs rewording versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 13 00:54:29 2010 From: report at bugs.python.org (Buck Golemon) Date: Thu, 12 Aug 2010 22:54:29 +0000 Subject: [New-bugs-announce] [issue9583] PYTHONOPTIMIZE = 0 is not honored In-Reply-To: <1281653669.29.0.363654611831.issue9583@psf.upfronthosting.co.za> Message-ID: <1281653669.29.0.363654611831.issue9583@psf.upfronthosting.co.za> New submission from Buck Golemon : In our environment, we have a wrapper which enables optimization by default (-OO). Most commandline tools which have a mode-changing flag such as this, also have a flag to do the opposite ( see: ls -t -U, wget -nv -v, ). I'd like to implement one or both of: 1) Add a -D option which is the opposite of -O. python -OO -D gives an optimization level of 1. 2) Honor PYTHONOPTIMIZE = 0. At the least, the man page needs to describe how these two methods interact. ---------- components: Interpreter Core messages: 113717 nosy: bukzor priority: normal severity: normal status: open title: PYTHONOPTIMIZE = 0 is not honored type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 13 10:36:53 2010 From: report at bugs.python.org (Mathieu Bridon) Date: Fri, 13 Aug 2010 08:36:53 +0000 Subject: [New-bugs-announce] [issue9584] Allow curly braces in fnmatch In-Reply-To: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za> Message-ID: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za> New submission from Mathieu Bridon : The attached patch allows for shell curly braces with fnmatch.filter(). This makes the following possible: >>> import fnmatch >>> import os >>> >>> for file in os.listdir('.'): ... if fnmatch.fnmatch(file, '*.{txt,csv}'): ... print file ... file.csv file.txt foo.txt This is especially convenient with the glob module: >>> import glob >>> glob.glob('*.{txt,csv}') ['file.csv', 'file.txt', 'foo.txt'] Hopefully, this makes fnmatch match better the behavior that people expect from a shell-style pattern matcher. Please note: I attached a patch that applies on the Python trunk, but only tested it on Python 2.5 on Windows. However, the fnmatch module doesn't seem to have changed substantially in between. ---------- components: Library (Lib) files: curly-fnmatch.patch keywords: patch messages: 113750 nosy: bochecha priority: normal severity: normal status: open title: Allow curly braces in fnmatch type: feature request Added file: http://bugs.python.org/file18497/curly-fnmatch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 13 14:15:10 2010 From: report at bugs.python.org (David Austin) Date: Fri, 13 Aug 2010 12:15:10 +0000 Subject: [New-bugs-announce] [issue9585] Largefile detection in configure fails In-Reply-To: <1281701710.49.0.222431192126.issue9585@psf.upfronthosting.co.za> Message-ID: <1281701710.49.0.222431192126.issue9585@psf.upfronthosting.co.za> New submission from David Austin : On a Linux Xeon server (x86_64) largefile support is (incorrectly) not included. configure determines: checking size of int... 4 checking size of long... 8 checking size of void *... 8 checking size of short... 2 checking size of float... 4 checking size of double... 8 . . . checking size of off_t... 8 but gets it wrong: checking whether to enable large file support... no To me it seems that the logic sizeof_off_t > sizeof_long is wrong. (I changed to comparison off_t > int and it built with largefile support and works fine.) $ uname -a Linux cpu3 2.6.31-14-server #48-Ubuntu SMP Fri Oct 16 15:07:34 UTC 2009 x86_64 GNU/Linux Ubuntu Lucid ---------- components: Build messages: 113757 nosy: David.Austin priority: normal severity: normal status: open title: Largefile detection in configure fails type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 13 14:43:48 2010 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 13 Aug 2010 12:43:48 +0000 Subject: [New-bugs-announce] [issue9586] "warning: comparison between pointer and integer" in multiprocessing build on PPC/Tiger In-Reply-To: <1281703428.64.0.285019462814.issue9586@psf.upfronthosting.co.za> Message-ID: <1281703428.64.0.285019462814.issue9586@psf.upfronthosting.co.za> New submission from Mark Dickinson : The PPC Tiger buildbot build output shows (e.g., for 2.7): /Users/buildbot/buildarea/2.7.parc-tiger-1/build/Modules/_multiprocessing/semaphore.c:421: warning: initialization makes pointer from integer without a cast /Users/buildbot/buildarea/2.7.parc-tiger-1/build/Modules/_multiprocessing/semaphore.c:441: warning: comparison between pointer and integer /Users/buildbot/buildarea/2.7.parc-tiger-1/build/Modules/_multiprocessing/semaphore.c:454: warning: comparison between pointer and integer /Users/buildbot/buildarea/2.7.parc-tiger-1/build/Modules/_multiprocessing/semaphore.c:476: warning: comparison between pointer and integer This looks as though it should be investigated; these comparisons are almost certainly doing the wrong thing. Including Antoine in the nosy because he was the last person to touch this code (I think). ---------- assignee: ronaldoussoren components: Build, Extension Modules, Macintosh messages: 113759 nosy: jnoller, mark.dickinson, pitrou, ronaldoussoren priority: normal severity: normal status: open title: "warning: comparison between pointer and integer" in multiprocessing build on PPC/Tiger versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 13 16:57:44 2010 From: report at bugs.python.org (Denver Coneybeare) Date: Fri, 13 Aug 2010 14:57:44 +0000 Subject: [New-bugs-announce] [issue9587] unittest.assertRaises() return the raised exception In-Reply-To: <1281711464.19.0.685530938413.issue9587@psf.upfronthosting.co.za> Message-ID: <1281711464.19.0.685530938413.issue9587@psf.upfronthosting.co.za> New submission from Denver Coneybeare : It would be great if unittest.assertRaises() returned the raised exception when it passes. This allows the caller to easily perform further checks on the exception, such as its attribute values. Currently assertRaises() returns None (when it doesn't return a context manager) so changing the return value should not break backwards compatibility. I see that this was already discussed in issue6275 but I'd like to resurrect the discussion since this is a common scenario in my unit tests, and I assume others. Revisions r76238 and r78110 added the ability to get the exception from the context manager (good) but sometimes using the context manager approach adds unnecessary bloat to already long-winded unit tests. I've attached a possible patch for the py3k branch (unittest.assertRaises.returnex.v1.patch). Thank you for (re)considering this topic :) Also, thank you Michael Foord for your recent improvements to unittest... the new features are very much appreciated! ---------- components: Library (Lib) files: unittest.assertRaises.returnex.v1.patch keywords: patch messages: 113781 nosy: denversc, krisvale, michael.foord priority: normal severity: normal status: open title: unittest.assertRaises() return the raised exception type: feature request versions: Python 3.2 Added file: http://bugs.python.org/file18501/unittest.assertRaises.returnex.v1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 13 18:33:10 2010 From: report at bugs.python.org (Brian Curtin) Date: Fri, 13 Aug 2010 16:33:10 +0000 Subject: [New-bugs-announce] [issue9588] Skip subprocess shell tests on Windows per file association setup In-Reply-To: <1281717190.24.0.68069123173.issue9588@psf.upfronthosting.co.za> Message-ID: <1281717190.24.0.68069123173.issue9588@psf.upfronthosting.co.za> New submission from Brian Curtin : The fix for #2304 causes issues on Windows if you have file associations setup that aren't Python interpters. In my case I have an association setup to open .py files in gvim, which causes the shell tests to hang until I quit the editor, then it fails because the output from gvim (nothing) doesn't match what it would when run through an interpreter. CommandsWithSpaces.test_shell_* tests should have a skip condition which checks file associations before running. The info is stored somewhere in the registry, so it should be easy to see that, e.g., gvim.exe isn't a valid Python interpreter. This issue only affects me at the moment, but it could affect other users who have tweaked file associations. ---------- assignee: brian.curtin components: Tests, Windows messages: 113794 nosy: brian.curtin, tim.golden priority: low severity: normal stage: needs patch status: open title: Skip subprocess shell tests on Windows per file association setup type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 13 19:31:17 2010 From: report at bugs.python.org (Florent Xicluna) Date: Fri, 13 Aug 2010 17:31:17 +0000 Subject: [New-bugs-announce] [issue9589] test_heapq: AttributeError: 'int' object has no attribute 'pop' In-Reply-To: <1281720677.01.0.254091973526.issue9589@psf.upfronthosting.co.za> Message-ID: <1281720677.01.0.254091973526.issue9589@psf.upfronthosting.co.za> New submission from Florent Xicluna : Various buildbots show a failure on test_heapq. * "x86 FreeBSD 3.x" failed on revision r83882 (r83869 was OK) http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%203.x/builds/492 and next runs were OK, too * "PPC (Leopard|Tiger) 3.x" and "x86 Tiger 3.x" fail consistently from r83889 onwards. * all "gentoo 3.x" and "Ubuntu 3.x" fail on r83981 http://www.python.org/dev/buildbot/all/builders/x86%20gentoo%203.x/builds/2816 http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%203.x/builds/1707 ---------- components: Library (Lib), Tests keywords: buildbot messages: 113798 nosy: flox, haypo priority: normal severity: normal stage: needs patch status: open title: test_heapq: AttributeError: 'int' object has no attribute 'pop' type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 13 20:05:29 2010 From: report at bugs.python.org (Anthony Long) Date: Fri, 13 Aug 2010 18:05:29 +0000 Subject: [New-bugs-announce] [issue9590] __init__ TypeError reverses expected vs received args In-Reply-To: <1281722729.75.0.301168748146.issue9590@psf.upfronthosting.co.za> Message-ID: <1281722729.75.0.301168748146.issue9590@psf.upfronthosting.co.za> New submission from Anthony Long : import unittest from selenium import selenium class SetupSomething(unittest.TestCase): def setUp(self, URL): self.selenium = selenium("localhost", 4444, "*firefox", self.URL) def tearDown(self): pass class TestSomething(SetupSomething): def __init__(): print "bug." def setUp(self): self.URL = "http://google.com/" def tearDown(self): pass def test_tester(self): self.selenium.open('/') print "no" unittest.main() ---- TypeError: '__init__() takes no arguments (2 given)' ---------- messages: 113802 nosy: antlong priority: normal severity: normal status: open title: __init__ TypeError reverses expected vs received args versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 13 20:47:25 2010 From: report at bugs.python.org (Volodymyr Kostyrko) Date: Fri, 13 Aug 2010 18:47:25 +0000 Subject: [New-bugs-announce] [issue9591] kqueu not reporting EOF under certain circumstances In-Reply-To: <1281725245.42.0.301580096416.issue9591@psf.upfronthosting.co.za> Message-ID: <1281725245.42.0.301580096416.issue9591@psf.upfronthosting.co.za> New submission from Volodymyr Kostyrko : This one is BSD related. FreeBSD 8.1. This works: # cat test.py | ./test.py -1 684 32768 0 0 # This hangs: # ./test.py < file -1 684 0 0 0 The difference is that in second case popped kevent lacks any data on EOF. ---------- components: Library (Lib) files: test.py messages: 113811 nosy: Volodymyr.Kostyrko priority: normal severity: normal status: open title: kqueu not reporting EOF under certain circumstances type: behavior versions: Python 3.1 Added file: http://bugs.python.org/file18506/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 13 21:02:48 2010 From: report at bugs.python.org (Freek Dijkstra) Date: Fri, 13 Aug 2010 19:02:48 +0000 Subject: [New-bugs-announce] [issue9592] Limitations in objects returned by multiprocessing Pool In-Reply-To: <1281726168.11.0.648826556363.issue9592@psf.upfronthosting.co.za> Message-ID: <1281726168.11.0.648826556363.issue9592@psf.upfronthosting.co.za> New submission from Freek Dijkstra : I came across three limitation in the multiprocessing module that were not handled correctly. Attached is a file that reproduces the errors in minimal code. I tested them with Python 2.6.5 and 3.1.2. Expected result: multiprocessing.Pool's promises a map function where each result is returned transparently to the main process (despite that the calculation was done in a subprocess) Actual result: Not all values returned by a subprocess are returned transparently. I expected multiprocessing to handle these cases gracefully by yielding an Exception in the Main process. The cases I found are: 1) A multiprocessing worker can not return (return, not raise!) an Exception. If this is attempted, the result handler thread in the Pool calls the exception with no arguments, which might raise an error if multiple arguments are required: TypeError: ('__init__() takes exactly 2 arguments (1 given)', , ()) 2) A multiprocessing worker can not return an hashlib Object. If this is attempted, pickle returns an error: PicklingError: Can't pickle : attribute lookup _hashlib.HASH failed 3) A multiprocessing worker can not return an Object which overrides __getattr__, and accesses a variable from self in __getattr__. If this is attempted, Python 2.6 crashes with a bus error: Program terminated by uncaught signal #10 after 1.56 seconds. Python 3.1 yields the error: RuntimeError: maximum recursion depth exceeded while calling a Python object ---------- components: Library (Lib) files: multiprocessingbugs.py messages: 113816 nosy: macfreek priority: normal severity: normal status: open title: Limitations in objects returned by multiprocessing Pool type: crash versions: Python 2.6, Python 3.1 Added file: http://bugs.python.org/file18507/multiprocessingbugs.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 13 21:27:03 2010 From: report at bugs.python.org (Joseph Copenhaver) Date: Fri, 13 Aug 2010 19:27:03 +0000 Subject: [New-bugs-announce] [issue9593] utf8 codec readlines error after "\x85 " In-Reply-To: <1281727623.94.0.00268299366408.issue9593@psf.upfronthosting.co.za> Message-ID: <1281727623.94.0.00268299366408.issue9593@psf.upfronthosting.co.za> New submission from Joseph Copenhaver : The IO readlines() facility incorrectly processes utf8 files for some unknown reason. Specifically, the call generates too many entries in the lines array result after a character sequence "\x85 blah" which gets cut as ("\x85 ","blah") according the the resultant array. My workaround for this issue is not elegant, especially since I need the newline characters: #BEGIN: WTF a_str_whole = fs_in.read() fs_in.close() a_str_lines = a_str_whole.split("\n") for idx in range(0,len(a_str_lines)-1): a_str_lines[idx]+="\n" #END: WTF Attached is an example script that defines the problem clearly. ---------- components: IO, Interpreter Core, Regular Expressions, Unicode files: ErrorProof-utf8-x85.py messages: 113818 nosy: jcope priority: normal severity: normal status: open title: utf8 codec readlines error after "\x85 " type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file18508/ErrorProof-utf8-x85.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 13 23:34:36 2010 From: report at bugs.python.org (Sridhar Ratnakumar) Date: Fri, 13 Aug 2010 21:34:36 +0000 Subject: [New-bugs-announce] [issue9594] typo on Mac/Makefile.in? s/pythonw/python/ In-Reply-To: <1281735276.23.0.449873150799.issue9594@psf.upfronthosting.co.za> Message-ID: <1281735276.23.0.449873150799.issue9594@psf.upfronthosting.co.za> New submission from Sridhar Ratnakumar : >From Mac/Makefile.in: [...] ifneq ($(LIPO_32BIT_FLAGS),) lipo $(LIPO_32BIT_FLAGS) -output $(DESTDIR)$(prefix)/bin/python$(VERSION)-32 pythonw lipo $(LIPO_32BIT_FLAGS) -output $(DESTDIR)$(prefix)/bin/pythonw$(VERSION)-32 pythonw ln -sf python$(VERSION)-32 "$(DESTDIR)$(prefix)/bin/python-32" ln -sf pythonw$(VERSION)-32 "$(DESTDIR)$(prefix)/bin/pythonw-32" endif [...] Shouldn't the last word in the first line be `python` instead of `pythonw`? http://svn.python.org/view/python/trunk/Mac/Makefile.in?annotate=77031#l55 ---------- assignee: ronaldoussoren components: Build, Macintosh messages: 113836 nosy: ronaldoussoren, srid priority: normal severity: normal status: open title: typo on Mac/Makefile.in? s/pythonw/python/ type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 13 23:47:29 2010 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 13 Aug 2010 21:47:29 +0000 Subject: [New-bugs-announce] [issue9595] PC/getpathp.c unused? Message-ID: <1281736049.14.0.316671320549.issue9595@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: pitrou priority: normal severity: normal status: open title: PC/getpathp.c unused? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 13 23:48:18 2010 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 13 Aug 2010 21:48:18 +0000 Subject: [New-bugs-announce] [issue9596] PC/getpathp.c unused? In-Reply-To: <1281736098.81.0.874478612531.issue9596@psf.upfronthosting.co.za> Message-ID: <1281736098.81.0.874478612531.issue9596@psf.upfronthosting.co.za> New submission from Antoine Pitrou : PC/getpathp.c claims it is ?Used by DOS, OS/2, Windows 3.1, Windows 95/98, Windows NT?, but Modules/getpath.c already tries to be cross-platform. It is not obvious whether the former is used at all. ---------- components: Interpreter Core messages: 113839 nosy: loewis, pitrou priority: low severity: normal status: open title: PC/getpathp.c unused? type: resource usage versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 14 00:29:01 2010 From: report at bugs.python.org (Sridhar Ratnakumar) Date: Fri, 13 Aug 2010 22:29:01 +0000 Subject: [New-bugs-announce] [issue9597] mac: Install 2to3 in /usr/local/bin In-Reply-To: <1281738541.55.0.960534882511.issue9597@psf.upfronthosting.co.za> Message-ID: <1281738541.55.0.960534882511.issue9597@psf.upfronthosting.co.za> New submission from Sridhar Ratnakumar : According to Mac/Makefile.in, scripts like pydoc, idle, smtpd.py and so on gets symlinked in /usr/local/bin but there is none for 2to3. Perhaps this was forgotten? ---------- assignee: ronaldoussoren components: 2to3 (2.x to 3.0 conversion tool), Build, Macintosh messages: 113845 nosy: ronaldoussoren, srid priority: normal severity: normal status: open title: mac: Install 2to3 in /usr/local/bin type: feature request versions: Python 2.6, Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 14 01:06:14 2010 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 13 Aug 2010 23:06:14 +0000 Subject: [New-bugs-announce] [issue9598] untabify.py fails on files that contain non-ascii characters In-Reply-To: <1281740774.41.0.842761146652.issue9598@psf.upfronthosting.co.za> Message-ID: <1281740774.41.0.842761146652.issue9598@psf.upfronthosting.co.za> New submission from Alexander Belopolsky : For example: $ ./python.exe Tools/scripts/untabify.py Modules/_heapqmodule.c Traceback (most recent call last): ... (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf8' codec can't decode byte 0xe7 in position 173: invalid continuation byte I am not sure what relevant C standard has to say about using non-ascii characters in comments, but the checking tool should not fail with a traceback in such situation. ---------- components: Demos and Tools messages: 113849 nosy: belopolsky priority: normal severity: normal status: open title: untabify.py fails on files that contain non-ascii characters type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 14 03:20:50 2010 From: report at bugs.python.org (STINNER Victor) Date: Sat, 14 Aug 2010 01:20:50 +0000 Subject: [New-bugs-announce] [issue9599] Add PySys_FormatStdout and PySys_FormatStderr functions In-Reply-To: <1281748850.03.0.226661002254.issue9599@psf.upfronthosting.co.za> Message-ID: <1281748850.03.0.226661002254.issue9599@psf.upfronthosting.co.za> New submission from STINNER Victor : For my work #9425 (Rewrite import machinery to work with unicode paths), I need a function to write unicode strings to sys.stderr (especially to write messages on import in verbose mode). Attached patch creates PySys_FormatStdout() and PySys_FormatStderr(). It's the same idea than the new function PyErr_WarnFormat() vs PyErr_WarnEx() (added by r83976): similar API but use PyUnicode_FromFormatV(). PySys_FormatStdout() and PySys_FormatStderr() don't truncate the output message. PySys_WriteStdout() and PySys_WriteStderr() truncate the output because they use a static buffer of 1001 bytes, but I don't know if it is an implementation choice (to avoid bugs?) or just a limitation of the implementation. About the patch: - rename mywrite() to sys_write() to use a less generic name (it helps debugging) - in sys_write(): don't call PyErr_Clear() if the second call to sys_pyfile_write() fails, because it is useless. fputs() doesn't care to Python exceptions and the exception state is restored just after the call to fputs() - sys_format() encodes the message to utf-8 on sys_pyfile_write_unicode() failure because utf-8 is able to encode all unicode characters (except unicode surrogates). Use an error handler to escape surrogates may avoid encode errors, but it's not important here because sys_pyfile_write_unicode() should not fail. sys_pyfile_write_unicode() knows better how to handle surrogate characters (sys.stderr uses backslashreplace error handler by default). For #9425, I only need PySys_FormatStderr(), but I added also PySys_FormatStdout() just to be consistent with PySys_Write*() and because it only costs a few line of code. ---------- components: Interpreter Core, Unicode files: pysys_formatstderr.patch keywords: patch messages: 113861 nosy: haypo priority: normal severity: normal status: open title: Add PySys_FormatStdout and PySys_FormatStderr functions versions: Python 3.2 Added file: http://bugs.python.org/file18518/pysys_formatstderr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 14 05:30:33 2010 From: report at bugs.python.org (cipater) Date: Sat, 14 Aug 2010 03:30:33 +0000 Subject: [New-bugs-announce] [issue9600] multiprocessing Pool instantiation crashes on 64 bit 2.6.6rc1 under Windows 7 In-Reply-To: <1281756633.5.0.731443815924.issue9600@psf.upfronthosting.co.za> Message-ID: <1281756633.5.0.731443815924.issue9600@psf.upfronthosting.co.za> New submission from cipater : I'm running 2.6.6rc1 64 bit on Windows 7 I get the following error when I try to instantiate a Pool: >>> import multiprocessing >>> p = Pool(processes = 2) Traceback (most recent call last): File "", line 1, in File "c:\Python26\lib\multiprocessing\__init__.py", line 227, in Pool return Pool(processes, initializer, initargs) File "c:\Python26\lib\multiprocessing\pool.py", line 84, in __init__ self._setup_queues() File "c:\Python26\lib\multiprocessing\pool.py", line 130, in _setup_queues from .queues import SimpleQueue File "c:\Python26\lib\multiprocessing\queues.py", line 22, in from multiprocessing.synchronize import Lock, BoundedSemaphore, Semaphore, Condition File "c:\Python26\lib\multiprocessing\synchronize.py", line 22, in from multiprocessing.forking import assert_spawning, Popen File "c:\Python26\lib\multiprocessing\forking.py", line 153, in from ._multiprocessing import win32, Connection, PipeConnection ImportError: No module named _multiprocessing >>> ---------- components: Extension Modules messages: 113864 nosy: cipater priority: normal severity: normal status: open title: multiprocessing Pool instantiation crashes on 64 bit 2.6.6rc1 under Windows 7 type: crash versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 14 05:41:59 2010 From: report at bugs.python.org (alphablue52) Date: Sat, 14 Aug 2010 03:41:59 +0000 Subject: [New-bugs-announce] [issue9601] ftplib should accept 250 on MKD In-Reply-To: <1281757319.27.0.238549854575.issue9601@psf.upfronthosting.co.za> Message-ID: <1281757319.27.0.238549854575.issue9601@psf.upfronthosting.co.za> New submission from alphablue52 : I try to use ftplib for a Webspace running on a Windows Server machine. The server responses 250 instead of 257 (which would be correct according to RFC959, ftp) It would be nice if ftplib could also tolerate the 250 "Requested file ation okay, completed" code, since I cannot change the server (or beat that M$ programmer). Thanks! ---------- components: Library (Lib) messages: 113866 nosy: alphablue52 priority: normal severity: normal status: open title: ftplib should accept 250 on MKD versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 14 15:42:32 2010 From: report at bugs.python.org (STINNER Victor) Date: Sat, 14 Aug 2010 13:42:32 +0000 Subject: [New-bugs-announce] [issue9602] PyObject_AsCharBuffer() should only accept read-only objects In-Reply-To: <1281793352.06.0.62940034279.issue9602@psf.upfronthosting.co.za> Message-ID: <1281793352.06.0.62940034279.issue9602@psf.upfronthosting.co.za> New submission from STINNER Victor : mmap, buffer, bytearray, string and unicode objects set the char buffer callback (bf_getcharbuffer). The bytearray object sets also the release buffer callback (bf_releasebuffer). In Python 2.7, PyObject_AsCharBuffer() accepts bytearray objects, whereas the "t#" format of PyArg_Parse functions rejects byte bytearray objects (expect an "pinned buffer object"). In Python 3.2, PyObject_AsCharBuffer() releases the buffer. PyObject_AsCharBuffer() documentation (in 2.7 and 3.2) says that the function only accepts read-only objects. Something is wrong here. If the caller doesn't hold a kind of lock, the object cannot be protected against futher modifications. The caller has to ensure that the object is not modifiable until it finishs to use the char* pointer. I think that it would be safer to respect the documentation: PyObject_AsCharBuffer() should only accept read-only objects. The most important change is that functions using PyObject_AsCharBuffer() will not accept bytearray objects anymore. Attached patch (for Python 2.7) changes PyObject_AsCharBuffer() to reject modifiable objects. It removes also the character buffer callback from the bytearray type. To avoid breaking compatibility too much, I patched int(), long() and float() to still support bytearray objects. Examples of functions rejecting bytearray with the patch: - int(), long(), float(), complex() - many str methods: split, partition, rpartition, rsplit, index, find, count, translate, replace, startswith, endswith - writelines() of file objects (eg. sys.stdout.writelines) - writelines() method of a bz2 file -- My patch breaks backward compatibility, and I don't know that it is acceptable in Python 2.7. I will write a similar patch for Python 3.2. ---------- components: Interpreter Core files: PyObject_AsCharBuffer-2.7.patch keywords: patch messages: 113895 nosy: haypo, pitrou priority: normal severity: normal status: open title: PyObject_AsCharBuffer() should only accept read-only objects versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file18523/PyObject_AsCharBuffer-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 14 21:09:13 2010 From: report at bugs.python.org (David Watson) Date: Sat, 14 Aug 2010 19:09:13 +0000 Subject: [New-bugs-announce] [issue9603] os.ttyname() and os.ctermid() don't decode result according to PEP 383 In-Reply-To: <1281812953.3.0.0625643381437.issue9603@psf.upfronthosting.co.za> Message-ID: <1281812953.3.0.0625643381437.issue9603@psf.upfronthosting.co.za> New submission from David Watson : These functions each return the path to a terminal, so they should use PyUnicode_DecodeFSDefault(). Patch attached. ---------- components: Extension Modules files: ttyname-ctermid-pep383.diff keywords: patch messages: 113920 nosy: baikie priority: normal severity: normal status: open title: os.ttyname() and os.ctermid() don't decode result according to PEP 383 type: behavior versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file18529/ttyname-ctermid-pep383.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 14 21:11:30 2010 From: report at bugs.python.org (David Watson) Date: Sat, 14 Aug 2010 19:11:30 +0000 Subject: [New-bugs-announce] [issue9604] os.initgroups() doesn't accept PEP 383 usernames returned by pwd module In-Reply-To: <1281813090.71.0.270641843019.issue9604@psf.upfronthosting.co.za> Message-ID: <1281813090.71.0.270641843019.issue9604@psf.upfronthosting.co.za> New submission from David Watson : The pwd module decodes usernames using PyUnicode_DecodeFSDefault(), so initgroups() should use PyUnicode_FSConverter() for the username. Patch attached. ---------- components: Extension Modules files: initgroups-pep383.diff keywords: patch messages: 113921 nosy: baikie priority: normal severity: normal status: open title: os.initgroups() doesn't accept PEP 383 usernames returned by pwd module type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file18530/initgroups-pep383.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 14 21:13:54 2010 From: report at bugs.python.org (David Watson) Date: Sat, 14 Aug 2010 19:13:54 +0000 Subject: [New-bugs-announce] [issue9605] os.getlogin() should use PEP 383 decoding to match the pwd module In-Reply-To: <1281813234.71.0.460155631473.issue9605@psf.upfronthosting.co.za> Message-ID: <1281813234.71.0.460155631473.issue9605@psf.upfronthosting.co.za> New submission from David Watson : The pwd module decodes usernames with PyUnicode_DecodeFSDefault(), and the LOGNAME environment variable (suggested as an alternative to getlogin()) is decoded the same way. Attaching a patch to use PyUnicode_DecodeFSDefault() in getlogin(). ---------- components: Extension Modules files: getlogin-pep383.diff keywords: patch messages: 113922 nosy: baikie priority: normal severity: normal status: open title: os.getlogin() should use PEP 383 decoding to match the pwd module type: behavior versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file18531/getlogin-pep383.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 14 23:38:24 2010 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 14 Aug 2010 21:38:24 +0000 Subject: [New-bugs-announce] [issue9606] logging filter is ignored when added to root handler In-Reply-To: <1281821904.42.0.0351548448859.issue9606@psf.upfronthosting.co.za> Message-ID: <1281821904.42.0.0351548448859.issue9606@psf.upfronthosting.co.za> New submission from Nikolaus Rath : I believe the following should print only one log message, not two: import logging class Filter(object): def filter(self, record): return record.name == 'foo' logger = logging.getLogger() formatter = logging.Formatter('%(message)s') handler = logging.StreamHandler() handler.setFormatter(formatter) logger.addFilter(Filter()) logger.addHandler(handler) logging.getLogger('foo').warn('foo!') logging.getLogger('bar').warn('bar!') If the filter is added to the handler instead of the logger, everything works as expected. If this is desired behaviour, please consider this a bug against the documentation. In that case I propose to extend the documentation of Logger.addFilter() as follows: "Note that the filter will act only on log messages that are generated by this logger, and not on messages that have been generated by descendant loggers." ---------- components: Library (Lib) messages: 113932 nosy: Nikratio priority: normal severity: normal status: open title: logging filter is ignored when added to root handler type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 15 07:15:48 2010 From: report at bugs.python.org (Greg Malcolm) Date: Sun, 15 Aug 2010 05:15:48 +0000 Subject: [New-bugs-announce] [issue9607] Test file 'test_keyword.py' submission for use with keyword.py In-Reply-To: <1281849348.53.0.810648733764.issue9607@psf.upfronthosting.co.za> Message-ID: <1281849348.53.0.810648733764.issue9607@psf.upfronthosting.co.za> New submission from Greg Malcolm : 'keyword.py' didn't have any tests, so I wrote some. Most of the tests are are for the main() method, which self-populates the keywords section of keyword.py with keywords taken from a grammar file, 'Python/graminit.c'. The main() method allows you to choose the grammar file and the target file, so I've written the tests such that the actual keyword.py does not have to modify itself. Most of the tests generate dummy keyword.py and graminit.c files for parsing. They are all deleted in the tearUp() stages of each test. I've timed the tests. In total they take approximately 3 seconds so you may want to tag some of them as "slow". Also I've only tested on the mac, so someone may want to check it runs ok on Windows. Most of the patch was written at the PyOhio 2010 Sprints. Thanks go to David Murray for advice given while working on it. ---------- components: Tests files: test_keyword.patch keywords: patch messages: 113942 nosy: gregmalcolm, r.david.murray priority: normal severity: normal status: open title: Test file 'test_keyword.py' submission for use with keyword.py type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file18537/test_keyword.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 15 14:23:45 2010 From: report at bugs.python.org (Floris Bruynooghe) Date: Sun, 15 Aug 2010 12:23:45 +0000 Subject: [New-bugs-announce] [issue9608] Re-phrase best way of using exceptions in doanddont.rst In-Reply-To: <1281875025.64.0.398474348151.issue9608@psf.upfronthosting.co.za> Message-ID: <1281875025.64.0.398474348151.issue9608@psf.upfronthosting.co.za> New submission from Floris Bruynooghe : The description of how to best use exceptions is slightly confusing and led me to believe there was an issue when using open() as a context manager. The main issue is that the wording seems to suggest the example above it is the best and not the very last. Attached is a patch which uses a slightly different wording which IMHO makes it clearer that the with-statement is the preferred method and does not introduce subtle bugs. ---------- assignee: docs at python components: Documentation files: doandont.diff keywords: patch messages: 113949 nosy: docs at python, flub priority: normal severity: normal status: open title: Re-phrase best way of using exceptions in doanddont.rst type: feature request versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file18538/doandont.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 15 17:09:36 2010 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sun, 15 Aug 2010 15:09:36 +0000 Subject: [New-bugs-announce] [issue9609] make cProfile multi-stack aware In-Reply-To: <1281884976.7.0.103613520648.issue9609@psf.upfronthosting.co.za> Message-ID: <1281884976.7.0.103613520648.issue9609@psf.upfronthosting.co.za> New submission from Kristj?n Valur J?nsson : One of the problems with the profiling modules provided with Python is that they are not useful in the presence of multiple threads. This is because time spent in a different thread may be falsely attributed to some random place in a thread being profiled. This patch helps fix that, by making the _lsprof.c module (the engine behind cProfile) multi-stack aware. At every entry into the profiler, a check is made to see which stack is in operation (by looking at the thread state). The previous stack is then paused and profiling commences on the new stack. Time spent on other stacks is then subtracted from the measured time on each stack. A complication arises because it is no longer possible to determine the recursion level of each function (or subcall instance) on each stack by looking at the function's entry alone. For this reason, it becomes necessary to walk the stack in cases where there are multiple stacks and multiple total recursions seen for the entries. This patch has been successfully used, with a modifiaction for stackless python, in production at CCP (the modification uses the Tasklet ID rather than the TLS pointer as a key to the stack map). To be useful, it is important that all threads in the process are set to use the same cProfile.Profiler() instance. Currently there is no easy way to do that and this patch doesn't attempt to fix that. But is is possible that an application designed for profiling would attach the profiler at each thread start point. (In the version of Stackless Python that this is used on, it is possible to enable tracing/profiling of all tasklets simultaneously) ---------- components: Extension Modules files: _lsprof.patch keywords: patch, patch messages: 113964 nosy: krisvale priority: normal severity: normal status: open title: make cProfile multi-stack aware type: feature request versions: Python 3.2 Added file: http://bugs.python.org/file18539/_lsprof.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 15 18:03:00 2010 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 15 Aug 2010 16:03:00 +0000 Subject: [New-bugs-announce] [issue9610] buildbot: uncaptured python exception (smtpd), but no failure in regrtest In-Reply-To: <1281888180.27.0.972389981931.issue9610@psf.upfronthosting.co.za> Message-ID: <1281888180.27.0.972389981931.issue9610@psf.upfronthosting.co.za> New submission from Florent Xicluna : It occurs on PPC Leopard 3.x buildbot. (...) [184/346] test_ssl error: uncaptured python exception, closing channel (:pop from empty list [/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/asyncore.py|read|79] [/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/asyncore.py|handle_read_event|435] [/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/asynchat.py|handle_read|128] [/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/asyncore.py|recv|375] [/Users/buildbot/buildarea/3.x.parc-leopard-1/build/Lib/test/mock_socket.py|recv|47]) (...) http://www.python.org/dev/buildbot/all/builders/PPC%20Leopard%203.x/builds/295 ---------- assignee: ronaldoussoren components: Macintosh, Tests keywords: buildbot messages: 113971 nosy: flox, ronaldoussoren priority: normal severity: normal status: open title: buildbot: uncaptured python exception (smtpd), but no failure in regrtest type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 15 19:25:42 2010 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 15 Aug 2010 17:25:42 +0000 Subject: [New-bugs-announce] [issue9611] FileIO not 64-bit safe under Windows In-Reply-To: <1281893142.91.0.972520708976.issue9611@psf.upfronthosting.co.za> Message-ID: <1281893142.91.0.972520708976.issue9611@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Modules/_io/fileio.c assumes that read() and write() allow a Py_ssize_t length, but under Windows the length is an int, limiting chunk size to 2GB. It should be easy enough to read or write in multiple chunks, although testing might be difficult. ---------- components: Extension Modules, Windows messages: 113974 nosy: pitrou priority: normal severity: normal status: open title: FileIO not 64-bit safe under Windows type: behavior versions: Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 15 19:33:37 2010 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 15 Aug 2010 17:33:37 +0000 Subject: [New-bugs-announce] [issue9612] setobject.c warnings under 64-bit Windows In-Reply-To: <1281893617.3.0.762329491862.issue9612@psf.upfronthosting.co.za> Message-ID: <1281893617.3.0.762329491862.issue9612@psf.upfronthosting.co.za> New submission from Antoine Pitrou : None of these warnings look critical (one affects the "search finger" optimization of pop(), one affects the result from __length_hint__ on set iterators, and the other the hash value of frozensets without any obviously bad consequences), but you might want to take a look at them anyway. (for the record, a C "long" is 32-bit under 64-bit Windows, so a Py_ssize_t won't fit in it) 1>..\Objects\setobject.c(743) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'long', possible loss of data 1>..\Objects\setobject.c(772) : warning C4244: '*=' : conversion from 'Py_ssize_t' to 'long', possible loss of data 1>..\Objects\setobject.c(819) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'long', possible loss of data ---------- assignee: rhettinger components: Interpreter Core messages: 113976 nosy: pitrou, rhettinger priority: low severity: normal status: open title: setobject.c warnings under 64-bit Windows type: behavior versions: Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 15 20:02:27 2010 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 15 Aug 2010 18:02:27 +0000 Subject: [New-bugs-announce] [issue9613] Python considers pid longs under 64-bit Windows In-Reply-To: <1281895347.49.0.271541660208.issue9613@psf.upfronthosting.co.za> Message-ID: <1281895347.49.0.271541660208.issue9613@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Under 64-bit Windows, Python aliases PyLong_FromPid() to PyLong_FromLong() (and PyLong_AsPid() to PyLong_AsLong()), but a C "long" is 32-bit, while apparently the MSVCRT defines a pid to be intptr_t, that is 64-bit. A potential loss of data ensues. ---------- components: Extension Modules, Interpreter Core, Windows messages: 113982 nosy: brian.curtin, pitrou, tim.golden priority: normal severity: normal status: open title: Python considers pid longs under 64-bit Windows type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 15 20:13:02 2010 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 15 Aug 2010 18:13:02 +0000 Subject: [New-bugs-announce] [issue9614] _pickle is not entirely 64-bit safe In-Reply-To: <1281895982.89.0.760453311109.issue9614@psf.upfronthosting.co.za> Message-ID: <1281895982.89.0.760453311109.issue9614@psf.upfronthosting.co.za> New submission from Antoine Pitrou : A number of legitimate warnings get emitted under a 64-bit Windows build (in many places, _pickle uses ints or longs instead of "Py_ssize_t" variable to store various lengths and sizes): 1>..\Modules\_pickle.c(284) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 1>..\Modules\_pickle.c(301) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 1>..\Modules\_pickle.c(461) : warning C4244: '+=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 1>..\Modules\_pickle.c(628) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'long', possible loss of data 1>..\Modules\_pickle.c(647) : warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data 1>..\Modules\_pickle.c(1320) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 1>..\Modules\_pickle.c(1558) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data 1>..\Modules\_pickle.c(1806) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data ---------- components: Extension Modules messages: 113986 nosy: alexandre.vassalotti, pitrou priority: normal severity: normal status: open title: _pickle is not entirely 64-bit safe type: behavior versions: Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 15 21:11:22 2010 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 15 Aug 2010 19:11:22 +0000 Subject: [New-bugs-announce] [issue9615] Building SSL fails under 64-bit Windows In-Reply-To: <1281899482.21.0.598309644137.issue9615@psf.upfronthosting.co.za> Message-ID: <1281899482.21.0.598309644137.issue9615@psf.upfronthosting.co.za> New submission from Antoine Pitrou : This is what I get when MSVC 2008 tries to build the _ssl module: 8>------ Build started: Project: _ssl, Configuration: Debug x64 ------ 8>Performing Pre-Build Event... 8>'""' is not recognized as an internal or external command, 8>operable program or batch file. 8>Project : error PRJ0019: A tool returned an error code from "Performing Pre-Build Event..." 8>Build log was saved at "file://Z:\py3k\__svn__\PCbuild\x64-temp-Debug\_ssl\BuildLog.htm" 8>_ssl - 1 error(s), 0 warning(s) The build log has the following contents: Creating temporary file "C:\Users\Antoine\AppData\Local\Temp\BAT00012021242476.bat" with contents [ @echo off cd "Z:\py3k\__svn__\PCbuild\" "" build_ssl.py Release x64 -a if errorlevel 1 goto VCReportError goto VCEnd :VCReportError echo Project : error PRJ0019: A tool returned an error code from "Performing Pre-Build Event..." exit 1 :VCEnd ] Creating command line "C:\Users\Antoine\AppData\Local\Temp\BAT00012021242476.bat" I have installed Perl and Python 2.7. ---------- components: Build, Extension Modules, Windows messages: 113998 nosy: loewis, pitrou priority: normal severity: normal status: open title: Building SSL fails under 64-bit Windows versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 15 22:12:26 2010 From: report at bugs.python.org (Neil Harkins) Date: Sun, 15 Aug 2010 20:12:26 +0000 Subject: [New-bugs-announce] [issue9616] copy.deepcopy() copying pointers from a dict/dict/list, should copy values In-Reply-To: <1281903146.28.0.294470710617.issue9616@psf.upfronthosting.co.za> Message-ID: <1281903146.28.0.294470710617.issue9616@psf.upfronthosting.co.za> New submission from Neil Harkins : hi. after using deepcopy() on a nested dict/list structure, i noticed that modifications to the deepcopied structure were affecting the original. this looks to me like a serious bug: >>> import copy >>> foo = { 'a':[1,2,3], 'b':{'c':[4,5]} } >>> bar = copy.deepcopy(foo) >>> id(foo) 4297360512 >>> id(bar) 4297373104 >>> id(foo['a']) 4299410752 >>> id(bar['a']) 4299760200 >>> id(foo['b']) 4297371984 >>> id(bar['b']) 4297373920 >>> id(foo['b']['c']) 4299721040 >>> id(bar['b']['c']) 4299761496 >>> id(foo['b']['c'][0]) 4297074656 >>> id(bar['b']['c'][0]) 4297074656 ---------- components: Extension Modules messages: 114007 nosy: nharkins priority: normal severity: normal status: open title: copy.deepcopy() copying pointers from a dict/dict/list, should copy values type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 15 23:28:29 2010 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 15 Aug 2010 21:28:29 +0000 Subject: [New-bugs-announce] [issue9617] Buffered IO shouldn't ignore incoming signals during a partial write In-Reply-To: <1281907709.19.0.902405894969.issue9617@psf.upfronthosting.co.za> Message-ID: <1281907709.19.0.902405894969.issue9617@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Prompted by Martin in #9611, here is a patch fixing the new buffered IO layer so that an incoming signal during a successful partial write() doesn't get ignored. Tests included. ---------- components: IO files: sigbufio.patch keywords: patch messages: 114012 nosy: exarkun, loewis, pitrou, rnk priority: normal severity: normal stage: patch review status: open title: Buffered IO shouldn't ignore incoming signals during a partial write type: behavior versions: Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file18540/sigbufio.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 16 00:52:10 2010 From: report at bugs.python.org (Cherniavsky Beni) Date: Sun, 15 Aug 2010 22:52:10 +0000 Subject: [New-bugs-announce] [issue9618] IDLE shell ignores all but first statement In-Reply-To: <1281912730.25.0.579832640698.issue9618@psf.upfronthosting.co.za> Message-ID: <1281912730.25.0.579832640698.issue9618@psf.upfronthosting.co.za> New submission from Cherniavsky Beni : [Spinoff of http://bugs.python.org/issue3559] If you manage to type several simple statements into the prompt (by copy-pasting them, using Ctrl+J, or creative deletion), IDLE runs the first one and silently ignores the rest: >>> x = 1 x = 2 >>> x 1 Moreover, it doesn't even parse the additional lines: >>> x = 3 $@syntax error?! >>> x 3 If the first statement is a compound statement, IDLE refuses with a SyntaxError at the begging of the second statement: >>> def f(): return 42 f() SyntaxError: invalid syntax I believe in both cases the right least-surprise behavior is to run all statements. If not, a clear error explaining that IDLE doesn't support multiple statements must be printed. But I can't see a reason to choose this over making it Just Work. [Implementation: might or might not be related to http://bugs.python.org/issue7741] ---------- components: IDLE messages: 114019 nosy: cben priority: normal severity: normal status: open title: IDLE shell ignores all but first statement versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 16 01:20:52 2010 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 15 Aug 2010 23:20:52 +0000 Subject: [New-bugs-announce] [issue9619] test_ssl freezes In-Reply-To: <1281914452.35.0.951436005695.issue9619@psf.upfronthosting.co.za> Message-ID: <1281914452.35.0.951436005695.issue9619@psf.upfronthosting.co.za> New submission from Antoine Pitrou : Recently there have been test_ssl freezes on the buildbots. They seem to happen in the asyncore test case: http://www.python.org/dev/buildbot/builders/i386%20Ubuntu%203.x/builds/1903/steps/test/logs/stdio http://www.python.org/dev/buildbot/builders/x86%20Ubuntu%203.x/builds/1742/steps/test/logs/stdio test_asyncore_server (test.test_ssl.ThreadedTests) Check the example asyncore integration. ... server: new connection from 127.0.0.1:36622 client: sending b'FOO\n'... server: read b'FOO\n' from client client: read b'foo\n' client: closing connection. server: read b'over\n' from client server: closed connection server: read b'' from client The only significant change recently in ssl has been r83869, and asyncore doesn't seem to have recent any important changes lately. ---------- components: Library (Lib), Tests messages: 114024 nosy: giampaolo.rodola, pitrou priority: normal severity: normal status: open title: test_ssl freezes versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 16 09:20:16 2010 From: report at bugs.python.org (beng umali) Date: Mon, 16 Aug 2010 07:20:16 +0000 Subject: [New-bugs-announce] [issue9620] IDLE Message-ID: <1281943216.85.0.864932852857.issue9620@psf.upfronthosting.co.za> Changes by beng umali : ---------- nosy: bpumali priority: normal severity: normal status: open title: IDLE _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 16 17:39:59 2010 From: report at bugs.python.org (Matt Bond) Date: Mon, 16 Aug 2010 15:39:59 +0000 Subject: [New-bugs-announce] [issue9621] Graphviz output for 2to3 fixer patterns In-Reply-To: <1281973199.06.0.194769344976.issue9621@psf.upfronthosting.co.za> Message-ID: <1281973199.06.0.194769344976.issue9621@psf.upfronthosting.co.za> New submission from Matt Bond : As part of my GSoC project working on 2to3, I've created a script which will allow compiled fixer patterns to be visualized using graphviz. This would be useful for debugging and understanding exactly how patterns are matched. I've written using the 2to3 sandbox as my base. The script is named pat2dot and is found in the scripts directory. The script currently relies on an external graphviz library (I provided bindings for the GvGen library with this patch), they are separated enough from the rest of the code that it would be trivial to create a class that would work using a different graphviz library. Additionally, since the code is never called within 2to3 proper, this dependency will only appear if you wish to use pat2dot, and will not affect any other usages of lib2to3. Usage of the script is `python pat2dot.py fixername` where fixername is any fixer provided in 2to3, as named by 2to3's -l option. ---------- components: 2to3 (2.x to 3.0 conversion tool) files: 2to3-graph.diff keywords: patch messages: 114049 nosy: facundobatista, gmattbond, loewis priority: normal severity: normal status: open title: Graphviz output for 2to3 fixer patterns versions: Python 2.6 Added file: http://bugs.python.org/file18544/2to3-graph.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 16 19:17:15 2010 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 16 Aug 2010 17:17:15 +0000 Subject: [New-bugs-announce] [issue9622] Allow to set profile/trace function globally In-Reply-To: <1281979035.75.0.299243674716.issue9622@psf.upfronthosting.co.za> Message-ID: <1281979035.75.0.299243674716.issue9622@psf.upfronthosting.co.za> New submission from Kristj?n Valur J?nsson : issue 9609 updates _lsprof.c to be multi-stack aware. This allows cProfile.Profile() objects to be shared by many threads and provide meaningfull results. This update makes it more convenient to profile running, multi-threaded, applications. By adding a set of global (cross thread) profiling hooks that override the per-thread hooks, it is possible to enable and disable profiling/tracing for the entire program. A multithreaded python could then do something like this: def ProfileMe(t): p = cProfile.Profile() p.enable(global=True) time.sleep(t) p.disable() p.print_stats() A patch is provided, also, an updated _lsprof adding the new 'global' flag to the "enable" function. (This paradigm is used successfully in EVE, albeit with "global" there meaning all tasklets, to do snapshot profiling of a running server. The results are displayed on a web page served by the server backend.) ---------- components: Interpreter Core files: globaltrace.patch keywords: patch, patch messages: 114054 nosy: krisvale priority: normal severity: normal status: open title: Allow to set profile/trace function globally type: feature request versions: Python 3.2 Added file: http://bugs.python.org/file18545/globaltrace.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 16 21:44:27 2010 From: report at bugs.python.org (Dave Malcolm) Date: Mon, 16 Aug 2010 19:44:27 +0000 Subject: [New-bugs-announce] [issue9623] test_site.py has a couple of stray self.assertTrue calls that test for equality In-Reply-To: <1281987867.95.0.832612777786.issue9623@psf.upfronthosting.co.za> Message-ID: <1281987867.95.0.832612777786.issue9623@psf.upfronthosting.co.za> New submission from Dave Malcolm : test_site.py has a couple of assertions of the form self.assertTrue(len(foo), some number) which appear to be incorrect, and should read: self.assertEqual(len(foo), some number) or assertEquals (that file uses both methods). r76047 fixed some of these, but a couple remain (introduced in r74526) in both 2.7 branch and py3k. Patch attached (for 2.7 branch) ---------- components: Tests keywords: easy, needs review, patch messages: 114069 nosy: dmalcolm priority: normal severity: normal stage: patch review status: open title: test_site.py has a couple of stray self.assertTrue calls that test for equality type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 17 01:36:35 2010 From: report at bugs.python.org (Jay Ballard) Date: Mon, 16 Aug 2010 23:36:35 +0000 Subject: [New-bugs-announce] [issue9624] 2755 In-Reply-To: <1282001795.13.0.196803574469.issue9624@psf.upfronthosting.co.za> Message-ID: <1282001795.13.0.196803574469.issue9624@psf.upfronthosting.co.za> New submission from Jay Ballard : failure to find drive ---------- components: None messages: 114085 nosy: Kartton priority: normal severity: normal status: open title: 2755 versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 17 11:19:04 2010 From: report at bugs.python.org (Martin Pengelly-Phillips) Date: Tue, 17 Aug 2010 09:19:04 +0000 Subject: [New-bugs-announce] [issue9625] argparse: Problem with defaults for variable nargs In-Reply-To: <1282036744.37.0.964764969496.issue9625@psf.upfronthosting.co.za> Message-ID: <1282036744.37.0.964764969496.issue9625@psf.upfronthosting.co.za> New submission from Martin Pengelly-Phillips : Variable argument count plays badly with choices. Example: ======== >>> import argparse >>> parser = argparse.ArgumentParser() >>> parser.add_argument('choices', nargs='*', default='a', choices=['a', 'b', 'c']) >>> args = parser.parse_args() >>> print type(args.choices) >>> args = parser.parse_args(['a']) >>> print type(args.choices) If the user specifies the value on the command line then a list is used, but if the value comes from the default a string is used. Unfortunately, changing default to a list value gives an error: error: argument choices: invalid choice: ['a'] (choose from 'a', 'b', 'c') Additionally, this means it is also not possible to use default=['a', 'c']. The current workaround is to create a custom type: def my_type(string): if string not in ['a', 'b', 'c']: raise TypeError return string ---------- components: Library (Lib) messages: 114108 nosy: thesociable priority: normal severity: normal status: open title: argparse: Problem with defaults for variable nargs type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 17 15:14:35 2010 From: report at bugs.python.org (Alexey Luchko) Date: Tue, 17 Aug 2010 13:14:35 +0000 Subject: [New-bugs-announce] [issue9626] OderedDict.viewitems() does not preserve item order In-Reply-To: <1282050875.1.0.267221585344.issue9626@psf.upfronthosting.co.za> Message-ID: <1282050875.1.0.267221585344.issue9626@psf.upfronthosting.co.za> New submission from Alexey Luchko : OrderedDict.viewitems() is expected to preserve item order like items() do >>> from collections import OrderedDict >>> d = OrderedDict([(1, 2), ("a", "b")]) >>> d.items() [(1, 2), ('a', 'b')] But it does not: >>> list(d.viewitems()) [('a', 'b'), (1, 2)] ---------- components: Library (Lib) messages: 114117 nosy: luch priority: normal severity: normal status: open title: OderedDict.viewitems() does not preserve item order type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 17 15:24:58 2010 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 17 Aug 2010 13:24:58 +0000 Subject: [New-bugs-announce] [issue9627] Regrtest failed to clean up temporary directory In-Reply-To: <1282051498.42.0.53321689124.issue9627@psf.upfronthosting.co.za> Message-ID: <1282051498.42.0.53321689124.issue9627@psf.upfronthosting.co.za> New submission from Nick Coghlan : Watching the Windows buildbot to check if test_dis was working yet, I found this output: http://www.python.org/dev/buildbot/stable/builders/x86%20XP-4%203.x/builds/2774/steps/test/logs/stdio It appears something still had files open in the directory when regrtest was attempting to clean it out. ---------- messages: 114120 nosy: ncoghlan priority: normal severity: normal status: open title: Regrtest failed to clean up temporary directory type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 17 18:29:37 2010 From: report at bugs.python.org (Dave Malcolm) Date: Tue, 17 Aug 2010 16:29:37 +0000 Subject: [New-bugs-announce] [issue9628] runtests.sh -x doesn't work with more than two args (sed error) In-Reply-To: <1282062577.36.0.157889963246.issue9628@psf.upfronthosting.co.za> Message-ID: <1282062577.36.0.157889963246.issue9628@psf.upfronthosting.co.za> New submission from Dave Malcolm : runtests.sh -x fails to work with more than two tests; for example, running: $ ./runtests.sh -x test_httplib test_http_cookies test_dl erroneously runs test_dl By default, "sed -e s" only substitutes the first match - the invocations within runtests.sh need to add the trailing "g" flag to substitute all matches. >From "info sed": The `s' command can be followed by zero or more of the following FLAGS: `g' Apply the replacement to _all_ matches to the REGEXP, not just the first. Am attaching a patch. (Seen with sed-4.2.1 on Fedora 13) ---------- components: Tests files: fix-sed-invocations-in-runtests.sh.patch keywords: easy, needs review, patch, patch messages: 114134 nosy: dmalcolm priority: normal severity: normal stage: patch review status: open title: runtests.sh -x doesn't work with more than two args (sed error) versions: Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file18554/fix-sed-invocations-in-runtests.sh.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 17 20:50:13 2010 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 17 Aug 2010 18:50:13 +0000 Subject: [New-bugs-announce] [issue9629] SIZEOF_SOCKET_T used in longobject.h but undefined In-Reply-To: <1282071013.13.0.416867033883.issue9629@psf.upfronthosting.co.za> Message-ID: <1282071013.13.0.416867033883.issue9629@psf.upfronthosting.co.za> New submission from Antoine Pitrou : longobject.h uses SIZEOF_SOCKET_T: #if SIZEOF_SOCKET_T <= SIZEOF_LONG #define PyLong_FromSocket_t(fd) PyLong_FromLong((SOCKET_T)(fd)) #define PyLong_AsSocket_t(fd) (SOCKET_T)PyLong_AsLong(fd) #else #define PyLong_FromSocket_t(fd) PyLong_FromLongLong(((SOCKET_T)(fd)); #define PyLong_AsSocket_t(fd) (SOCKET_T)PyLong_AsLongLong(fd) #endif but SIZEOF_SOCKET_T doesn't exist at that point since it is defined in Modules/socketmodule.h which isn't part of Include/Python.h. As a result, PyLong_FromSocket_t is always aliased to PyLong_FromLong, which is wrong under 64-bit Windows (a SOCKET is 64-bit there, while a long is 32-bit). ---------- components: Extension Modules messages: 114144 nosy: brian.curtin, christian.heimes, pitrou, tim.golden priority: normal severity: normal stage: needs patch status: open title: SIZEOF_SOCKET_T used in longobject.h but undefined type: behavior versions: Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 18 01:47:06 2010 From: report at bugs.python.org (STINNER Victor) Date: Tue, 17 Aug 2010 23:47:06 +0000 Subject: [New-bugs-announce] [issue9630] Reencode filenames of all module and code objects when setting the filesystem encoding In-Reply-To: <1282088826.81.0.444273804054.issue9630@psf.upfronthosting.co.za> Message-ID: <1282088826.81.0.444273804054.issue9630@psf.upfronthosting.co.za> New submission from STINNER Victor : Python 3 has a very important variable: the filesystem encoding, sys.getfilesystemencoding(). It is used to encode and decode filenames to access to the filesystem, to encode program arguments in subprocess, etc. The encoding is hardcoded to "mbcs" on Windows and "utf-8" on Mac OS X. On other OSes, Python gets the encoding from the locale. The problem is that the code getting the locale encoding loads Python modules (eg. locale) and Python uses a default encoding before the locale encoding is known. As a result, modules and code objects created before Python sets the locale encoding are encoded with the old encoding. The default encoding is "utf-8". If the locale encoding is also "utf-8", there is no problem because the filename are correctly encoded. If the locale encoding is different, we keep filenames encoded in the wrong encoding. It becomes worse when the locale encoding is unable to encode the filenames, eg. ASCII encoding. -- A solution would be to avoid loading any Python module, but I don't think that it is possible. The locale encoding can be something different than ascii, latin-1, utf-8 or mbcs. The locale encoding can be an alias like 'utf8' (instead of 'utf-8'), 'iso-8859-1' (Python uses 'latin_1') or 'ANSI_x3.4_1968' (for 'ascii') and encoding aliases are implemented as Lib/encodings/aliases.py which is... a Python module. -- I wrote a patch to reencode filenames of all module and code objects in initfsencoding() when the locale encoding is known. I tested my patch on my import_unicode branch (branch to fix #8611, see also #9425: issue to merge the branch to py3k). I would like one or more reviews of the patch because it is long and complex. Please check for refleaks :-) -- About the patch. I don't know how to list *all* code objects and so I created a list to store weak references to all code objects, list filled by the code object constructor. The list is destroyed at initfsencoding() exit (early in Python initialization). There is a FIXME: I don't know if sys.path_importer_cache keys should also be reencoded. I tried to apply all remarks made on the first patch (posted on Rietveld for #9425). The patch now stores weak references instead of strong references to code objects in the code object list. (r84168 creates PyModule_GetFilenameObject, function needed by this patch) ---------- components: Interpreter Core, Unicode files: reencode_modules_path.patch keywords: patch messages: 114191 nosy: haypo priority: normal severity: normal status: open title: Reencode filenames of all module and code objects when setting the filesystem encoding versions: Python 3.2 Added file: http://bugs.python.org/file18560/reencode_modules_path.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 18 07:22:33 2010 From: report at bugs.python.org (Prakash Palanivel) Date: Wed, 18 Aug 2010 05:22:33 +0000 Subject: [New-bugs-announce] [issue9631] Python 2.7 installation issue for Linux Red Hat 4.1 In-Reply-To: <1282108953.92.0.943632360126.issue9631@psf.upfronthosting.co.za> Message-ID: <1282108953.92.0.943632360126.issue9631@psf.upfronthosting.co.za> New submission from Prakash Palanivel : Server on Linux:gcc version 4.1.0 20060304 (Red Hat 4.1.0-3) Which "sunaudiodev" library i need to install on linux. Kindly help me how to install or configure or avoid this issue. Error: Python build finished, but the necessary bits to build these modules were not found: _tkinter bsddb185 sunaudiodev To find the necessary bits, look in setup.py in detect_modules() for the module's name. ---------- components: Installation messages: 114196 nosy: spprakash priority: normal severity: normal status: open title: Python 2.7 installation issue for Linux Red Hat 4.1 versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 18 13:56:04 2010 From: report at bugs.python.org (STINNER Victor) Date: Wed, 18 Aug 2010 11:56:04 +0000 Subject: [New-bugs-announce] [issue9632] Remove sys.setfilesystemencoding() In-Reply-To: <1282132564.59.0.094866961442.issue9632@psf.upfronthosting.co.za> Message-ID: <1282132564.59.0.094866961442.issue9632@psf.upfronthosting.co.za> New submission from STINNER Victor : sys.setfilesystemencoding() function is dangerous because it introduces a lot of inconsistencies: this function is unable to reencode all filenames in all objects (eg. Python is unable to find filenames in user objects or 3rd party libraries). Eg. if you change the filesystem from utf8 to ascii, it will not be possible to use existing non-ascii (unicode) filenames: they will raise UnicodeEncodeError. As sys.setdefaultencoding() in Python2, I think that sys.setfilesystemencoding() is the root of evil :-) PYTHONFSENCODING (issue #8622) is the right solution to set the filesysteme encoding. Attached patch removes sys.setfilesystemencoding(). ---------- components: Library (Lib), Unicode messages: 114211 nosy: haypo priority: normal severity: normal status: open title: Remove sys.setfilesystemencoding() versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 18 14:17:17 2010 From: report at bugs.python.org (=?utf-8?q?Markus_Pr=C3=B6ller?=) Date: Wed, 18 Aug 2010 12:17:17 +0000 Subject: [New-bugs-announce] [issue9633] pdb go stack up/down In-Reply-To: <1282133837.82.0.171010459939.issue9633@psf.upfronthosting.co.za> Message-ID: <1282133837.82.0.171010459939.issue9633@psf.upfronthosting.co.za> New submission from Markus Pr?ller : Hello, with python 2.7 I encounter the following problem: I have created the following sample script: import pdb def function_1(number): stack_1 = number function_2(stack_1) def function_2(number): stack_2 = number + 1 function_3(stack_2) def function_3(number): stack_3 = number + 1 pdb.set_trace() print stack_3 function_1(1) This is what I have done in the pdb session: > c:\tst_pdb.py(14)function_3() -> print stack_3 (Pdb) l 9 function_3(stack_2) 10 11 def function_3(number): 12 stack_3 = number + 1 13 pdb.set_trace() 14 -> print stack_3 15 16 function_1(1) [EOF] (Pdb) stack_3 3 (Pdb) !stack_3 = 177 (Pdb) !print stack_3 177 (Pdb) u > c:\tst_pdb.py(9)function_2() -> function_3(stack_2) (Pdb) l 4 stack_1 = number 5 function_2(stack_1) 6 7 def function_2(number): 8 stack_2 = number + 1 9 -> function_3(stack_2) 10 11 def function_3(number): 12 stack_3 = number + 1 13 pdb.set_trace() 14 print stack_3 (Pdb) !print stack_2 2 (Pdb) !stack_2 = 144 (Pdb) !print stack_2 144 (Pdb) d > c:\tst_pdb.py(14)function_3() -> print stack_3 (Pdb) l 9 function_3(stack_2) 10 11 def function_3(number): 12 stack_3 = number + 1 13 pdb.set_trace() 14 -> print stack_3 15 16 function_1(1) [EOF] (Pdb) stack_3 3 (Pdb) u > c:\tst_pdb.py(9)function_2() -> function_3(stack_2) (Pdb) !print stack_2 2 (Pdb) I walked through the stack and changed the values of the variables stack_x but the values weren't saved when I moved one frame up/down ---------- components: Library (Lib) messages: 114213 nosy: Markus.Pr?ller priority: normal severity: normal status: open title: pdb go stack up/down type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 18 19:46:21 2010 From: report at bugs.python.org (Kelly Lucas) Date: Wed, 18 Aug 2010 17:46:21 +0000 Subject: [New-bugs-announce] [issue9634] Add timeout parameter to Queue.join() In-Reply-To: <1282153581.83.0.092560551276.issue9634@psf.upfronthosting.co.za> Message-ID: <1282153581.83.0.092560551276.issue9634@psf.upfronthosting.co.za> New submission from Kelly Lucas : I've seen quite a few people requesting to add a timeout value to the Queue.join() method, as it seems like a nice feature to have when waiting for queue's to finish. Please add a feature so that Queue.join() will issue a self.all_tasks_done.release() when the timeout value is reached. ---------- components: Library (Lib) messages: 114257 nosy: kdlucas priority: normal severity: normal status: open title: Add timeout parameter to Queue.join() versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 19 01:43:25 2010 From: report at bugs.python.org (Dave Malcolm) Date: Wed, 18 Aug 2010 23:43:25 +0000 Subject: [New-bugs-announce] [issue9635] RFE(patch): add Py_BREAKPOINT and sys.breakpoint hooks In-Reply-To: <1282175005.37.0.905894818052.issue9635@psf.upfronthosting.co.za> Message-ID: <1282175005.37.0.905894818052.issue9635@psf.upfronthosting.co.za> New submission from Dave Malcolm : It's sometimes useful to be able to programatically inject a breakpoint when debugging CPython. For example, sometimes you want a conditional breakpoint, but the logic involved is too complex to be expressed in the debugger (e.g. runtime complexity of evaluating the conditional in the debugger process, or deficiency of the debugger itself). I'm attaching a patch which: - adds a Py_BREAKPOINT macro to pyport.h This is available as a quick and dirty way of hardcoding a breakpoint in code (e.g. in extension modules); so that when you need to you can put of these in (perhaps guarded by C-level conditionals): if (complex_conditional()) { Py_BREAKPOINT(); } - when Py_BREAKPOINT is defined, adds a sys.breakpoint() method. This means that you can add C-level breakpoints to Python scripts, perhaps guarded by python-level conditionals: if foo and bar and not baz: sys.breakpoint() Naturally this is highly system-dependent. Only tested on Linux (Fedora 13 x86_64 with gcc-4.4.4). The Windows implementation was copied from http://bugs.python.org/issue8863 but I don't have a Windows box to test it on. I note that the GLib library within GNOME has a similar idea with a G_BREAKPOINT macro, which has accumulated a collection of platform-specific logic: http://git.gnome.org/browse/glib/tree/glib/gbacktrace.h (unfortunately that's LGPLv2+ licensed) Doesn't yet have a unit test. Note that when running on Linux when _not_ under a debugger, the default for SIGTRAP is to get a coredump: Trace/breakpoint trap (core dumped) so people should be strongly discouraged from adding these calls to their code. ---------- components: Interpreter Core, Library (Lib) files: add-sys.breakpoint.patch keywords: patch, patch messages: 114301 nosy: dmalcolm, haypo priority: normal severity: normal stage: patch review status: open title: RFE(patch): add Py_BREAKPOINT and sys.breakpoint hooks type: feature request versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file18572/add-sys.breakpoint.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 19 02:47:27 2010 From: report at bugs.python.org (STINNER Victor) Date: Thu, 19 Aug 2010 00:47:27 +0000 Subject: [New-bugs-announce] [issue9636] {'key': 'value'}[b'key'] raises a BytesWarning In-Reply-To: <1282178847.04.0.326162016951.issue9636@psf.upfronthosting.co.za> Message-ID: <1282178847.04.0.326162016951.issue9636@psf.upfronthosting.co.za> New submission from STINNER Victor : With python3 -bb: {'key': 'value'}[b'key'] raises a BytesWarning, but {'key': 'value'}[b'missing_key'] doesn't. The warning is unexpected here because it's an implicit comparaison (I mean, different than an explicit: 'key' == b'key'), we cannot check that the dict keys are all bytes / unicode (at least, I don't want to). And so I think that it should be fixed. First lookdict_unicode() is used because all dict keys are unicode, but lookdict_unicode() falls back to lookdict() because the asked key type is not unicode. lookdict() checks the hash: they matches, hash('key') == hash(b'key'). Then it compares the two key objects with PyObject_RichCompareBool(startkey, key, Py_EQ). PyUnicode_RichCompare() returns NotImplemented, and so bytes_richcompare() is called. Finally, bytes_richcompare() raises the BytesWarning. ---------- components: Interpreter Core, Unicode messages: 114314 nosy: haypo priority: normal severity: normal status: open title: {'key': 'value'}[b'key'] raises a BytesWarning versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 19 07:44:29 2010 From: report at bugs.python.org (Kirikaza) Date: Thu, 19 Aug 2010 05:44:29 +0000 Subject: [New-bugs-announce] [issue9637] docs do not say that urllib uses HTTP_PROXY In-Reply-To: <1282196669.74.0.629180904202.issue9637@psf.upfronthosting.co.za> Message-ID: <1282196669.74.0.629180904202.issue9637@psf.upfronthosting.co.za> New submission from Kirikaza : In practice urllib reads HTTP_PROXY firstly and then if HTTP_PROXY is empty urllib reads http_proxy. Documentation (http://docs.python.org/library/urllib.html) says nothing about HTTP_PROXY. Maybe it affects all the versions of Python. ---------- assignee: docs at python components: Documentation messages: 114319 nosy: docs at python, kirikaza priority: normal severity: normal status: open title: docs do not say that urllib uses HTTP_PROXY versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 19 08:57:39 2010 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 19 Aug 2010 06:57:39 +0000 Subject: [New-bugs-announce] [issue9638] remove dead code from py3k imaplib In-Reply-To: <1282201059.85.0.738229053301.issue9638@psf.upfronthosting.co.za> Message-ID: <1282201059.85.0.738229053301.issue9638@psf.upfronthosting.co.za> New submission from Mark Lawrence : The title says it all. ---------- files: imaplibpy3k.diff keywords: patch messages: 114331 nosy: BreamoreBoy priority: normal severity: normal stage: patch review status: open title: remove dead code from py3k imaplib versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file18573/imaplibpy3k.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 19 11:11:50 2010 From: report at bugs.python.org (Marcus Huewe) Date: Thu, 19 Aug 2010 09:11:50 +0000 Subject: [New-bugs-announce] [issue9639] urllib2's AbstractBasicAuthHandler is limited to 6 requests In-Reply-To: <1282209110.27.0.244600135673.issue9639@psf.upfronthosting.co.za> Message-ID: <1282209110.27.0.244600135673.issue9639@psf.upfronthosting.co.za> New submission from Marcus Huewe : It seems that commit r81636 broke urllib2's AbstractBasicAuthHandler because the "retried" attribute isn't reset on success. Therefore it's limited to 6 requests. The attached patch should fix this problem. ---------- components: Library (Lib) files: urllib2-AbstractBasicAuthHandler_reset_attr.diff keywords: patch messages: 114336 nosy: mhuewe priority: normal severity: normal status: open title: urllib2's AbstractBasicAuthHandler is limited to 6 requests type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file18574/urllib2-AbstractBasicAuthHandler_reset_attr.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 19 13:04:11 2010 From: report at bugs.python.org (W. Trevor King) Date: Thu, 19 Aug 2010 11:04:11 +0000 Subject: [New-bugs-announce] [issue9640] Improved doctest REPORT_*DIFFs with ELLIPSIS and/or NORMALIZE_WHITESPACE In-Reply-To: <1282215851.54.0.826836496752.issue9640@psf.upfronthosting.co.za> Message-ID: <1282215851.54.0.826836496752.issue9640@psf.upfronthosting.co.za> New submission from W. Trevor King : I had been struggling to find the failure-causing mismatch in a doctest with lots of output. REPORT_UDIFF gave lots of false mismatches because I was also using NORMALIZE_WHITESPACE. Looking through the doctest.py source, I saw a comment suggesting a nicer diff in the similar REPORT_*DIFF and ELLIPSIS situation. So I went ahead and implemented one. I'm not super happy with the cleanliness of the implementation, but it ended up being a bit trickier than I'd initially expected. ---------- components: Library (Lib) messages: 114340 nosy: labrat priority: normal severity: normal status: open title: Improved doctest REPORT_*DIFFs with ELLIPSIS and/or NORMALIZE_WHITESPACE type: feature request versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 19 13:29:29 2010 From: report at bugs.python.org (Anders Sandvig) Date: Thu, 19 Aug 2010 11:29:29 +0000 Subject: [New-bugs-announce] [issue9641] httplib/ftplib: timeout parameter not applied correctly In-Reply-To: <1282217369.56.0.577376889076.issue9641@psf.upfronthosting.co.za> Message-ID: <1282217369.56.0.577376889076.issue9641@psf.upfronthosting.co.za> New submission from Anders Sandvig : >From : Consider the following code for retreieving a web page using httplib: def get_url(hostname, port, url, timeout=5): con = httplib.HTTPConnection(hostname, port, timeout) con.request("GET", url) res = con.getresponse() data = res.read() return res, data As expected, this will raise a socket.error if the client is unable to connect before the timeout has expired. However, once the connection has been made, the timeout parameter no longer has any effect and con.getresponse() will block forever if the server does not send any data. I think the reason for this is that the socket object created in HTTPConnection.connect() has a default timeout of 0 (i.e. it is never set explicitly): def connect(self): """Connect to the host and port specified in __init__.""" self.sock = socket.create_connection((self.host,self.port), self.timeout) For now I have been able to work around this by manually setting the timeout of the (private) socket object after calling con.request(), like this: ... con.request("GET", url) con.sock.settimeout(timeout) res = con.getresponse() ... However, I don't think this is a very good solution as it relies on knowledge about the inner workings of httplib (and I had to read the library source code to come up with it). >From the top of my head, I can come up with three (four) ways of properly solving the issue: 1) Documenting the timeout behavior and describing the above hack in the httplib documentation. 2) Modify HTTPConnection.connect() to set the timeout on the socket object after it has been created (using the same timeout as given on the HTTPConnection constructor). 3) Adding (optional) timeout parameters to HTTPConnection.getresponse() and HTTPResponse.read() (and possibly other functions with the same problem). 4) A combination of 2) and 3). [...] ---------- components: Library (Lib) messages: 114343 nosy: anders.sandvig priority: normal severity: normal status: open title: httplib/ftplib: timeout parameter not applied correctly type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 19 14:02:28 2010 From: report at bugs.python.org (STINNER Victor) Date: Thu, 19 Aug 2010 12:02:28 +0000 Subject: [New-bugs-announce] [issue9642] #ifdef and mbcs: don't check for defined(HAVE_USABLE_WCHAR_T) In-Reply-To: <1282219348.43.0.267719038373.issue9642@psf.upfronthosting.co.za> Message-ID: <1282219348.43.0.267719038373.issue9642@psf.upfronthosting.co.za> New submission from STINNER Victor : mbcs codec functions are surrounded by: #if defined(MS_WINDOWS) && defined(HAVE_USABLE_WCHAR_T) (especially in unicodeobject.c and _codecsmodule.c) or #ifdef MS_WIN32 (in unicodeobject.h) or #if defined(MS_WINDOWS) && !defined(__BORLANDC__) (in timemodule.c) I think that all of these tests are wrong. We should just check that we are compiling under Windows: mbcs functions don't use the wchar_t type. And it's better to use the same test in all tests (MS_WIN32 vs MS_WINDOWS). Attached patch replaces all #ifdef (except the one in timemodule.c because I don't know what to do with the BORLAND check, does anyone use this compiler?). I suppose that my patch doesn't change anything in pratice because mbcs is used in many places and noboby complained that mbcs encoding was missing on Windows. ---------- components: Unicode, Windows files: ifdef_mbcs.patch keywords: patch messages: 114350 nosy: brian.curtin, haypo, tim.golden priority: normal severity: normal status: open title: #ifdef and mbcs: don't check for defined(HAVE_USABLE_WCHAR_T) versions: Python 3.2 Added file: http://bugs.python.org/file18577/ifdef_mbcs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 19 19:59:11 2010 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 19 Aug 2010 17:59:11 +0000 Subject: [New-bugs-announce] [issue9643] urllib2 - Basic, Digest Auth Handlers Retry will give 401 code instead of 407 In-Reply-To: <1282240751.95.0.79564995249.issue9643@psf.upfronthosting.co.za> Message-ID: <1282240751.95.0.79564995249.issue9643@psf.upfronthosting.co.za> New submission from Senthil Kumaran : The retry logic and code used by ProxyBasicAuthHandler and ProxyDigestAuthHandler are same as normal authentication handlers. While this reuse is good, there is a problem that, on authentication failure, the HTTPError code is hardcoded to 401, whereas for Proxy cases it should have been 407. The problematic line is this: def http_error_auth_reqed(self, auth_header, host, req, headers): ... raise HTTPError(req.full_url, 401, "digest auth failed", headers, None) can be changed by: - Passing the errcode as arg. - Or getting it from headers. ---------- assignee: orsenthil messages: 114386 nosy: orsenthil priority: normal severity: normal status: open title: urllib2 - Basic,Digest Auth Handlers Retry will give 401 code instead of 407 versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 19 20:40:37 2010 From: report at bugs.python.org (David Watson) Date: Thu, 19 Aug 2010 18:40:37 +0000 Subject: [New-bugs-announce] [issue9644] PEP 383: os.statvfs() does not accept surrogateescape arguments In-Reply-To: <1282243237.49.0.435221885834.issue9644@psf.upfronthosting.co.za> Message-ID: <1282243237.49.0.435221885834.issue9644@psf.upfronthosting.co.za> New submission from David Watson : The statvfs() function still converts its argument with the "s" format; the attached patch (for 3.2) fixes it to use PyUnicode_FSConverter(). ---------- components: Extension Modules files: statvfs-pep383-3.2.diff keywords: patch messages: 114392 nosy: baikie priority: normal severity: normal status: open title: PEP 383: os.statvfs() does not accept surrogateescape arguments type: behavior versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file18578/statvfs-pep383-3.2.diff _______________________________________ Python tracker