[issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__

Georg Brandl added the comment: IMO zseil's latest patch is the best one, but I need any other developer to review and approve it. _ Tracker <[EMAIL PROTECTED]> _ ___

[issue1181] Redefine clear() for os.environ to use unsetenv() if possible

Changes by Raghuram Devarakonda: -- nosy: +draghuram __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue1541463] Optimizations for cgi.FieldStorage methods

Georg Brandl added the comment: Okay, you've convinced me. Committed rev. 58218. -- resolution: -> accepted status: open -> closed _ Tracker <[EMAIL PROTECTED]> _ _

[issue1182] Paticular decimal mod operation wrongly output NaN.

New submission from Hirokazu Yamamoto : Following code illegally print "NaN" on Python2.5. from decimal import * d1 = Decimal("23.08589694291355371979265447") d2 = Decimal("2.302585092994045640179914546844") print d1 % d2

[issue1613130] str.split creates new string even if pattern not found

Changes by Georg Brandl: -- type: -> rfe versions: +Python 2.6, Python 3.0 _ Tracker <[EMAIL PROTECTED]> _ ___ Python-bugs-list mail

[issue1176] str.split() takes no keyword arguments (Should this be expected?)

Sergio Correia added the comment: Thanks for the update, Sergio __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http:/

[issue1176] str.split() takes no keyword arguments (Should this be expected?)

Georg Brandl added the comment: Added to the documentation that string methods don't take keyword args in rev. 58219. Closing this as "works for me". -- nosy: +georg.brandl resolution: -> works for me status: open -> closed __ Tracker <[EMAIL PROTECTED]>

[issue1182] Paticular decimal mod operation wrongly output NaN.

Changes by Georg Brandl: -- assignee: -> facundobatista nosy: +facundobatista __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing li

[issue1686386] Python SEGFAULT on tuple.__repr__ and str()

Georg Brandl added the comment: I don't have a specific opinion on this; the usage of Py_EnterRecursiveCall/Py_ReprEnter certainly looks correct. -- assignee: georg.brandl -> brett.cannon _ Tracker <[EMAIL PROTECTED]>

[issue1696444] Adding an index method to tuples

Changes by Georg Brandl: -- components: +Interpreter Core -None type: -> rfe versions: +Python 2.6, Python 3.0 _ Tracker <[EMAIL PROTECTED]> _ _

[issue1181] Redefine clear() for os.environ to use unsetenv() if possible

Guido van Rossum added the comment: Sounds like a good idea. Anyone care to check it in? -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> __

[issue1179] [CVE-2007-4965] Integer overflow in imageop module

Changes by Sean Reifschneider: -- priority: -> high __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue1719423] Python package support not properly documented

Changes by Sean Reifschneider: -- priority: high -> normal resolution: -> remind status: open -> pending _ Tracker <[EMAIL PROTECTED]> _ ___

[issue1643369] pdb find_function does not find Class methods.

Changes by Sean Reifschneider: -- priority: high -> low title: function breakpoints in pdb -> pdb find_function does not find Class methods. type: -> rfe _ Tracker <[EMAIL PROTECTED]> ___

[issue1643369] pdb find_function does not find Class methods.

Changes by Sean Reifschneider: -- severity: normal -> minor _ Tracker <[EMAIL PROTECTED]> _ ___ Python-bugs-list mailing list Unsubs

[issue1181] Redefine clear() for os.environ to use unsetenv() if possible

Raghuram Devarakonda added the comment: Shouldn't the first clear() in the patch say "del self.data[key.upper()]" instead of "del self.data[key]"? I also think the patch should include doc change. __ Tracker <[EMAIL PROTECTED]> _

[issue1170766] weakref.proxy incorrect behaviour

Sean Reifschneider added the comment: Raymond: Is this still a problem, or should we close it because the reported issue is resolved and 2.4 is no longer maintained? -- assignee: -> rhettinger nosy: +jafo priority: high -> low resolution: -> accepted type: -> behavior ___

[issue1181] Redefine clear() for os.environ to use unsetenv() if possible

Guido van Rossum added the comment: On 9/20/07, Raghuram Devarakonda <[EMAIL PROTECTED]> wrote: > Shouldn't the first clear() in the patch say "del > self.data[key.upper()]" instead of "del self.data[key]"? I also think > the patch should include doc change. I don't think so -- it goes over self

[issue1181] Redefine clear() for os.environ to use unsetenv() if possible

Georg Brandl added the comment: Committed, incl. docs, as rev. 58221. -- assignee: -> georg.brandl nosy: +georg.brandl resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]> _

[issue1183] race in SocketServer.ForkingMixIn.collect_children

New submission from David Ripton: CentOS Linux 5, Python 2.4.3 (but code appears unchanged in 2.5 and trunk, so I don't believe this bug has already been fixed) We have an xmlrpc server that subclasses DocXMLRPCServer.DocXMLRPCServer and SocketServer.ForkingMixIn. Under load, it sometimes cras

[issue1185] py3k: Completely remove nb_coerce slot

New submission from Amaury Forgeot d'Arc: Arguments coercion has been removed in py3k for a while, but there are still some traces of it. This patch removes the nb_coerce slot and the last usages of __coerce__. Documentation is also updated: Py_TPFLAGS_CHECKTYPES does not exists anymore. Note: I

[issue1183] race in SocketServer.ForkingMixIn.collect_children

Changes by Sean Reifschneider: -- keywords: +patch priority: -> normal __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Uns

[issue1184] test fixes for immutable bytes change

Changes by Sean Reifschneider: -- keywords: +patch, py3k priority: -> normal __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing lis

[issue1185] py3k: Completely remove nb_coerce slot

Changes by Sean Reifschneider: -- keywords: +patch, py3k priority: -> normal __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing lis

[issue1578269] Add os.link() and os.symlink() support for Windows

Stephen Warren added the comment: I'd say that junction points were a great way to expose this feature under Win32 - after all, isn't it specifically what they were designed for? Incidentally, at least one other application uses them for exactly this purpose; a commercial source control tool nam

[issue1704287] must run "make" before "make install"

Stephen Warren added the comment: I can confirm this happens for me too, also on CentOS 5, with SVN 2.5 HEAD as of now. It seems that this problem occurs, whilst running the first compileall command for the libinstall target: Compiling /somewhere/lib/python2.5/test/test_multibytecodec.py ... So

[issue1704287] UnicodeError in compileall if "make install" is run before "make".

Changes by Sean Reifschneider: -- title: must run "make" before "make install" -> UnicodeError in compileall if "make install" is run before "make". _ Tracker <[EMAIL PROTECTED]> _

[issue1704287] UnicodeError in compileall if "make install" is run before "make".

Stephen Warren added the comment: The attached patch should solve the problem by adding appropriate dependencies to the libinstall target. I have tested: ./configure; make install but not yet: ./configure; make all install ./configure; make all; make install Note: I introduced a new "build_a

[issue1704287] UnicodeError in compileall if "make install" is run before "make".

Changes by Sean Reifschneider: -- keywords: +patch _ Tracker <[EMAIL PROTECTED]> _ ___ Python-bugs-list mailing list Unsubscribe: h

[issue1704287] UnicodeError in compileall if "make install" is run before "make".

Sean Reifschneider added the comment: I can verify that this happens in trunk (2.6) on CentOS 5, 32-bit. Patch review looks good, and solves the problem. I've committed it to trunk as revision 58225. -- nosy: +jafo resolution: -> accepted status: open -> closed type: -> behavior vers

[issue1704287] UnicodeError in compileall if "make install" is run before "make".

Stephen Warren added the comment: Now, I have also tested: ./configure; make all install ./configure; make all; make install The "install" piece of each of the above doesn't seem to accidentally duplicate any of the building work, so the patch seems to check out OK - no negative side-effects.