[issue1411] A typo in tutorial

Georg Brandl added the comment: Fixed in r58921. -- nosy: +georg.brandl resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ _

[issue1408] Inconsistence in multiply list

Georg Brandl added the comment: I'm sorry, this is no bug. List multiplication works by referencing, there is no way to implement it differently in a straightforward way. Note that in >>> [a[:]] + [a[:]] the expression "a[:]" is evaluated twice, yielding two independent copies of a. In contrast,

[issue1412] test_subprocess fails on SuSE 10

New submission from Denes Vadasz: I compiled Python 2.5.1 on SuSE 10 and ran "make test", which reported test_subprocess.py to fail on lines 537 and 579 with "permission denied". After a short investigation it looks the problem is that in SuSE 10 the shell (bash) rejects to execute scripts re

[issue1409] new keyword-only function parameters interact badly with nested functions

Christian Heimes added the comment: I set this bug to accepted because I was able to reproduce it yesterday. It's all in the history. Scroll down, pal! :) -- nosy: +tiran __ Tracker <[EMAIL PROTECTED]> __

[issue1409] new keyword-only function parameters interact badly with nested functions

Georg Brandl added the comment: I think you misunderstood the meaning of "accepted" in our tracker - it may mean "I confirm that this is a bug" somewhere else, here it means "patch accepted". -- nosy: +georg.brandl __ Tracker <[EMAIL PROTECTED]>

[issue1413] int literal methods inaccessible

New submission from Michal Božoň: It's impossible to call methods of int literals directly e.g. 1.__str__() (the same for oct literals). Even through it works for float, hex, literals, etc.. >>> 0x1.__str__() '1' >>> 1e0.__str__() '1.0' >>> 1..__str__() '1.0' >>> hasattr(1, '__str__') True >>> 1

[issue1401] urllib2 302 POST

Senthil added the comment: Hello Andres, I think we are mixing up 2 or 3 things. Here are my comments. 1) urllib2 POST issue. - Discussion broke on this. No conclusion. 2) GET Request. >> If we create a GET request (handling 302 as 303) we should >> remove the content length header! I fail to

[issue1401] urllib2 302 POST

Andres Riancho added the comment: As I said in my original bug report, if you don't remove the content-length header or add the data, you are sending an invalid request: START Request= GET http://f00/1.php HTTP/1.1 Content-length: 63 Accept-encoding: identity Accept: */* User-agent: w3af

[issue1409] new keyword-only function parameters interact badly with nested functions

Christian Heimes added the comment: Oh, I misinterpreted the meaning of accepted. Can somebody please add a "confirmed" resolution? __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1413] int literal methods inaccessible

Michal Božoň added the comment: .. OK, now I see than (1).__str__() works.. however, could be the parser fixed to 1.__str__() work too ? __ Tracker <[EMAIL PROTECTED]> __ __

[issue1351] Add getsize() to io instances

Christian Heimes added the comment: Does "it's convenient and I'm too lazy to address it in my code whenever the problem arises?" count as a darn good use case? No? Mh, I thought so :) __ Tracker <[EMAIL PROTECTED]> ___

[issue1414] Fix for refleak tests

Changes by Christian Heimes: -- assignee: gvanrossum keywords: patch, py3k nosy: gvanrossum, tiran priority: low severity: normal status: open title: Fix for refleak tests versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]>

[issue1414] Fix for refleak tests

New submission from Christian Heimes: The patch prevents some tests from running multiple times in a test session. Added file: http://bugs.python.org/file8720/py3k_reftestfix.patch __ Tracker <[EMAIL PROTECTED]>

[issue1395] py3k: duplicated line endings when using read(1)

Raghuram Devarakonda added the comment: On 11/8/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I do think there is something iffy here -- the 2.x version of this > test opens the files in binary mode. I wonder what end users are > supposed to do. I think that requirement (need to open in bina

[issue1410] BaseHTTPServer cannot accept Unicode data

Christian Heimes added the comment: Due to its nature it is impossible to transmit unicode over the wire. Unicode must always be encoded to bytes before it can be stored on the hard disk or transmitted. Typically it's UTF-8 but in your case it depends on the client's browser and the Request heade

[issue1409] new keyword-only function parameters interact badly with nested functions

Georg Brandl added the comment: Please discuss that in the meta tracker (see the "report tracker problem" link in the sidebar). __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1409] new keyword-only function parameters interact badly with nested functions

Christian Heimes added the comment: > Please discuss that in the meta tracker (see the "report tracker > problem" link in the sidebar). Done http://psf.upfronthosting.co.za/roundup/meta/issue167 __ Tracker <[EMAIL PROTECTED]> __

[issue1414] Fix for refleak tests

Guido van Rossum added the comment: Hm, I was hoping more for patches to the C code that would make these initializations reentrant (e.g. by testing a flag in C that says "I'm already initialized"). __ Tracker <[EMAIL PROTECTED]>

[issue1405] Garbage collection not working correctly in Python 2.3

Stefan Sonnenberg-Carstens added the comment: No, I can't. As many Front Arena Developers on the 1.6/2.0/2.1/2.2 can't. Python 2.4 will be in Front Arena 4.0. Lightyears away from here. Same behaviour seen under Solaris 10 / Python 2.5.1 -- versions: +Python 2.5

[issue1405] Garbage collection not working correctly in Python 2.3

Changes by Christian Heimes: -- resolution: out of date -> status: closed -> open __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailin

[issue1405] Garbage collection not working correctly in Python 2.3

Paul Pogonyshev added the comment: See if gc.set_threshold (0, 0, 0) helps. -- nosy: +_doublep __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs

[issue1403] py_compile and compileall need unit tests

Guido van Rossum added the comment: Why is it still open? -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing li

[issue1405] Garbage collection not working correctly in Python 2.3

Guido van Rossum added the comment: How do you know the memory isn't given back? It may be available for reallocation within Python, just not given back to the operating system. That's not necessarily a leak or a bug; that could just be heap fragmentation. There's nothing you can do about it. --

[issue1410] BaseHTTPServer cannot accept Unicode data

Changes by Guido van Rossum: -- resolution: -> invalid status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing li

[issue1407] [performance] Too many closed() checkings

Guido van Rossum added the comment: To find out what really happens, use pdb to step through the example. This gives much better insight than adding a printf() call to PyObject_Call(). I've notice myself when stepping through I/O that there are a lot of checks for closed -- this may have to do wi

[issue1414] Fix for refleak tests

Christian Heimes added the comment: Here is a version of test_freeze that doesn't depend on stdout output on load. Added file: http://bugs.python.org/file8721/py3k_reftestfix2.patch __ Tracker <[EMAIL PROTECTED]> ___

[issue1403] py_compile and compileall need unit tests

Christian Heimes added the comment: I've left this bug open because no unit tests verifies that compileall can compile all files under Lib/. It has caused a problem with the Windows installer in 3.0a1 for some people. I like to add a compileall followed by a cleanup to make testall. I hope that'

[issue1413] int literal methods inaccessible

Michal Božoň added the comment: I don't understand why 1.j is 1j .. because there's no int.j .. why then 1.L is not 1L ? __ Tracker <[EMAIL PROTECTED]> __ __

[issue1413] int literal methods inaccessible

Michal Božoň added the comment: .. however, fixing this is not necessary - because no one would probably use it, it's just a syntax inconsistency __ Tracker <[EMAIL PROTECTED]> __ _

[issue1413] int literal methods inaccessible

Michal Božoň added the comment: (finally now I get it.. I have forgotten that complex numbers can be float.. :) sorry ) __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1413] int literal methods inaccessible

Christian Heimes added the comment: > I don't understand why 1.j is 1j .. because there's no int.j .. why then > 1.L is not 1L ? Complex numbers from the number domain |C which supersets |R. Complex numbers are usually implemented and viewed as 2d vectors made from two floating numbers real and

[issue1413] int literal methods inaccessible

Christian Heimes added the comment: It's a tricky problem because it's ambiguous: >>> 1.j What's going to happen here? Does it do getattr(1, 'j') or does it create the imaginary number 1j? -- nosy: +tiran __ Tracker <[EMAIL PROTECTED]>

[issue1413] int literal methods inaccessible

Michal Božoň added the comment: I don't know it's in docs, it came into my mind, maybe logically (but later) to put 1 into parentheses __ Tracker <[EMAIL PROTECTED]> __

[issue1413] int literal methods inaccessible

Michal Božoň added the comment: .. I remember.. it came onto my mind when I tried also -1.__str__() and found out that the dot has higher priority than unary minus :) __ Tracker <[EMAIL PROTECTED]> ___

[issue1410] BaseHTTPServer cannot accept Unicode data

J. Peterson added the comment: As implemented it's not even possible to send UTF-8, because the "data = str(data)" line only accepts seven bit ASCII with the default encoding. Since there's no easy way to change the encoding "str()" uses, some other mechanism should be available to do the encodi

[issue1410] BaseHTTPServer cannot accept Unicode data

Christian Heimes added the comment: Yes, it's possible to send UTF-8 data: >>> data = u"testdata umlaut öäü".encode("utf-8") >>> data 'testdata umlaut \xc3\xb6\xc3\xa4\xc3\xbc' >>> type(data) >>> data == str(data) True >>> data is str(data) True You have to encode your unicode string to a byte

[issue1410] BaseHTTPServer cannot accept Unicode data

Christian Heimes added the comment: PS: http://www.joelonsoftware.com/articles/Unicode.html is a nice article about unicode and character sets. Joel is amazing when it comes to explaining complex problems in simple words. __ Tracker <[EMAIL PROTECTED]>

[issue1234] semaphore errors on AIX 5.2

Christian Heimes added the comment: I'm setting the priority to high because it sounds important for AIX users and the patch is *really* simple, just two additional lines for configure.in -- keywords: +patch nosy: +tiran priority: -> high versions: +Python 2.5, Python 2.6, Python 3.0 _

[issue1413] int literal methods inaccessible

Martin v. Löwis added the comment: As now should be clear, there really is no bug here. Notice that you can also write 1 .__str__() -- nosy: +loewis resolution: -> invalid status: open -> closed __ Tracker <[EMAIL PROTECTED]>

[issue1413] int literal methods inaccessible

Michal Božoň added the comment: interesting. I'm not sure I've read anywhere that it is allowed to place a whitespace between object and attributes. Thanks __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1378] fromfd() and dup() for _socket on WIndows

Christian Heimes added the comment: I've created a clean patch and tested it. It works as promised, great work! Somebody with more Windows Fu than me should verify it before it's applied. -- nosy: +tiran Added file: http://bugs.python.org/file8723/trunk_socket_fromfd.patch _

[issue1631171] implement warnings module in C

Changes by Christian Heimes: -- nosy: +tiran _ Tracker <[EMAIL PROTECTED]> _ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue718532] inspect, class instances and __getattr__

Changes by Christian Heimes: -- versions: +Python 2.5, Python 2.6, Python 3.0 Tracker <[EMAIL PROTECTED]> ___ Python-bugs-list maili

[issue1704621] interpreter crash when multiplying large lists

Christian Heimes added the comment: Python 2.5 still seg faults. Python 2.6 and 3.0 are raising a memory error. However I'm unsure if the memory error is also raised in a plain build. I've just Py_DEBUG builds of 2.6 and 3.0 around. -- nosy: +tiran versions: +Python 2.5, Python 2.6, Pyt

[issue815646] thread unsafe file objects cause crash

Christian Heimes added the comment: I'm still able to reproduce the bug in Python 2.5 (svn) and 2.6 (trunk). import thread f=open("tmp1", "w") def worker(): global f while 1: f.close() f=open("tmp1", "w") f.seek(0,0) thread.start_new_thread(worker, ()) thread.st

[issue1678380] 0.0 and -0.0 identified, with surprising results

Christian Heimes added the comment: It's fixed in 2.6 but still broken in 2.5. -- nosy: +tiran versions: +Python 2.5 _ Tracker <[EMAIL PROTECTED]> _

[issue1413] int literal methods inaccessible

Martin v. Löwis added the comment: See http://www.python.org/doc/2.5/ref/whitespace.html which says that you can put spaces between arbitrary tokens, and http://www.python.org/doc/2.5/ref/attribute-references.html which says that all of primary, ".", and identifier are separate tokens in an a

[issue1351] Add getsize() to io instances

Martin v. Löwis added the comment: Ok, I'm rejecting it now based on the YAGNI argument Guido brought up, and based on my own concerns. -- resolution: -> rejected status: open -> closed __ Tracker <[EMAIL PROTECTED]> __

[issue1415] py3k: pythonw.exe fails to run

New submission from Christian Heimes: pythonw.exe fails to run with a runtime error. python.exe works as expected. While the bug itself isn't serious it should either be fixed or pythonw.exe be omitted from the next alpha release. -- components: Windows keywords: py3k messages: 57342 nos

[issue1415] py3k: pythonw.exe fails to run

Christian Heimes added the comment: Update: pythonw fails because the standard streams can't be initialized. fileno(stdin), fileno(stdout) and fileno(stderr) are returning -2. __ Tracker <[EMAIL PROTECTED]> _

[issue1415] py3k: pythonw.exe fails to run

Christian Heimes added the comment: Python 2.6 (svn trunk) doesn't check the file handlers when it creates sys.stdin, stdout and stderr. write() operations to stdout and stderr don't fail although the data is written into nowhere land. stdin.read() fails with IOError: [Errno 9] Bad file descripto

[issue1416] @prop.setter decorators

New submission from Guido van Rossum: Here's an implementation of the idea I floated recently on python-dev (Subject: Declaring setters with getters). This implements the kind of syntax that I believe won over most folks in the end: @property def foo(self): ... @foo.setter def foo(self