[issue1541420] tools and demo missing from windows
Martin v. Löwis added the comment: I'm closing it as won't fix. If you have specific tools that you would like to see included, please submit that as a separate report, along with a rationale as to why you want to see them included. -- resolution: - wont fix status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1541420 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1252] IDLE - patch Delegator to support callables
Changes by Martin v. Löwis: -- keywords: +patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1252 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1253] IDLE - Percolator overhaul
Changes by Martin v. Löwis: -- keywords: +patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1253 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 of sizes controlled by the encryption protocol being used, decrypted, and placed in SSL-internal buffers. The buffer content is then transferred to the application program through SSL_read(). If you've read only part of the decrypted data, there will still be pending input data on the SSL connection, but it won't show up on the underlying file descriptor via select(). Your code needs to call SSL_pending() explicitly to see if there is any pending data to be read. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1251 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 : globals_ = {__name__ : __main__}
by: globals_ = {__name__ : __main__, __file__: filename}
The problem happens also in python 2.5.
--
components: Library (Lib)
files: bug.py
messages: 56312
nosy: romain_jacquet
severity: normal
status: open
title: pdb fails to launch some script.
type: behavior
versions: Python 2.4
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1254
__
Output:
---
pdb bug.py
/home/romain/prog-test/bug.py(1)?()
- print file is %s % (__file__,)
(Pdb) c
Traceback (most recent call last):
File /usr/bin/pdb, line 1067, in main
pdb._runscript(mainpyfile)
File /usr/bin/pdb, line 992, in _runscript
self.run(statement, globals=globals_, locals=locals_)
File bdb.py, line 366, in run
exec cmd in globals, locals
File string, line 1, in ?
File bug.py, line 1, in ?
print file is %s % (__file__,)
NameError: name '__file__' is not defined
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
/home/romain/prog-test/bug.py(1)?()
- print file is %s % (__file__,)
(Pdb)
print file is %s % (__file__,)
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 SSL_pending(), but I don't think you really have to.) Also, unlike normal sockets, SSL-wrapped sockets *must* be set non-blocking. I can see how this pattern might not play nicely with asyncore. But I think this is a separate (though related) issue from the one I reported. As it's currently implemented, the ssl module provides no way of wrapping a socket without (potentially) blocking during the handshake, making it unusable by Twisted or any other package that requires all I/O to be non-blocking. Moving the handshaking into a separate method solves this problem. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1251 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 remember past strictures on the messiness of threads and imports) but I doubt if it's a fantastic design choice. -- nosy: +tim.golden __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1255 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1251] ssl module doesn't support non-blocking handshakes
Changes by Guido van Rossum: -- nosy: -gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1251 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1251 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 problem - I created 2 files (small_file and large_file) that are 20480 and 20481 bytes, respectively ls -lrt ./tmp/*_file -rw-r--r-- 1 wtorres staff 20481 Oct 10 12:32 ./tmp/large_file -rw-r--r-- 1 wtorres staff 20480 Oct 10 12:32 ./tmp/small_file the script cats each file, thus generating an appropriately sized stdout - the workaround we came up with was to use our own file handle and use the parameter stdout=my_file_handle.fileno() instead of stdout=PIPE - you can see this in the attached example as well python ./tmp/brent.py testing with a small file - these should both work using my own file handle ok using PIPE ... ok testing with a large file - the second one here should fail using my own file handle ok using PIPE ... Traceback (most recent call last): File ./tmp/brent.py, line 43, in ? test_popen_bug( large_file ) File ./tmp/brent.py, line 31, in test_popen_bug rc = my_popen.wait() File /tools/python/2.4.2/solaris/lib/python2.4/subprocess.py, line 1007, in wait pid, sts = os.waitpid(self.pid, 0) KeyboardInterrupt based on all this, it seems that the PIPE file handle has some buffer or something that is filling up and not allowing us to continue... or something. Thoughts? -w -- components: None files: brent.py messages: 56317 nosy: superwesman severity: normal status: open title: subprocess Popen wait() function hangs when stdout is 20480 type: behavior versions: Python 2.4 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1256 __ brent.py Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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() to know when a read or write won't block, it shouldn't matter whether you've called setblocking(False) on the socket (although there may be corner cases where it does). With an SSL-wrapped socket, you have to try the I/O operation first, and then call select() if it fails with SSL_ERROR_WANT_READ/WRITE. But that won't happen if the socket is in blocking mode. In that case, the OpenSSL call will just block until the operation completes (or an error or disconnection occurs). That's my understanding, anyway, based on the OpenSSL man pages and my own usage. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1251 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1031213 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1251 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 contain: import something and something is .pyc. So I did a simple change into my application. I start it via a very brief script whic only contains: # !/usr/bin/python import something Wow! It stopped working at all! After 4 hours of isolating of the problem I developped an elementary code which demonstrates my problem (attached at the bug report). I expect that the import statement does not return the control until the code being executed by it finishes, does'n it? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1255 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 this function then it works fine). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1255 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 that verified the bug occurred, since it happened at program exit. Returning a nonzero exit code when atexit errors occur would be preferable to just printing the error. Of course, if SystemExit is already raised, we should propagate that out, but other exceptions should print the traceback and then return some other code IMO. -- components: Interpreter Core messages: 56323 nosy: aminusfu severity: normal status: open title: atexit errors should result in nonzero exit code type: behavior versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1257 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 # a non_zero exit code. 48 old_exitfunc = sys.exitfunc 49 def exitfunc(): 50 try: 51 old_exitfunc() 52 except SystemExit: 53 raise 54 except: 55 raise SystemExit(1) -- nosy: +lakin.wecker __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1257 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 = sys.exitfunc 49 def exitfunc(): 50 try: 51 old_exitfunc() 52 except SystemExit: 53 raise 54 except: 55 raise SystemExit(1) 56 sys.exitfunc = exitfunc __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1257 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1258] Removal of basestring type
Guido van Rossum added the comment: Thanks, evaluating! -- nosy: +gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1258 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1258 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/test/test_re.py, line 622, in test_empty_array ValueError: bad typecode (must be b, B, u, h, H, i, I, l, L, f or d) test_subprocess: I don't understand why it fails. The traceback is missing a line test_sys: related to __file__ test_xml_etree / test_xml_etree_c: a str8 / io error that may be related to __file__ __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1258 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: __file__ has a wrong type str8. I'm looking into it. Yes, __file__ always has that type. Fixing it is messy because it requires using the default filesystem encoding. Can you try that as a separate patch? test_inspect: same issue as httplib test_os: same issue test_re: I had the failing test before my changes But it passes for me. File Lib/test/test_re.py, line 622, in test_empty_array ValueError: bad typecode (must be b, B, u, h, H, i, I, l, L, f or d) Hm. It passes for me. test_subprocess: I don't understand why it fails. The traceback is missing a line test_sys: related to __file__ test_xml_etree / test_xml_etree_c: a str8 / io error that may be related to __file__ Thanks for looking into these!! __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1258 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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_generator() The generator tries to print a str8 to a text file. Yes, __file__ always has that type. Fixing it is messy because it requires using the default filesystem encoding. Can you try that as a separate patch? I'm already working on it. Can I introduce a new function _PyUnicode_AsDefaultFSEncodedString that encodes unicode using Py_FileSystemDefaultEncoding or UTF-8? File Lib/test/test_re.py, line 622, in test_empty_array ValueError: bad typecode (must be b, B, u, h, H, i, I, l, L, f or d) Hm. It passes for me. I'm going to look into the issue later. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1258 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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', None, None)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: slice indices must be integers or None or have an __index__
method
'asd'.rfind('s', None, None)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: slice indices must be integers or None or have an __index__
method
# Note that this works, at the price of a memory copy,
# and on large strings that is undesirable.
'asd'[None:None].find('s')
1
'asd'[None:None].rfind('s')
1
--
messages: 56332
nosy: rbcollins
severity: normal
status: open
title: string find and rfind methods give a TypeError that is misleading
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1259
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 for None before calling _PyEval_SliceIndex. -- nosy: +barry __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1259 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 good idea. I believe that if this call is ever reached, two tracebacks will be printed, confusing the user. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1031213 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1031213 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 (Ubuntu i386) Odd. I'll investigate when I have more time. test_email: need some help from an email expoert Which test is failing? test_decoded_generator() The generator tries to print a str8 to a text file. Thought so. I have a tentative fix that I want approved by Barry Warsaw before checking; you can see if it works for you too: --- Lib/email/generator.py (revision 58412) +++ Lib/email/generator.py (working copy) @@ -288,7 +288,7 @@ for part in msg.walk(): maintype = part.get_content_maintype() if maintype == 'text': -print(part.get_payload(decode=True), file=self) +print(part.get_payload(decode=False), file=self) elif maintype == 'multipart': # Just skip this pass Yes, __file__ always has that type. Fixing it is messy because it requires using the default filesystem encoding. Can you try that as a separate patch? I'm already working on it. Can I introduce a new function _PyUnicode_AsDefaultFSEncodedString that encodes unicode using Py_FileSystemDefaultEncoding or UTF-8? That's a rather long name... I don't think it needs a leading underscore. How about PyUnicode_AsFSString()? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1258 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 --include='*.c' 'PyArg.*Parse.*[^;:]*[cwt].*' py3k/
I haven't checked these function calls yet. So, it would probably be a
good idea to wait I do so before committing this patch.
--
files: unicode_rm_buf_api.patch
messages: 56336
nosy: alexandre.vassalotti
severity: normal
status: open
title: PEP 3137: Remove the buffer API from PyUnicode
versions: Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1260
__Index: Modules/_sre.c
===
--- Modules/_sre.c (revision 58376)
+++ Modules/_sre.c (working copy)
@@ -1674,6 +1674,15 @@
void* ptr;
Py_buffer view;
+/* Unicode objects do not support the buffer API. So, get the data
+ directly instead. */
+if (PyUnicode_Check(string)) {
+ptr = (void *)PyUnicode_AS_DATA(string);
+*p_length = PyUnicode_GET_SIZE(string);
+*p_charsize = sizeof(Py_UNICODE);
+return ptr;
+}
+
/* get pointer to string buffer */
view.len = -1;
buffer = Py_Type(string)-tp_as_buffer;
Index: Objects/unicodeobject.c
===
--- Objects/unicodeobject.c (revision 58376)
+++ Objects/unicodeobject.c (working copy)
@@ -8113,19 +8113,6 @@
};
-static int
-unicode_buffer_getbuffer(PyUnicodeObject *self, Py_buffer *view, int flags)
-{
-
-if (flags PyBUF_CHARACTER) {
-PyErr_SetString(PyExc_SystemError, can't use str as char buffer);
-return -1;
-}
-return PyBuffer_FillInfo(view, (void *)self-str,
- PyUnicode_GET_DATA_SIZE(self), 1, flags);
-}
-
-
/* Helpers for PyUnicode_Format() */
static PyObject *
@@ -8819,11 +8806,6 @@
return NULL;
}
-static PyBufferProcs unicode_as_buffer = {
-(getbufferproc) unicode_buffer_getbuffer,
-NULL,
-};
-
static PyObject *
unicode_subtype_new(PyTypeObject *type, PyObject *args, PyObject *kwds);
@@ -8907,7 +8889,7 @@
(reprfunc) unicode_str, /* tp_str */
PyObject_GenericGetAttr, /* tp_getattro */
0, /* tp_setattro */
-unicode_as_buffer, /* tp_as_buffer */
+0, /* tp_as_buffer */
Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE |
Py_TPFLAGS_UNICODE_SUBCLASS, /* tp_flags */
unicode_doc, /* tp_doc */
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1258] Removal of basestring type
Changes by Martin v. Löwis: -- keywords: +patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1258 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1260] PEP 3137: Remove the buffer API from PyUnicode
Changes by Martin v. Löwis: -- keywords: +patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1260 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
