[issue7393] Executing Python program of sum of 2 nos.

Raymond Hettinger added the comment: In Python 3.1, the input() function always returns a string. In your case, the string is "21". Adding two strings together gives you a longer string: "12" + "34" --> "1234". To get your program to do what you want, convert the string to a number using int

[issue7393] Executing Python program of sum of 2 nos.

New submission from Mayuresh : I am getting error of sum of two nos. the output should give addition of two numbers,but instead it is displaying 2 nos. side-by-side.I have pasted the program and output for the same. print "Please give a number: " a = input() print "And another: " b = input() p

[issue6033] LOOKUP_METHOD and CALL_METHOD optimization

Benjamin Peterson added the comment: Yes, my patch introduces that regression you mention. PyPy solves this by having the instances dictionary keep track of shadowing of the type dictionary. Not easy for CPython... I wish you luck on your patch! -- _

[issue1606092] csv module broken for unicode

Craig McQueen added the comment: I think I see now--it accepts Unicode input, but converts it back to bytes internally using the ASCII codec. So it works as long as the Unicode input contains on ASCII characters. That's a gotcha. It appears that it's been fixed in Python 3.x, judging by the doc

[issue1606092] csv module broken for unicode

Craig McQueen added the comment: Is this still an open bug? I have the following code: lookup = {} csv_reader = csv.reader(codecs.open(lookup_file_name, 'r', 'utf-8')) for row in csv_reader: lookup[row[1]] = row[0] And it "appears to work" (it runs) using Python 2.6.2. So h

[issue1606092] csv module broken for unicode

Changes by Craig McQueen : -- nosy: +cmcqueen1975 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue6033] LOOKUP_METHOD and CALL_METHOD optimization

Reid Kleckner added the comment: One thing I was wondering about the current patch is what about objects that have attributes that shadow methods? For example: class C(object): def foo(self): return 1 c = c() print c.foo() c.foo = lambda: 2 print c.foo() Shouldn't the above print

[issue6615] multiprocessing logging support test

Changes by flox : Removed file: http://bugs.python.org/file15397/issue6615_weakref.diff ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue6615] multiprocessing logging support test

flox added the comment: Small change to acquire the module lock before working on _handlerList. -- Added file: http://bugs.python.org/file15398/issue6615_weakref.diff ___ Python tracker

[issue6615] multiprocessing logging support test

Changes by flox : Removed file: http://bugs.python.org/file15396/issue6615_weakref.diff ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue6615] multiprocessing logging support test

flox added the comment: Updated the patch with technical recommendations from Antoine. I kept the _handlerList as a list because "It allows handlers to be removed in reverse of order initialized." And some tests are needed to outline the change. -- Added file: http://bugs.python.org/f

[issue6615] multiprocessing logging support test

Antoine Pitrou added the comment: Some quick comments on your patch (not an in-depth review): - you should add some tests for the problem you're trying to solve - using __del__ when you have a weakref is counter-productive; use the weakref's optional callback instead - if you remove arbitrary el

[issue7117] Backport py3k float repr to trunk

Eric Smith added the comment: Thanks for tackling the last few bits, Mark. I think we're done, although I admit I haven't verified what state the documentation is in. I suggest we close this issue and if any problems occur open them as new issues. -- __

[issue7391] Re-title the "Using Backslash to Continue Statements" anti-idiom

Georg Brandl added the comment: As you write, the parentheses "trick" only works in expressions (what you tried to wrap in your with statement is not an expression). The backslash works for all kinds of statements however, so the suggested change is wrong. -- resolution: -> wont fix s

[issue5911] built-in compile() should take encoding option.

Changes by Trundle : -- nosy: +Trundle ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/ma

[issue6615] multiprocessing logging support test

flox added the comment: yep... patch was not clean. Sorry :( I changed it. It passes the 21 tests of the test_logging suite. And the count of references decreases with the test: >>> import logging >>> handler = logging.Handler() >>> handler = logging.Handler() -- Added file: http://b

[issue6615] multiprocessing logging support test

Changes by flox : Removed file: http://bugs.python.org/file15395/issue6615_weakref.diff ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue7117] Backport py3k float repr to trunk

Mark Dickinson added the comment: I think we're pretty much done here. I'd still like to produce a more complete set of float formatting test cases at some point (for both trunk and py3k), but that's a separate activity. Eric, Raymond: can you spot anything we've missed? -- __

[issue7228] %lld for PyErr_Format (Modules/_io/bufferedio.c)

Mark Dickinson added the comment: Thanks for testing! Fixed (again) in r76502 (trunk), r76503 (py3k). I don't think it's worth backporting the fix to the release branches, given that that would require also implementing %lld support in those branches. -- resolution: -> fixed status

[issue6615] multiprocessing logging support test

Vinay Sajip added the comment: > With the patch attached, if the handler is not referenced anywhere, it > is closed. > However named handlers are not closed (because of hard reference in > _handlers dictionary). I haven't tried it yet, but does the patch actually work? You seem to have self_w

[issue6615] multiprocessing logging support test

flox added the comment: I would think to use weak references in order to prevent such leaks. With the patch attached, if the handler is not referenced anywhere, it is closed. However named handlers are not closed (because of hard reference in _handlers dictionary). -- nosy: +flox Added

[issue6615] multiprocessing logging support test

Vinay Sajip added the comment: > removing from a handler), it's removed from the list and would not cause a s/handler/logger/ -- ___ Python tracker ___

[issue6615] multiprocessing logging support test

Vinay Sajip added the comment: > Why is this exactly? Why do you want to keep handlers until shutdown > rather than dispose of them when they aren't used anymore? Typically handlers are only instantiated when being added to loggers, and loggers live for the lifetime of the process so those ha

[issue6615] multiprocessing logging support test

Antoine Pitrou added the comment: > Handler.__init__ no longer adds the handler instance to the _handlers > map unconditionally, but still adds it to the _handlerList array. The > only place this array is actually used is in the shutdown() API, which > is registered to be run via atexit. It flus

[issue7128] cPickle looking for non-existent package copyreg

Alexandre Vassalotti added the comment: Thanks you! Committed in r76499 and backported to 2.6 in r76500. -- resolution: -> accepted stage: needs patch -> committed/rejected status: open -> closed ___ Python tracker

[issue3924] cookielib chokes on non-integer cookie version, should ignore it instead

Changes by Andrew Shuiu : -- versions: +Python 3.1 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue7392] cPickle test failure on release26-maint branch

New submission from Alexandre Vassalotti : I get the following test failure on the release26-maint branch: ./python Lib/test/test_cpickle.py [...] == ERROR: test_issue2702 (__main__.cPickleDeepRecursive)

[issue6615] multiprocessing logging support test

Vinay Sajip added the comment: > In general it would be nice if logging were more conservative (or > cautious) when it comes to keeping objects persistent. It is too easy to > fall into a trap and experience memory leaks. I've checked in a change into trunk today which might improve matters.

[issue7382] bytes.__getnewargs__ is broken; copy.copy() therefore doesn't work on bytes, and bytes subclasses can't be pickled by default

Alexandre Vassalotti added the comment: We just need make __getnewargs__ return bytes, instead of a unicode string. So this is a single character fix. I think we should reuse the ByteArraySubclass test case in test_bytes.py to test for this bug. Incidentally, the reduce method of bytearray shou

[issue5166] ElementTree and minidom don't prevent creation of not well-formed XML

Denis S. Otkidach added the comment: Here is a regexp I use to clean up text (note, that I don't touch "compatibility characters" that are also not recommended in XML; some other developers remove them too): # http://www.w3.org/TR/REC-xml/#NT-Char # Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] |

[issue6033] LOOKUP_METHOD and CALL_METHOD optimization

Changes by Reid Kleckner : -- nosy: +rnk ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/

[issue1700507] Carbon.Scrap.PutScrapFlavor

Ronald Oussoren added the comment: Lowering the priority to low because this is a bug in a deprecated binding for a deprecated Apple framework. I won't work on a fix, although I am willing to review and apply a patch when someone provides one. -- nosy: +ronaldoussoren priority: norma

[issue822005] Carbon.CarbonEvt.ReceiveNextEvent args wrong

Changes by Ronald Oussoren : -- resolution: -> wont fix versions: +Python 2.6, Python 2.7 ___ Python tracker ___ ___ Python-bugs-lis

[issue822005] Carbon.CarbonEvt.ReceiveNextEvent args wrong

Ronald Oussoren added the comment: According to this issue is valid. However, I won't work on fixing this because Carbon is deprecated, both the Python bindings and the frame

[issue1653416] print >> f, "Hello" produces no error: normal?

Ronald Oussoren added the comment: claims fprintf should return a negative value when there is an output error (the same claims is in the manpage of fprintf on OSX 10.6). Neither document refers to the error indicator. I'm

[issue6615] multiprocessing logging support test

Jesse Noller added the comment: Yeah, I should have checked the tearDown stuff in the logging test suite -- ___ Python tracker ___ ___

[issue6393] OS X: python3 from python-3.1.dmg crashes at startup

Changes by Ronald Oussoren : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue5166] ElementTree and minidom don't prevent creation of not well-formed XML

Andy added the comment: I'm also of the opinion that this would be a valuable feature to have. I think it's a reasonable expectation that an XML library produces valid XML. It's particularly strange that ET would output XML that it can't itself read. Surely the job of making the input valid fall

[issue7383] test_multiprocessing leaks

R. David Murray added the comment: I haven't looked at the test, but is it possible that the logging module is creating state that isn't being cleaned up after the test completes? Test refleaks don't always mean refleaks in the underlying C code. -- ___

[issue6615] multiprocessing logging support test

Antoine Pitrou added the comment: > Yes, test_logging has a serious tearDown() method to wipe installed > handlers. In general it would be nice if logging were more conservative (or cautious) when it comes to keeping objects persistent. It is too easy to fall into a trap and experience memory l

[issue6615] multiprocessing logging support test

Amaury Forgeot d'Arc added the comment: Yes, test_logging has a serious tearDown() method to wipe installed handlers. -- ___ Python tracker ___ __

[issue6615] multiprocessing logging support test

Antoine Pitrou added the comment: >From a quick command-line attempt, it seems that logging is the culprit: >>> handler = logging.Handler() [64370 refs] >>> handler = logging.Handler() [64383 refs] >>> handler = logging.Handler() [64396 refs] -- nosy: +pitrou, vinay.sajip

[issue6615] multiprocessing logging support test

Amaury Forgeot d'Arc added the comment: Are these leaks caused by the test, or revealed by it? -- nosy: +amaury.forgeotdarc ___ Python tracker ___ ___

[issue7383] test_multiprocessing leaks

Jesse Noller added the comment: I've backed it out on trunk and py3k. I've reopened the original bug to debug the refleak caused by the test. -- resolution: -> fixed status: open -> closed ___ Python tracker

[issue6615] multiprocessing logging support test

Jesse Noller added the comment: I've commented out the test (therefore, reopening this) the test introduces a pretty bad refleak problem. Need to debug. -- resolution: fixed -> accepted status: closed -> open ___ Python tracker

[issue7391] Re-title the "Using Backslash to Continue Statements" anti-idiom

New submission from Neil Cerutti : This "anti-idiom" is in the Python HOWTOs->Idioms and Anti-Idioms The current title is "Using Backslash to Continue Statements" However, using the line continuation character won't cause mysterious problems in statements, but only in certain expressions, as th

[issue7383] test_multiprocessing leaks

Jesse Noller added the comment: Well, that's alarming. I'll back that out for now - I'm fairly disturbed it introduced leaks that bad. -- ___ Python tracker ___

[issue7383] test_multiprocessing leaks

Antoine Pitrou added the comment: > R. David Murray added the comment: > > This started just after r76438, which is an additional test for > multiprocessing. Given build delays this is only a correlation not a > definite cause, but it is suspicious. I just checked, it was indeed introduced b

[issue5294] pdb "break" command messes up "continue"

Swapnil Talekar added the comment: The problem it seems is actually in the bdb module and not in pdb. The set_next function sets the current frame as stopframe but it does not specify the stoplineno. Hence it's always -1. When you do c(ontinue), set_continue just sets botframe as stopframe, i

[issue7382] bytes.__getnewargs__ is broken; copy.copy() therefore doesn't work on bytes, and bytes subclasses can't be pickled by default

Changes by Antoine Pitrou : -- nosy: +alexandre.vassalotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue7390] inconsistent type return

Changes by Antoine Pitrou : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue7390] inconsistent type return

Antoine Pitrou added the comment: `instance` means it is an instance of an old-style class. Old-style classes are classes which don't have `object` in their inheritance hierarchy. On the other hand, for instance new-style classes type() returns the actual class. Bottom line: this is by design. O

[issue7390] inconsistent type return

flox added the comment: The relevant documentation for Python 2.6 is there. http://docs.python.org/reference/datamodel.html#new-style-and-classic-classes The PEP 3115 is implemented for Python >= 3.0. There's nothing wrong. -- nosy: +flox ___ Pytho

[issue7390] inconsistent type return

New submission from Sérgio Surkamp : The type function returns inconsistent value depending on class hierarchy. >>> class X: ... pass ... >>> x = X() >>> type(x) >>> class Y(object): ... pass ... >>> x = Y() >>> type(x) >>> >>> class Z(X): ... pass ... >>> x = Z() >>> type(x)

[issue7389] Make decimal floating point be default, remove binary floating point

Mark Dickinson added the comment: I think the bug tracker is the wrong place to discuss such a wide- ranging and (currently) ill-specified change. The python-list or python-ideas mailing lists might be better places. Decimal in the core is out of the question for Python 3.2, thanks to PEP 30

[issue7389] Make decimal floating point be default, remove binary floating point

New submission from Retro : The Python interpreter should have the decimal type built into its core. The mechanism for dealing with decimal numbers should be handled by the decimal type and not by the processor which spits binary floats. The time is now. But ask yourself these questions: Is this

[issue1519816] urllib2 proxy does not work in 2.4.3

Senthil Kumaran added the comment: HTTP Proxy Authentication works on Windows and has been verified. Under the situation of failure, we do not enough details. Closing this bug as out-of-date as the reporter informed it worked on py2.5 and problem was with py2.4. -- assignee: -> orsenth

[issue7388] Documentation: capitalizations of the word 'python' needed when used as a name

Changes by Georg Brandl : -- keywords: +easy priority: -> low ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue7388] Documentation: capitalizations of the word 'python' needed when used as a name

New submission from Retro : There are 'python' typos in the Python tutorial in these titles: (1) Tools for Working with Lists: The following example shows an array of numbers stored as two byte unsigned binary numbers (typecode "H") rather than the usual 16 bytes per entry for regular lists of !

[issue6683] smtplib authentication - try all mechanisms

Ben Standefer added the comment: Here is one work-around. The default smtplib.SMTP.login() doesn't work for StrongMail out of the box. http://www.harelmalka.com/?p=94&cpage=1 -- nosy: +aguynamedben ___ Python tracker