[issue1031213] Use correct encoding for printing SyntaxErrors

Martin v. Löwis added the comment: > Should we silently clear the exception raised by codecs, or print a > message such as "Codec raised an exception while processing compile > error." ? Can you create a test case that triggers that specific problem? Regards, Martin ___

[issue1031213] Use correct encoding for printing SyntaxErrors

atsuo ishimoto added the comment: Sorry for insufficient comment. When a codec raised an exception, I think the exception should be reported. Otherwise, user cannot know why Python prints broken line of code. Should we silently clear the exception raised by codecs, or print a message such as

[issue1260] PEP 3137: Remove the buffer API from PyUnicode

Changes by Martin v. Löwis: -- keywords: +patch __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue1258] Removal of basestring type

Changes by Martin v. Löwis: -- keywords: +patch __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue1258] Removal of basestring type

Guido van Rossum added the comment: On 10/10/07, Christian Heimes <[EMAIL PROTECTED]> wrote: > > Christian Heimes added the comment: > > Guido van Rossum wrote: > > Did you svn up, make clean and rebuild? > > The ctypes package didn't change since my last rebuild an hour ago. I'm > on Linux (Ubun

[issue1260] PEP 3137: Remove the buffer API from PyUnicode

New submission from Alexandre Vassalotti: This patch removes the buffer API from PyUnicode, as specified by PEP 3137. All the unit tests passes. However, I believe there is a few function calls to PyArg API that could become problematic if they are given a PyUnicode object: % egrep -R --includ

[issue1031213] Use correct encoding for printing SyntaxErrors

Guido van Rossum added the comment: > PyErr_Print() is called to report exception raised by codec. > If PyUnicode_DecodeUTF8() or PyUnicode_AsEncodedString() return NULL, > PyErr_Print() is called. This comment is not very helpful; it describes what happens, but not why, or whether that is a goo

[issue1031213] Use correct encoding for printing SyntaxErrors

atsuo ishimoto added the comment: PyErr_Print() is called to report exception raised by codec. If PyUnicode_DecodeUTF8() or PyUnicode_AsEncodedString() return NULL, PyErr_Print() is called. _ Tracker <[EMAIL PROTECTED]> _

[issue1259] string find and rfind methods give a TypeError that is misleading

Barry A. Warsaw added the comment: I believe this is because string_find_internal() uses an O& with _PyEval_SliceIndex() to convert its start and end arguments, but the latter function does not accept None. To fix this, you'd have to change string_find_internal() to do its own argument checking

[issue1259] string find and rfind methods give a TypeError that is misleading

New submission from Robert Collins : Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 'asd'.find('s',

[issue1258] Removal of basestring type

Christian Heimes added the comment: Guido van Rossum wrote: > Did you svn up, make clean and rebuild? The ctypes package didn't change since my last rebuild an hour ago. I'm on Linux (Ubuntu i386) > >> test_email: need some help from an email expoert > > Which test is failing? test_decoded_ge

[issue1258] Removal of basestring type

Guido van Rossum added the comment: On 10/10/07, Christian Heimes <[EMAIL PROTECTED]> wrote: > > Christian Heimes added the comment: > > test_ctypes: works for me Did you svn up, make clean and rebuild? > test_email: need some help from an email expoert Which test is failing? > test_httplib:

[issue1258] Removal of basestring type

Christian Heimes added the comment: test_ctypes: works for me test_email: need some help from an email expoert test_httplib: __file__ has a wrong type str8. I'm looking into it. test_inspect: same issue as httplib test_os: same issue test_re: I had the failing test before my changes File "Lib/tes

[issue1258] Removal of basestring type

Guido van Rossum added the comment: I see 10 failing tests: test_ctypes test_email test_httplib test_inspect test_os test_re test_subprocess test_sys test_xml_etree test_xml_etree_c -- assignee: -> gvanrossum __ Tracker <[EMAIL PROTECTED]>

[issue1258] Removal of basestring type

Guido van Rossum added the comment: Thanks, evaluating! -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list

[issue1257] atexit errors should result in nonzero exit code

Lakin Wecker added the comment: sorry for the noise and duplication. The full code listing should have been: 46 # Sometimes an exception happens during exit, try to make sure we get 47 # a non_zero exit code. 48 old_exitfunc =

[issue1257] atexit errors should result in nonzero exit code

Lakin Wecker added the comment: I am an agreeance with the original report. I just finished writing an automated test that did the following to work around this behavior: 46 # Sometimes an exception happens during exit, try to make sure we get 47 #

[issue1257] atexit errors should result in nonzero exit code

New submission from Robert Brewer : While debugging/fixing the logging module's atexit behavior (see http://www.cherrypy.org/ticket/646 -- it chokes atexit if stdout is closed), it became difficult to write an automated test

[issue1255] Strange Python hangup

Jiri Krivanek added the comment: One more hint: There is the coincidence of three facts: 1. It uses the thread (if I remove the thread then it works fine). 2. It is "double imported" (if I remove the outer import then it works fine). 3. There is the strptime() function being used (if I remove thi

[issue1255] Strange Python hangup

Jiri Krivanek added the comment: The reason for it is pragmatic: The whole of my application is published as .pyc files. Except of the only one which must stay .py - that one which has to be executable (+x) on Linux and thus it starts with the line: # !/usr/bin/python and then it should only cont

[issue1251] ssl module doesn't support non-blocking handshakes

Bill Janssen added the comment: Yes, that's correct. I've reviewed your patch, and it looks OK to me. I'll fold it in in the next go-around, once I've made some progress on the asyncore issues. __ Tracker <[EMAIL PROTECTED]> _

[issue1031213] Use correct encoding for printing SyntaxErrors

Martin v. Löwis added the comment: ishimoto: in dec_utf8, there is a PyErr_Print call. What is the purpose of this call? _ Tracker <[EMAIL PROTECTED]> _ _

[issue1251] ssl module doesn't support non-blocking handshakes

Chris Stawarz added the comment: I meant that SSL-wrapped sockets must be set non-blocking in the case where you want to do non-blocking I/O with them using select(). This is another difference between SSL-wrapped sockets and normal sockets. With a normal socket, as long as you use select

[issue1256] subprocess Popen wait() function hangs when stdout is > 20480

New submission from superwesman: hi - I noticed some odd behaviour with subprocess when the output (stdout) is large - I did some sleuthing and found a reproduceable case - I tested this on solaris using python 2.4.2 (sparc) and using 2.5 (opteron) - I've attached a python script that details the

[issue1251] ssl module doesn't support non-blocking handshakes

Bill Janssen added the comment: "SSL-wrapped sockets *must* be set non-blocking." Can you say a bit more about why? __ Tracker <[EMAIL PROTECTED]> __ __

[issue1251] ssl module doesn't support non-blocking handshakes

Changes by Guido van Rossum: -- nosy: -gvanrossum __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue1255] Strange Python hangup

Tim Golden added the comment: Do you realise that the code at the bottom of bb.py is executed when you import it from aa.py? In other words, when you run aa.py, the whole of your significant code is running within an import statement. I don't know if it's the cause of the problem (although I reme

[issue1251] ssl module doesn't support non-blocking handshakes

Chris Stawarz added the comment: Yeah, the pattern for doing non-blocking I/O with select() is different for SSL-wrapped sockets: You always have to try the potentially-blocking operation first, and then call select() and retry in response to SSL_ERROR_WANT_READ/WRITE. (You can also check

[issue1254] pdb fails to launch some script.

New submission from Romain JACQUET: Pdb fails to launch any scripts that uses the __file__ builtin. This problem occurs because pdb does not set the global environnement correctly. It can be corrected by setting the global variable __file__ before pdb executes the file. Lib/pdb.py: Replace : gl

[issue1251] ssl module doesn't support non-blocking handshakes

Bill Janssen added the comment: The larger problem here is that straightforward select() just doesn't work with SSL-wrapped sockets. If you depend on it for liveness, your program will eventually hang up. When packets in SSL arrive at a destination, they are pulled off the socket in chunks o