[issue1585] IDLE uses non-existent xrange() function (Py30a2)
New submission from Mark Summerfield: When I start IDLE I get this: Python 3.0a2 (r30a2:59382, Dec 10 2007, 14:21:37) [GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2 Type copyright, credits or license() for more information. Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. IDLE 3.0a1 That's fine (if slightly confusing regarding the version numbers), but if I click Options-Configure I get this error output: : Exception in Tkinter callback Traceback (most recent call last): File /home/mark/opt/python30a2/lib/python3.0/lib-tk/Tkinter.py, line 1402, in __call__ return self.func(*args) File /home/mark/opt/python30a2/lib/python3.0/idlelib/EditorWindow.py, line 385, in config_dialog configDialog.ConfigDialog(self.top,'Settings') File /home/mark/opt/python30a2/lib/python3.0/idlelib/configDialog.py, line 50, in __init__ self.CreateWidgets() File /home/mark/opt/python30a2/lib/python3.0/idlelib/configDialog.py, line 69, in CreateWidgets page_names=['Fonts/Tabs','Highlighting','Keys','General']) File /home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py, line 398, in __init__ self.add_page(name) File /home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py, line 413, in add_page self._tab_set.add_tab(page_name) File /home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py, line 76, in add_tab self._arrange_tabs() File /home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py, line 163, in _arrange_tabs for row_index in xrange(n_rows): NameError: global name 'xrange' is not defined I tried changing xrange to range, but that doesn't work: : Exception in Tkinter callback Traceback (most recent call last): File /home/mark/opt/python30a2/lib/python3.0/lib-tk/Tkinter.py, line 1402, in __call__ return self.func(*args) File /home/mark/opt/python30a2/lib/python3.0/idlelib/EditorWindow.py, line 385, in config_dialog configDialog.ConfigDialog(self.top,'Settings') File /home/mark/opt/python30a2/lib/python3.0/idlelib/configDialog.py, line 50, in __init__ self.CreateWidgets() File /home/mark/opt/python30a2/lib/python3.0/idlelib/configDialog.py, line 69, in CreateWidgets page_names=['Fonts/Tabs','Highlighting','Keys','General']) File /home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py, line 398, in __init__ self.add_page(name) File /home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py, line 413, in add_page self._tab_set.add_tab(page_name) File /home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py, line 76, in add_tab self._arrange_tabs() File /home/mark/opt/python30a2/lib/python3.0/idlelib/tabbedpages.py, line 148, in _arrange_tabs for tab_name in self._tabs.keys(): RuntimeError: dictionary changed size during iteration -- components: IDLE messages: 58417 nosy: mark severity: normal status: open title: IDLE uses non-existent xrange() function (Py30a2) type: behavior versions: Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1585 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1585] IDLE uses non-existent xrange() function (Py30a2)
Mark Summerfield added the comment: Amaury Forgeot d'Arc says he's fixed this in change 59456 (but I don't know how---or if---I can change its status). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1585 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Noam Raphael added the comment: The Tcl code can be fonund here: http://tcl.cvs.sourceforge.net/tcl/tcl/generic/tclStrToD.c?view=markup What Tim says gives another reason for using that code - it means that currently, the compilation of the same source code on two platforms can result in a code which does different things. Just to make sure - IEEE does require that operations on doubles will do the same thing on different platforms, right? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1585] IDLE uses non-existent xrange() function (Py30a2)
Christian Heimes added the comment: Fixed in r59456 -- keywords: +py3k nosy: +tiran resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1585 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1584] Mac OS X: building with X11 Tkinter
Christian Heimes added the comment: The problem is already fixed in svn. Can you download a svn checkout and verify it that the code is working? 41848 skip.montanaro if (platform == 'darwin' and -- nosy: +tiran priority: - normal resolution: - out of date status: open - pending __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1584 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Christian Heimes added the comment: It's really a shame. It was a nice idea ... Could we at least use the new formating for str(float) and the display of floats? In Python 2.6 floats are not displayed with repr(). They seem to use yet another hook. repr(11./5) '2.2' 11./5 2.2002 str(11./5) '2.2' __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1754489] Non-portable address length calculation for AF_UNIX sockets
Changes by Christian Heimes: -- assignee: - loewis nosy: +loewis _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1754489 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1586] IDLE no longer shows colour syntax highlighting in the Shell (Py30a2)
New submission from Mark Summerfield: When I do: import sys; dir(sys) everything is shown in plain black white, but in the IDLE that came with Py30a1 color syntax highlighting is used. -- components: IDLE messages: 58423 nosy: mark severity: minor status: open title: IDLE no longer shows colour syntax highlighting in the Shell (Py30a2) type: behavior versions: Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1586 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Noam Raphael added the comment: I think that for str(), the current method is better - using the new repr() method will make str(1.1*3) == '3.3003', instead of '3.3'. (The repr is right - you can check, and 1.1*3 != 3.3. But for str() purposes it's fine.) But I actually think that we should also use Tcl's decimal to binary conversion - otherwise, a .pyc file created by python compiled with Microsoft will cause a different behaviour from a .pyc file created by python compiled with Gnu, which is quite strange. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1587] instancemethod wrapper for PyCFunctions
New submission from Christian Heimes:
The patch implements the instancemethod wrapper as discussed on the py3k
mailing list. The patch is roughly based on Marcin Kowalczyk patch but
it contains more fancy slots like repr, call etc. The rest is mostly
based on PyMethod_Type.
--
components: Interpreter Core
files: py3k_instancemethod.patch
keywords: patch, py3k
messages: 58425
nosy: tiran
priority: normal
severity: normal
status: open
title: instancemethod wrapper for PyCFunctions
type: rfe
versions: Python 3.0
Added file: http://bugs.python.org/file8923/py3k_instancemethod.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1587
__Index: Python/bltinmodule.c
===
--- Python/bltinmodule.c (Revision 59464)
+++ Python/bltinmodule.c (Arbeitskopie)
@@ -1903,6 +1903,7 @@
SETBUILTIN(frozenset, PyFrozenSet_Type);
SETBUILTIN(property, PyProperty_Type);
SETBUILTIN(int, PyLong_Type);
+ SETBUILTIN(instancemethod, PyInstanceMethod_Type);
SETBUILTIN(list, PyList_Type);
SETBUILTIN(object, PyBaseObject_Type);
SETBUILTIN(range, PyRange_Type);
Index: Include/classobject.h
===
--- Include/classobject.h (Revision 59464)
+++ Include/classobject.h (Arbeitskopie)
@@ -31,6 +31,24 @@
#define PyMethod_GET_SELF(meth) \
(((PyMethodObject *)meth) - im_self)
+
+typedef struct {
+ PyObject_HEAD
+ PyObject *func;
+} PyInstanceMethodObject;
+
+PyAPI_DATA(PyTypeObject) PyInstanceMethod_Type;
+
+#define PyInstanceMethod_Check(op) ((op)-ob_type == PyInstanceMethod_Type)
+
+PyAPI_FUNC(PyObject *) PyInstanceMethod_New(PyObject *);
+PyAPI_FUNC(PyObject *) PyInstanceMethod_Function(PyObject *);
+
+/* Macros for direct access to these values. Type checks are *not*
+ done, so use with care. */
+#define PyInstanceMethod_GET_FUNCTION(meth) \
+(((PyInstanceMethodObject *)meth) - func)
+
#ifdef __cplusplus
}
#endif
Index: Objects/classobject.c
===
--- Objects/classobject.c (Revision 59464)
+++ Objects/classobject.c (Arbeitskopie)
@@ -5,7 +5,6 @@
#define TP_DESCR_GET(t) ((t)-tp_descr_get)
-
PyObject *
PyMethod_Function(PyObject *im)
{
@@ -68,12 +67,12 @@
/* im_func and im_self are stored in the PyMethod object */
-#define OFF(x) offsetof(PyMethodObject, x)
+#define MO_OFF(x) offsetof(PyMethodObject, x)
static PyMemberDef method_memberlist[] = {
- {__func__, T_OBJECT, OFF(im_func), READONLY|RESTRICTED,
+ {__func__, T_OBJECT, MO_OFF(im_func), READONLY|RESTRICTED,
the function (or other callable) implementing a method},
- {__self__, T_OBJECT, OFF(im_self), READONLY|RESTRICTED,
+ {__self__, T_OBJECT, MO_OFF(im_self), READONLY|RESTRICTED,
the instance to which a method is bound},
{NULL} /* Sentinel */
};
@@ -131,7 +130,7 @@
PyDoc_STRVAR(method_doc,
method(function, instance)\n\
\n\
-Create an instance method object.);
+Create a bound instance method object.);
static PyObject *
method_new(PyTypeObject* type, PyObject* args, PyObject *kw)
@@ -139,7 +138,7 @@
PyObject *func;
PyObject *self;
- if (!_PyArg_NoKeywords(instancemethod, kw))
+ if (!_PyArg_NoKeywords(method, kw))
return NULL;
if (!PyArg_UnpackTuple(args, method, 2, 2,
func, self))
@@ -351,7 +350,7 @@
(traverseproc)method_traverse, /* tp_traverse */
0, /* tp_clear */
method_richcompare, /* tp_richcompare */
- offsetof(PyMethodObject, im_weakreflist), /* tp_weaklistoffset */
+ offsetof(PyMethodObject, im_weakreflist), /* tp_weaklistoffset */
0, /* tp_iter */
0, /* tp_iternext */
0, /* tp_methods */
@@ -378,3 +377,243 @@
PyObject_GC_Del(im);
}
}
+
+/*
+ * instance method
+ */
+
+PyObject *
+PyInstanceMethod_New(PyObject *func) {
+ PyInstanceMethodObject *method;
+ method = PyObject_GC_New(PyInstanceMethodObject,
+ PyInstanceMethod_Type);
+ if (method == NULL) return NULL;
+ Py_INCREF(func);
+ method-func = func;
+ _PyObject_GC_TRACK(method);
+ return (PyObject *)method;
+}
+
+PyObject *
+PyInstanceMethod_Function(PyObject *im)
+{
+ if (!PyInstanceMethod_Check(im)) {
+ PyErr_BadInternalCall();
+ return NULL;
+ }
+ return PyInstanceMethod_GET_FUNCTION(im);
+}
+
+#define IMO_OFF(x) offsetof(PyInstanceMethodObject, x)
+
+static PyMemberDef instancemethod_memberlist[] = {
+ {__func__, T_OBJECT, IMO_OFF(func), READONLY|RESTRICTED,
+ the function (or other callable) implementing a method},
+ {NULL} /* Sentinel */
+};
+
+static PyObject *
+instancemethod_get_doc(PyObject *self, void *context)
+{
+ static PyObject *docstr;
+ if (docstr == NULL) {
+ docstr = PyUnicode_InternFromString(__doc__);
+ if (docstr == NULL)
+ return NULL;
+ }
+ return PyObject_GetAttr(PyInstanceMethod_GET_FUNCTION(self), docstr);
+}
+
+static PyGetSetDef
[issue1581] xmlrpclib.ServerProxy() doesn't use x509 data
Andreas Hasenack added the comment:
The only difference between xmlrpclib.py from trunk and 2.5.1 is in the
Marshaller class. Unrelated, as far as I can see.
Note that it seems that the intent of the original code was to support
this x509-dict all along:
$ grep -n x509 xmlrpclib.py.trunk
1224:# Host may be a string, or a (host, x509-dict) tuple; if a string,
1228:# @param host Host descriptor (URL or (URL, x509 info) tuple).
1230:# x509 info). The header and x509 fields may be None.
1234:x509 = {}
1236:host, x509 = host
1251:return host, extra_headers, x509
1262:host, extra_headers, x509 = self.get_host_info(host)
1282:host, extra_headers, x509 = self.get_host_info(host)
1362:# host may be a string, or a (host, x509-dict) tuple
1364:host, extra_headers, x509 = self.get_host_info(host)
1372:return HTTPS(host, None, **(x509 or {}))
Basically just the ServerProxy constructor doesn't support it. One would
have to create a new class with a new constructor just because of it.
That's why I opened this ticket.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1581
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1586] IDLE no longer shows colour syntax highlighting in the Shell (Py30a2)
Changes by Christian Heimes: -- keywords: +py3k priority: - normal __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1586 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Noam Raphael added the comment: If I think about it some more, why not get rid of all the float platform-dependencies and define how +inf, -inf and nan behave? I think that it means: * inf and -inf are legitimate floats just like any other float. Perhaps there should be a builtin Inf, or at least math.inf. * nan is an object of type float, which behaves like None, that is: nan == nan is true, but nan nan and nan 3 will raise an exception. Mathematical operations which used to return nan will raise an exception (division by zero does this already, but inf + -inf will do that too, instead of returning nan.) Again, there should be a builtin NaN, or math.nan. The reason for having a special nan object is compatibility with IEEE floats - I want to be able to pass around IEEE floats easily even if they happen to be nan. This is basically what Tcl did, if I understand correctly - see item 6 in http://www.tcl.tk/cgi-bin/tct/tip/132.html . __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1588] str.format() wrongly formats complex() numbers (Py30a2)
New submission from Mark Summerfield:
x = complex(1, 2/3)
{0} {0:.5}.format(x)
'(1+0.6667j) (1+0.'
The complex number is being formatted as if it were a string and simply
truncated to 5 characters. I would expect each part of the complex
number to be formatted according to the format specifier, i.e., in the
case of :.5 to both have 5 digits after the decimal point.
--
components: Interpreter Core
messages: 58428
nosy: mark
severity: normal
status: open
title: str.format() wrongly formats complex() numbers (Py30a2)
type: behavior
versions: Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1588
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Noam Raphael added the comment: That's right, but the standard also defines that 0.0/0 - nan, and 1.0/0 - inf, but instead we raise an exception. It's just that in Python, every object is expected to be equal to itself. Otherwise, how can I check if a number is nan? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Christian Heimes added the comment: Noam Raphael wrote: * nan is an object of type float, which behaves like None, that is: nan == nan is true, but nan nan and nan 3 will raise an exception. No, that's not correct. The standard defines that nan is always unequal to nan. False float(inf) == float(inf) True float(inf) == -1*float(-inf) True The float module could gain three singletons nan, inf an neginf so you can do True Christian __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1577] shutil.move() does not use os.rename() if dst is a directory
Raghuram Devarakonda added the comment: Since we already have os.rename, wouldn't it be better for shutil.move() to be closer to command line 'mv'? I think Facundo's approach should work. -- nosy: +draghuram __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1577 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Christian Heimes added the comment:
I propose that we add three singletons to the float implementation:
PyFloat_NaN
PyFloat_Inf
PyFloat_NegInf
The singletons are returned from PyFloat_FromString() for nan, inf
and -inf. The other PyFloat_ method must return the singletons, too.
It's easy to check the signum, special and nan/inf status of an IEEE
double with a struct.
I've already started to work on a way to create nan, inf and -inf cross
platform conform. Right now float(nan), float(inf) and float(-inf)
works on Linux but doesn't work on Windows. We could also add four
methods to math:
signum(float) - 1/-1, finity(float) - bool, infinite(float), nan(float)
Here is my work in progress:
#define Py_IEEE_DBL *(double*)(ieee_double)
#if defined(LITTLE_ENDIAN_IEEE_DOUBLE) !defined(BIG_ENDIAN_IEEE_DOUBLE)
typedef struct {
unsigned intm4 : 16;
unsigned intm3 : 16;
unsigned intm2 : 16;
unsigned intm1 : 4;
unsigned int exp : 11;
unsigned int sign : 1;
} ieee_double;
#define Py_IEEE_NAN Py_IEEE_DBL{0x, 0x, 0x, 0xf, 0x7ff, 0}
#define Py_IEEE_INF Py_IEEE_DBL{0, 0, 0, 0, 0x7ff, 0}
#define Py_IEEE_NEGINF Py_IEEE_DBL{0, 0, 0, 0, 0x7ff, 1}
#elif !defined(LITTLE_ENDIAN_IEEE_DOUBLE) defined(BIG_ENDIAN_IEEE_DOUBLE)
typedef struct {
unsigned int sign : 1;
unsigned int exp : 11;
unsigned intm1 : 4;
unsigned intm2 : 16;
unsigned intm3 : 16;
unsigned intm4 : 16;
} ieee_double;
#define Py_IEEE_NAN Py_IEEE_DBL{0, 0x7ff, 0xf, 0x, 0x, 0x}
#define Py_IEEE_INF Py_IEEE_DBL{0, 0x7ff, 0, 0, 0, 0}
#define Py_IEEE_NEGINF Py_IEEE_DBL{1, 0x7ff, 0, 0, 0, 0}
#else
#error Unknown or no IEEE double implementation
#endif
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1580
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Guido van Rossum added the comment: (1) Despite Tim's grave language, I don't think we'll need to write our own correctly-rounding float input routine. We can just say that Python won't work correctly unless your float input routine is rounding correctly; a unittest should detect whether this is the case. I expect that more recent C runtimes for Windows are correct. (1a) Perhaps it's better to only do this for Python 3.0, which has a smaller set of platforms to support. (2) Have you two (Christian and Noam) figured out yet why repr(1e5) is '1.0' on some platforms? If it's not byte order (and I no longer believe it is) what could it be? An uninitialized variable? It doesn't seem to vary with the processor, but it could vary with the C runtime or OS. (3) Detecting NaNs and infs in a platform-independent way is tricky, probably beyond you (I know it's beyond me). (Of course, producing standardized output for them and recognizing these as input is easy, and that should definitely be done.) (4) Looks like we've been a bit too hasty checking this in. Let's be extra careful for round #2. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1589] New SSL module doesn't seem to verify hostname against commonName in certificate
New submission from Andreas Hasenack:
(I hope I used the correct component for this report)
http://pypi.python.org/pypi/ssl/
I used the client example shown at
http://docs.python.org/dev/library/ssl.html#client-side-operation to
connect to a bank site called www.realsecureweb.com.br at
200.208.16.101. Its certificate signed by verisign. My OpenSSL has this
CA at /etc/pki/tls/rootcerts/verisign-inc-class-3-public-primary.pem.
The verification works.
If I make up a hostname called something else, like wwws, and place it
in /etc/hosts pointing to that IP address, the SSL connection should not
be established because that name doesn't match the common name field in
the server certificate. But the SSL module happily connects to it
(excerpt below):
cert = verisign-inc-class-3-public-primary.pem
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
ssl_sock = ssl.wrap_socket(s,
ca_certs=/etc/pki/tls/rootcerts/%s % cert,
cert_reqs=ssl.CERT_REQUIRED)
ssl_sock.connect(('wwws', 443))
print repr(ssl_sock.getpeername())
output:
('200.208.16.101', 443)
('RC4-MD5', 'TLSv1/SSLv3', 128)
{'notAfter': 'Sep 10 23:59:59 2008 GMT',
'subject': ((('countryName', u'BR'),),
(('stateOrProvinceName', u'Sao Paulo'),),
(('localityName', u'Sao Paulo'),),
(('organizationName', u'Banco ABN AMRO Real SA'),),
(('organizationalUnitName', u'TI Internet PF e PJ'),),
(('commonName', u'www.realsecureweb.com.br'),))}
If I now open, say, a firefox window and point it to https://wwws;, it
gives me the expected warning that the hostname doesn't match the
certificate.
I'll attach the verisign CA certificate to make it easier to reproduce
the error.
--
components: Library (Lib)
files: verisign-inc-class-3-public-primary.pem
messages: 58434
nosy: ahasenack
severity: normal
status: open
title: New SSL module doesn't seem to verify hostname against commonName in
certificate
type: security
versions: Python 2.6
Added file:
http://bugs.python.org/file8924/verisign-inc-class-3-public-primary.pem
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1589
__
verisign-inc-class-3-public-primary.pem
Description: application/x509-ca-cert
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1589] New SSL module doesn't seem to verify hostname against commonName in certificate
Andreas Hasenack added the comment: Ups, typo in the script: cert = verisign-inc-class-3-public-primary.pem __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1589 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1590] make altinstall installs pydoc, idle, smtpd.py
New submission from David Ripton: Python 3.0a2, Gentoo Linux, x86 make altinstall installs idle, pydoc, and smtpd.py This can partially break the previous Python install, which is counter to the idea of altinstall being safe to use in parallel with an existing install of a different version of Python. IMO altinstall should install no files that lack a version number somewhere in their path. I suggest having altinstall simply not install pydoc, idle, and smtpd.py. -- components: Build messages: 58437 nosy: dripton severity: minor status: open title: make altinstall installs pydoc, idle, smtpd.py type: behavior versions: Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1590 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Christian Heimes added the comment: Guido van Rossum wrote: (1a) Perhaps it's better to only do this for Python 3.0, which has a smaller set of platforms to support. +1 Does Python depend on a working, valid and non-broken IEEE 754 floating point arithmetic? Could we state the Python's float type depends on IEEE754-1985 conform 64bit double precision format. Developers for a platform with no IEEE754 conform double must role their own floatobject implementation. (2) Have you two (Christian and Noam) figured out yet why repr(1e5) is '1.0' on some platforms? If it's not byte order (and I no longer believe it is) what could it be? An uninitialized variable? It doesn't seem to vary with the processor, but it could vary with the C runtime or OS. I wasn't able to reproduce the problem on my work stations. Can you give us more information about the computer with failing tests? CPU, OS, Kernel, libc etc. (3) Detecting NaNs and infs in a platform-independent way is tricky, probably beyond you (I know it's beyond me). (Of course, producing standardized output for them and recognizing these as input is easy, and that should definitely be done.) In fact detecting NaNs and Infs is platform-independent is dead easy IFF the platform has IEEE 754 support. A double uses 64bit to store the data, 1 bit signum, 11 bit exponent and 53bit fraction part (aka mantissa). When all bits of the exponent are set (0x7ff) the number is either a NaN or +/-Inf. For Infs the fraction part has no bits set (0) and the signum bit signals +Inf (sig: 0) or -Inf (sig: 1). If one to all bits of the mantissa is set, it's a NaN. The form (normalized or denormalized) is regardless for the detection of NaN and Inf. An autoconf macro can easily detect the endianness of the double implementation. We can also use the much slower version and check if x DBL_MAX for +Inf, x -DBL_MAX for -Inf and x != x for NaN. Christian __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1583] Patch for signal.set_wakeup_fd
Georg Brandl added the comment: ``'\0'`` will be correct. -- nosy: +georg.brandl __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1583 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1584] Mac OS X: building with X11 Tkinter
Georg Brandl added the comment: Crys: look closely at the diff, the 0 and is in the modified file. -- nosy: +georg.brandl __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1584 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1577] shutil.move() does not use os.rename() if dst is a directory
Guido van Rossum added the comment: Since we already have os.rename, wouldn't it be better for shutil.move() to be closer to command line 'mv'? I think Facundo's approach should work. I'd rather not do this. It might cause disasters for code that expects the old semantics. If you want a way to do the mv semantics, propose a new API. shutil.move() still offers several things over os.rename(): deleting the target even if os.rename() doesn't (it doesn't on Windows); cross-filesystem moves implemented as copy. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1577 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1583] Patch for signal.set_wakeup_fd
Adam Olsen added the comment:
Thanks georg.
Added file: http://bugs.python.org/file8925/python2.6-set_wakeup_fd3.diff
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1583
__Index: Doc/library/signal.rst
===
--- Doc/library/signal.rst (revision 59455)
+++ Doc/library/signal.rst (working copy)
@@ -110,6 +110,20 @@
:manpage:`signal(2)`.)
+.. function:: set_wakeup_fd(fd)
+
+ Set the wakeup fd to *fd*. When a signal is received, a ``'\0'`` byte is
+ written to the fd. This can be used by a library to wakeup a poll or select
+ call, allowing the signal to be fully processed.
+
+ The old wakeup fd is returned. *fd* must be non-blocking. It is up to the
+ library to remove any bytes before calling poll or select again.
+
+ When threads are enabled, this function can only be called from the main thread;
+ attempting to call it from other threads will cause a :exc:`ValueError`
+ exception to be raised.
+
+
.. function:: signal(signalnum, handler)
Set the handler for signal *signalnum* to the function *handler*. *handler* can
Index: Lib/test/test_signal.py
===
--- Lib/test/test_signal.py (revision 59455)
+++ Lib/test/test_signal.py (working copy)
@@ -165,12 +165,59 @@
self.assertRaises(TypeError, signal.signal,
signal.SIGUSR1, None)
+class WakeupSignalTests(unittest.TestCase):
+TIMEOUT_FULL = 10
+TIMEOUT_HALF = 5
+
+def test_wakeup_fd_early(self):
+import select
+
+signal.alarm(1)
+before_time = time.time()
+# We attempt to get a signal during the sleep,
+# before select is called
+time.sleep(self.TIMEOUT_FULL)
+mid_time = time.time()
+self.assert_(mid_time - before_time self.TIMEOUT_HALF)
+select.select([self.read], [], [], self.TIMEOUT_FULL)
+after_time = time.time()
+self.assert_(after_time - mid_time self.TIMEOUT_HALF)
+
+def test_wakeup_fd_during(self):
+import select
+
+signal.alarm(1)
+before_time = time.time()
+# We attempt to get a signal during the select call
+self.assertRaises(select.error, select.select,
+[self.read], [], [], self.TIMEOUT_FULL)
+after_time = time.time()
+self.assert_(after_time - before_time self.TIMEOUT_HALF)
+
+def setUp(self):
+import fcntl
+
+self.alrm = signal.signal(signal.SIGALRM, lambda x,y:None)
+self.read, self.write = os.pipe()
+flags = fcntl.fcntl(self.write, fcntl.F_GETFL, 0)
+flags = flags | os.O_NONBLOCK
+fcntl.fcntl(self.write, fcntl.F_SETFL, flags)
+self.old_wakeup = signal.set_wakeup_fd(self.write)
+
+def tearDown(self):
+signal.set_wakeup_fd(self.old_wakeup)
+os.close(self.read)
+os.close(self.write)
+signal.signal(signal.SIGALRM, self.alrm)
+
+
def test_main():
if sys.platform[:3] in ('win', 'os2') or sys.platform == 'riscos':
raise test_support.TestSkipped(Can't test signal on %s % \
sys.platform)
-test_support.run_unittest(BasicSignalTests, InterProcessSignalTests)
+test_support.run_unittest(BasicSignalTests, InterProcessSignalTests,
+WakeupSignalTests)
if __name__ == __main__:
Index: Modules/signalmodule.c
===
--- Modules/signalmodule.c (revision 59455)
+++ Modules/signalmodule.c (working copy)
@@ -12,6 +12,8 @@
#include signal.h
+#include sys/stat.h
+
#ifndef SIG_ERR
#define SIG_ERR ((PyOS_sighandler_t)(-1))
#endif
@@ -75,6 +77,8 @@
PyObject *func;
} Handlers[NSIG];
+static sig_atomic_t wakeup_fd = -1;
+
static int is_tripped = 0; /* Speed up sigcheck() when none tripped */
static PyObject *DefaultHandler;
@@ -112,6 +116,7 @@
static void
signal_handler(int sig_num)
{
+ const char dummy_byte = '\0';
#ifdef WITH_THREAD
#ifdef WITH_PTH
if (PyThread_get_thread_ident() != main_thread) {
@@ -125,6 +130,8 @@
is_tripped++;
Handlers[sig_num].tripped = 1;
Py_AddPendingCall(checksignals_witharg, NULL);
+ if (wakeup_fd != -1)
+ write(wakeup_fd, dummy_byte, 1);
#ifdef WITH_THREAD
}
#endif
@@ -264,6 +271,39 @@
anything else -- the callable Python object used as a handler);
+static PyObject *
+signal_set_wakeup_fd(PyObject *self, PyObject *args)
+{
+ struct stat buf;
+ int fd, old_fd;
+ if (!PyArg_ParseTuple(args, i:set_wakeup_fd, fd))
+ return NULL;
+#ifdef WITH_THREAD
+ if (PyThread_get_thread_ident() != main_thread) {
+ PyErr_SetString(PyExc_ValueError,
+set_wakeup_fd only works in main thread);
+ return NULL;
+ }
+#endif
+ if (fd != -1 fstat(fd, buf) != 0) {
+ PyErr_SetString(PyExc_ValueError, invalid fd);
+ return NULL;
+ }
+ old_fd
[issue1580] Use shorter float repr when possible
Guido van Rossum added the comment: (1a) Perhaps it's better to only do this for Python 3.0, which has a smaller set of platforms to support. +1 Does Python depend on a working, valid and non-broken IEEE 754 floating point arithmetic? Could we state the Python's float type depends on IEEE754-1985 conform 64bit double precision format. Developers for a platform with no IEEE754 conform double must role their own floatobject implementation. No, traditionally Python has just used whatever C's double provides. There are some places that benefit from IEEE 754, but few that require it (dunno about optional extension modules). (2) Have you two (Christian and Noam) figured out yet why repr(1e5) is '1.0' on some platforms? If it's not byte order (and I no longer believe it is) what could it be? An uninitialized variable? It doesn't seem to vary with the processor, but it could vary with the C runtime or OS. I wasn't able to reproduce the problem on my work stations. Can you give us more information about the computer with failing tests? CPU, OS, Kernel, libc etc. So far I have only one box where it is broken (even after make clobber and ./configure). I cannot reproduce it with a debug build. It's an x86 Linux box running in mixed 64-32 bit mode. From /etc/lsb-release: Ubuntu 6.06 LTS uname -a: Linux pythonic.corp.google.com 2.6.18.5-gg16-mixed64-32 #1 SMP Wed Oct 10 17:45:08 PDT 2007 x86_64 GNU/Linux gcc -v: gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5) I'm afraid I'll have to debug this myself, but not today. (3) Detecting NaNs and infs in a platform-independent way is tricky, probably beyond you (I know it's beyond me). (Of course, producing standardized output for them and recognizing these as input is easy, and that should definitely be done.) In fact detecting NaNs and Infs is platform-independent is dead easy IFF the platform has IEEE 754 support. A double uses 64bit to store the data, 1 bit signum, 11 bit exponent and 53bit fraction part (aka mantissa). When all bits of the exponent are set (0x7ff) the number is either a NaN or +/-Inf. For Infs the fraction part has no bits set (0) and the signum bit signals +Inf (sig: 0) or -Inf (sig: 1). If one to all bits of the mantissa is set, it's a NaN. The form (normalized or denormalized) is regardless for the detection of NaN and Inf. An autoconf macro can easily detect the endianness of the double implementation. Only for IEEE 754 though. We can also use the much slower version and check if x DBL_MAX for +Inf, x -DBL_MAX for -Inf and x != x for NaN. Of course the latter isn't guaranteed to help for non-IEEE-754 platforms -- some platforms don't have NaNs at all! __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1589] New SSL module doesn't seem to verify hostname against commonName in certificate
Guido van Rossum added the comment: Bill, can you respond? -- assignee: - janssen nosy: +gvanrossum, janssen __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1589 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Raymond Hettinger added the comment: Of course the latter isn't guaranteed to help for non-IEEE-754 platforms -- some platforms don't have NaNs at all! ISTM, that years of toying with Infs and Nans has not yielded a portable, workable solution. I'm concerned that further efforts will contort and slow-down our code without benefit. NaNs in particular are a really difficult case because our equality testing routines have a fast path where identity implies equality. I don't think NaNs can be correctly implemented without breaking that fast path which appears throughout the code base (even inside the code for dictobject.c; otherwise, how could you lookup a NaN value). I recommend punting on the subject of NaNs. Attempting to fix it will necessarily entail introducing a number of little atrocities that just aren't worth it. IMO, Practicality beats purity on this one. The decimal module provides full support for NaNs. While it is slow, it may be sufficient for someone who isn't happy with the way float handles them. -- nosy: +rhettinger __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1587] instancemethod wrapper for PyCFunctions
Guido van Rossum added the comment: I'm tempted to call YAGNI on this. -- nosy: +gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1587 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1588] str.format() wrongly formats complex() numbers (Py30a2)
Guido van Rossum added the comment:
This really is a feature request -- in Python 2.x there is no formatting
code for complex numbers at all, and %.5s % complex(...) does the same
thing.
I agree it would be neat to have control over complex numbers using the
same formatting language used for floats; but I note that it's easy
enough to do this manually, e.g.
{0.real:.5}+{0.imag:.5}j.format(z)
'1+0.7j'
--
nosy: +gvanrossum
priority: - low
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1588
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1588] str.format() wrongly formats complex() numbers (Py30a2)
Guido van Rossum added the comment: Maybe this would be a good GHOP task? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1588 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Tim Peters added the comment: [Raymond] ... NaNs in particular are a really difficult case because our equality testing routines have a fast path where identity implies equality. Works as intended in 2.5; this is Windows output: 1.#INF nan = inf - inf nan # really is a NaN -1.#IND nan is nan # of course this is true True nan == nan # but not equal anyway False __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Tim Peters added the comment: [Guido] ... We can just say that Python won't work correctly unless your float input routine is rounding correctly; a unittest should detect whether this is the case. Sorry, but that's intractable. Correct rounding is a property that needs to be proved, not tested. Processors aren't fast enough to test all (roughly) 2**64 possible doubles in reasonable time, and there's only one way to get all of them right (correct rounding). There are many ways to get at least one of them wrong, and short of proof only exhaustive testing can determine whether at least one is wrong. There is no smoking gun specific test case, either -- different flawed routines will fail on different inputs. I expect that more recent C runtimes for Windows are correct. Based on what? Unless MS says so somewhere, it's very hard to know. Vern Paxson and David Hough developed a test program in the early 90's, based on an excruciatingly difficult algorithm I invented for finding hard cases, and the code they wrote still appears to be available from the places Vern mentions in this brief msg: http://www.netlib.org/fp/testbase That code doesn't guarantee to find a failing correct-rounding case if one exists, but did find failures reasonably efficiently on many platforms tested at the time. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1592] operations on closed shelves fail cryptically
New submission from Erno Kuusela: shelve objects set self.dict = 0 in their close() method. this results in errors such as TypeError: unsubscriptable object and AttributeError: 'int' object has no attribute 'has_key'. This is fairly baffling for the user. self.dict = 0 in close() is present in current svn trunk too. -- components: Library (Lib) messages: 58453 nosy: erno severity: normal status: open title: operations on closed shelves fail cryptically type: behavior versions: Python 2.4 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1592 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Christian Heimes added the comment: Guido van Rossum wrote: No, traditionally Python has just used whatever C's double provides. There are some places that benefit from IEEE 754, but few that require it (dunno about optional extension modules). I asked Thomas Wouter about IEEE 754: I don't know of any system with FPU that does not support 754 semantics. and all intel CPUs since the 486 have FPUs. During the discussion we found only one system that has supported Python in the past but doesn't have IEEE 754 doubles. Pippy (Python for PalmOS) has no floats at all since the hardware doesn't haven a FPU. So far I have only one box where it is broken (even after make clobber and ./configure). I cannot reproduce it with a debug build. It's an x86 Linux box running in mixed 64-32 bit mode. From /etc/lsb-release: Ubuntu 6.06 LTS uname -a: Linux pythonic.corp.google.com 2.6.18.5-gg16-mixed64-32 #1 SMP Wed Oct 10 17:45:08 PDT 2007 x86_64 GNU/Linux gcc -v: gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5) I'm afraid I'll have to debug this myself, but not today. The problem could either be related to SMP or to the mixed mode. Please try to bind the Python process to one CPU with schedtool or schedutils. Only for IEEE 754 though. Of course the latter isn't guaranteed to help for non-IEEE-754 platforms -- some platforms don't have NaNs at all! Do you know of any system that supports Python and floats but doesn't have IEEE 753 semantics? I'm asking out of curiosity. Christian __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1587] instancemethod wrapper for PyCFunctions
Christian Heimes added the comment: The wrapper is useful for C code which used PyMethod_New(func, NULL, type) in 2.5. W/o a wrapper people may have to rewrite and redesign their code base. For example see http://bugs.python.org/issue1505 and r59215. I had to rewrite a good bunch of code just to get one C function right. I'm +1 to add a wrapper and +0 to expose it to Python code and -0 to expose it as built-in. I used a built-in for quick testing. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1587 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Guido van Rossum added the comment: Do you know of any system that supports Python and floats but doesn't have IEEE 753 semantics? (Assuming you meant 754.) I'm pretty sure the VAX doesn't have IEEE FP, and it used to run Unix and Python. Ditto for Crays -- unsure if we still support that though. What about Nokia S60? Tim probably knows more. -- priority: high - normal __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Guido van Rossum added the comment: Correct rounding is a property that needs to be proved, not tested. I take it your position is that this can never be done 100% correctly so it shouldn't go in? That's disappointing, because the stream of complaints that round is broken won't stop (we had two of these in the bug tracker just this month). I really want to address this without having to either change interactive mode to use something besides repr() or changing repr() to drop precision (assuming correctly rounding input). We can fix the roundtripping in marshal and pickle and the like by explicitly using %.17g % x instead of repr(x). Scientists who worry about roundtripping can also do this (though are there any scientists who work on platforms that don't have correctly-rounding input routines?). We can also fix it by adopting the Tcl string-to-float code. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1587] instancemethod wrapper for PyCFunctions
Guido van Rossum added the comment: OK, you've convinced me. Let's just make it a C API for now. On Dec 11, 2007 10:56 AM, Christian Heimes [EMAIL PROTECTED] wrote: Christian Heimes added the comment: The wrapper is useful for C code which used PyMethod_New(func, NULL, type) in 2.5. W/o a wrapper people may have to rewrite and redesign their code base. For example see http://bugs.python.org/issue1505 and r59215. I had to rewrite a good bunch of code just to get one C function right. I'm +1 to add a wrapper and +0 to expose it to Python code and -0 to expose it as built-in. I used a built-in for quick testing. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1587 __ __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1587 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1593] spacing of the builtin_format function is inconsistent
New submission from Joseph Armbruster:
URL: http://svn.python.org/projects/python/branches/py3k
Revision: 59467
The spacing of the builtin_format function did not appear to be
consistent with the rest of the .c file.
See attached patch
--
components: Interpreter Core
files: bltinmodule.patch
messages: 58459
nosy: JosephArmbruster
severity: normal
status: open
title: spacing of the builtin_format function is inconsistent
versions: Python 3.0
Added file: http://bugs.python.org/file8927/bltinmodule.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1593
__Index: bltinmodule.c
===
--- bltinmodule.c (revision 59467)
+++ bltinmodule.c (working copy)
@@ -284,58 +284,58 @@
static PyObject *
builtin_format(PyObject *self, PyObject *args)
{
-static PyObject * format_str = NULL;
-PyObject *value;
-PyObject *spec = NULL;
-PyObject *meth;
-PyObject *empty = NULL;
-PyObject *result = NULL;
+static PyObject * format_str = NULL;
+PyObject *value;
+PyObject *spec = NULL;
+PyObject *meth;
+PyObject *empty = NULL;
+PyObject *result = NULL;
-/* Initialize cached value */
-if (format_str == NULL) {
-/* Initialize static variable needed by _PyType_Lookup */
-format_str = PyUnicode_FromString(__format__);
-if (format_str == NULL)
-goto done;
-}
+/* Initialize cached value */
+if (format_str == NULL) {
+/* Initialize static variable needed by _PyType_Lookup */
+format_str = PyUnicode_FromString(__format__);
+if (format_str == NULL)
+goto done;
+}
-if (!PyArg_ParseTuple(args, O|U:format, value, spec))
- goto done;
+if (!PyArg_ParseTuple(args, O|U:format, value, spec))
+goto done;
-/* initialize the default value */
-if (spec == NULL) {
-empty = PyUnicode_FromUnicode(NULL, 0);
-spec = empty;
-}
+/* initialize the default value */
+if (spec == NULL) {
+empty = PyUnicode_FromUnicode(NULL, 0);
+spec = empty;
+}
-/* Make sure the type is initialized. float gets initialized late */
-if (Py_Type(value)-tp_dict == NULL)
-if (PyType_Ready(Py_Type(value)) 0)
-goto done;
+/* Make sure the type is initialized. float gets initialized late */
+if (Py_Type(value)-tp_dict == NULL)
+if (PyType_Ready(Py_Type(value)) 0)
+goto done;
-/* Find the (unbound!) __format__ method (a borrowed reference) */
-meth = _PyType_Lookup(Py_Type(value), format_str);
-if (meth == NULL) {
-PyErr_Format(PyExc_TypeError,
- Type %.100s doesn't define __format__,
- Py_Type(value)-tp_name);
-goto done;
-}
+/* Find the (unbound!) __format__ method (a borrowed reference) */
+meth = _PyType_Lookup(Py_Type(value), format_str);
+if (meth == NULL) {
+PyErr_Format(PyExc_TypeError,
+Type %.100s doesn't define __format__,
+Py_Type(value)-tp_name);
+goto done;
+}
-/* And call it, binding it to the value */
-result = PyObject_CallFunctionObjArgs(meth, value, spec, NULL);
+/* And call it, binding it to the value */
+result = PyObject_CallFunctionObjArgs(meth, value, spec, NULL);
-if (result !PyUnicode_Check(result)) {
-PyErr_SetString(PyExc_TypeError,
-__format__ method did not return string);
-Py_DECREF(result);
-result = NULL;
-goto done;
-}
+if (result !PyUnicode_Check(result)) {
+PyErr_SetString(PyExc_TypeError,
+__format__ method did not return string);
+Py_DECREF(result);
+result = NULL;
+goto done;
+}
done:
-Py_XDECREF(empty);
-return result;
+Py_XDECREF(empty);
+return result;
}
PyDoc_STRVAR(format_doc,
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1612746] Enhanced tabbed pane widget
Kurt B. Kaiser added the comment: r59468 Thanks for the update! -- status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1612746 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1587] instancemethod wrapper for PyCFunctions
Christian Heimes added the comment: Applied in r59469 The PyInstanceMethod_Type is not exposed to Python programs. -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1587 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1590] make altinstall installs pydoc, idle, smtpd.py
Christian Heimes added the comment: Yes, 2.5 and 2.6 are affected, too. The scripts are install by setup.py in sharedinstall. -- nosy: +tiran priority: - normal versions: +Python 2.5, Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1590 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1594] MacOS.GetCreatorAndType() and SetCreatorAndType() broken on intel
New submission from Just van Rossum: On intel, MacOS.GetCreatorAndType() returns the creator and type code with the wrong endianness, eg. as 'DCBA' instead of 'ABCD'. -- components: Macintosh messages: 58464 nosy: jvr priority: normal severity: normal status: open title: MacOS.GetCreatorAndType() and SetCreatorAndType() broken on intel type: behavior versions: Python 2.4, Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1594 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1593] spacing of the builtin_format function is inconsistent
Christian Heimes added the comment: Applied in r59470 Thanks for noticing the issue :) -- keywords: +patch, py3k nosy: +tiran priority: - normal resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1593 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Tim Peters added the comment:
[Guido]
I take it your position is that this can never be done 100% correctly
No. David Gay's code is believed to be 100% correctly-rounded and is
also reasonably fast in most cases. I don't know of any other open
string-float code that achieves both ( expect that's why glibc
adopted Gay's code as its base). I don't know anything about Tcl's
code here, except that, unlike Gay's code, it appears that Tcl's code
also tries to cater to non-754 platforms. It's also easy to be 100%
correct if you don't care about speed (but that's factors of 1000s
slower than Gay's code).
If you care about guaranteeing eval(repr(x)) == x for binary floats,
sorry, there's no way to do it that satisfies all of {cheap, easy,
fast, correct}. If you don't care about guaranteeing eval(repr(x)) ==
x, then it's dead easy to do any number of wrong things instead.
For example, much easier and faster than anything discussed here would
be to use the float str() implementation instead. Produce the
shortest possible output that reproduces the same input is a
genuinely difficult task (for both output and input) when speed
matters, but it's not really what people are asking for when they see
0.10001. They would be just as happy with str(x)'s output
instead: it's not people who know a lot about floats who are asking
to begin with, it's people who don't know much at all.
It's not a coincidence that the whole idea of shortest possible
output came from the Scheme world ;-) That is, formally correct at
any price.
so it shouldn't go in?
What shouldn't go in is something that doesn't solve the problem,
whatever that's thought to be today. Changing repr() to do
shortest-possible output is not, by itself, a solution /if/ the
problem is thought to be getting rid of lots of zeroes or nines while
preserving eval(repr(x)) == x. Slows things down yet isn't enough to
guarantee eval(repr(x)) == x. This is just going in circles.
That's disappointing, because the stream of complaints that round is broken
won't stop (we
had two of these in the bug tracker just this month).
I don't care about complaints from people who use binary floating
point without understanding it; they should use the decimal module
instead if they're unwilling or unable to learn. Or give up on
eval(repr(x)) == x for binary floats and then it's all much easier --
although people using binary floats naively will get burned by
something subtler then.
A sufficient response to round() is broken complaints is to point to
the Tutorial appendix that specifically discusses round() is broken
complaints.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1580
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Guido van Rossum added the comment: I'd be willing to require eval(repr(x)) == x only for platforms whose float input routine is correctly rounding. That would make the current patch acceptable I believe -- but I believe you think there's a better way in that case too? What way is that? Also, I'd rather not lock out non-IEEE-754 platforms, but I'm OK with dropping the above roundtripping invariant there. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1595] Probable extra semicolon in Py_LeaveRecursiveCall macro
New submission from Amaury Forgeot d'Arc:
In file ceval.h, the macro Py_LeaveRecursiveCall is defined like this:
#define Py_LeaveRecursiveCall() \
do{ if((--PyThreadState_GET()-recursion_depth)\
_Py_CheckRecursionLimit - 50); \
PyThreadState_GET()-overflowed = 0; \
} while(0)
The semicolon on the third line seems very suspicious to me: the if()
statement has no side effect, and overflowed is always reset to zero.
I don't really understand the consequences, though. The variable seems
to be used as an additional protection against C code that does not
correctly unwind when the recursion limit is hit.
--
assignee: loewis
components: Interpreter Core
keywords: py3k
messages: 58468
nosy: amaury.forgeotdarc, loewis
severity: normal
status: open
title: Probable extra semicolon in Py_LeaveRecursiveCall macro
versions: Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1595
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1596] Broken pipes should be handled better in 2.x
New submission from Alexandre Vassalotti: I think Python 2.x should mimic, or improve on, the behavior of Py3k for handling broken pipes. That is: 1. Don't print the message close failed: [Errno 32] Broken pipe, from filemodule.c; since this is impossible to override from Python. 2. Check sys.stdout if it's closed before calling the print routine. Raise an IOError if so. Finally, here's some examples to illustrate what I am saying: alex:~% python -c print | head -n0 close failed: [Errno 32] Broken pipe alex:~% python -c while 1: print | head -n0 [The loop continues running, even if the output stream is closed] ^C Traceback (most recent call last): File string, line 1, in module KeyboardInterrupt close failed: [Errno 32] Broken pipe alex:~% py3k -c print() | head -n0 alex:~% py3k -c while 1: print() | head -n0 Traceback (most recent call last): ... IOError: [Errno 32] Broken pipe -- components: Interpreter Core messages: 58469 nosy: alexandre.vassalotti severity: normal status: open title: Broken pipes should be handled better in 2.x type: rfe versions: Python 2.5, Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1596 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1596] Broken pipes should be handled better in 2.x
Guido van Rossum added the comment: I'll entertain a patch for 2.6. For 2.5 I think this smells too much like a feature. -- nosy: +gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1596 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1595] Probable extra semicolon in Py_LeaveRecursiveCall macro
Martin v. Löwis added the comment: I think you are right - that's a bug. As a consequence, overflowed would be cleared less often than it is now, which in turn may cause a fatal abort in case it fails to recover from a stack overflow (i.e. if it consumes another 50 stack frames, instead of unwinding). This entire machinery is there to guard against hard-to-analyze crashes resulting from stack overflows, in particular when a dictionary lookup happened to cause a stack overflow. The overflow would raise the Python exception, which would then be cleared in the dictionary lookup, as if nothing happened. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1595 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1589] New SSL module doesn't seem to verify hostname against commonName in certificate
Bill Janssen added the comment: Unfortunately, hostname matching is one of those ideas that seemed better when it was thought up than it actually proved to be in practice. I've had extensive experience with this, and have found it to almost always an application-specific decision. I thought about this when designing the client-side verification, and couldn't see any automatic solution that doesn't get in the way. So the right way to do this with Python is to write some application code that looks at the verified identity and makes decisions based on whatever authentication algorithm you need. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1589 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Noam Raphael added the comment: If I understand correctly, there are two main concerns: speed and portability. I think that they are both not that terrible. How about this: * For IEEE-754 hardware, we implement decimal/binary conversions, and define the exact behaviour of floats. * For non-IEEE-754 hardware, we keep the current method of relying on the system libraries. About speed, perhaps it's not such a big problem, since decimal/binary conversions are usually related to I/O, and this is relatively slow anyway. I think that usually a program does a relatively few decimal/binary conversions. About portability, I think (from a small research I just made) that S90 supports IEEE-754. This leaves VAX and cray users, which will have to live with a non-perfect floating-point behaviour. If I am correct, it will let 99.9% of the users get a deterministic floating-point behaviour, where eval(repr(f)) == f and repr(1.1)=='1.1', with a speed penalty they won't notice. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Guido van Rossum added the comment: Sounds okay, except that I think that for some folks (e.g. numeric Python users) I/O speed *does* matter, as their matrices are very large, and their disks and networks are very fast. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1576] [Patch] Working post import hook and lazy modules
Christian Heimes added the comment:
Updates:
* Some minor cleanups
* First draft of lazy modules implemented in C. It works but it needs
some cleanup and more error checking.
--
keywords: +patch
title: First draft of a post import hook - [Patch] Working post import hook
and lazy modules
Added file: http://bugs.python.org/file8928/py3k_post_import_hook_lazy.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1576
__Index: Python/import.c
===
--- Python/import.c (Revision 59470)
+++ Python/import.c (Arbeitskopie)
@@ -161,7 +161,7 @@
void
_PyImportHooks_Init(void)
{
- PyObject *v, *path_hooks = NULL, *zimpimport;
+ PyObject *v, *path_hooks = NULL, *zimpimport, *pihr;
int err = 0;
/* adding sys.path_hooks and sys.path_importer_cache, setting up
@@ -198,6 +198,14 @@
);
}
+ pihr = PyDict_New();
+ if (pihr == NULL ||
+PySys_SetObject(post_import_hooks, pihr) != 0) {
+ PyErr_Print();
+ Py_FatalError(initialization of post import hook registry
+ failed);
+ }
+
zimpimport = PyImport_ImportModule(zipimport);
if (zimpimport == NULL) {
PyErr_Clear(); /* No zip import module -- okay */
@@ -369,6 +377,7 @@
path, argv, ps1, ps2,
last_type, last_value, last_traceback,
path_hooks, path_importer_cache, meta_path,
+ post_import_hooks,
NULL
};
@@ -623,6 +632,228 @@
sys.modules failed);
}
+/* post import hook API */
+PyObject *
+PyImport_GetPostImportHooks(void)
+{
+ PyObject *pihr;
+
+ pihr = PySys_GetObject(post_import_hooks);
+ /* This should only happen during initialization */
+ if (pihr == NULL)
+ return NULL;
+
+ if (!PyDict_Check(pihr)) {
+ PyErr_SetString(PyExc_TypeError,
+post import registry is not a dict);
+ }
+ return pihr;
+}
+
+PyObject *
+PyImport_NotifyPostImport(PyObject *module)
+{
+ static PyObject *name = NULL;
+ PyObject *mod_name = NULL, *registry = NULL, *o;
+ PyObject *hooks = NULL, *hook, *it = NULL;
+ int status = -1;
+
+ if (name == NULL) {
+ name = PyUnicode_InternFromString(__name__);
+ if (name == NULL) {
+ return NULL;
+ }
+ }
+
+ if (module == NULL) {
+ return NULL;
+ }
+
+ if (!PyModule_Check(module)) {
+ PyErr_Format(PyExc_TypeError,
+ A module object was expected, got '%.200s',
+ Py_Type(module)-tp_name);
+ Py_DECREF(module);
+ return NULL;
+ }
+
+ if (PyModule_IsLazy(module)) {
+ /* nothing to do here */
+ return module;
+ }
+ /* XXX check if module is in sys.modules ? */
+
+ registry = PyImport_GetPostImportHooks();
+ if (registry == NULL) {
+ /* This should only happen during initialization */
+ return module;
+ }
+
+ mod_name = PyObject_GetAttr(module, name);
+ if (mod_name == NULL) {
+ goto error;
+ }
+ if (!PyUnicode_Check(mod_name)) {
+ PyObject *repr;
+ char *name;
+
+ repr = PyObject_Repr(module);
+ name = repr ? PyUnicode_AsString(repr) : unknown;
+ PyErr_Format(PyExc_TypeError,
+ Module __name__ attribute of '%.200s' is not
+ string, name);
+ Py_XDECREF(repr);
+ goto error;
+ }
+
+ hooks = PyDict_GetItem(registry, mod_name);
+ if (hooks == NULL || hooks == Py_None) {
+ /* Either no hooks are defined or they are already fired */
+ if (hooks == NULL) {
+ PyErr_Clear();
+ }
+ goto end;
+ }
+ if (!PyList_Check(hooks)) {
+ PyErr_Format(PyExc_TypeError,
+ expected None or list of hooks, got '%.200s',
+ Py_Type(hooks)-tp_name);
+ goto error;
+ }
+
+ /* fire hooks */
+ it = PyObject_GetIter(hooks);
+ if (it == NULL) {
+ goto error;
+ }
+ while ((hook = PyIter_Next(it)) != NULL) {
+ o = PyObject_CallFunctionObjArgs(hook, module, NULL);
+ Py_DECREF(hook);
+ if (o == NULL) {
+ goto error;
+ }
+ Py_DECREF(o);
+ }
+
+ /* Mark hooks as fired */
+ if (PyDict_SetItem(registry, mod_name, Py_None) 0) {
+ goto error;
+ }
+
+end:
+ status = 0;
+error:
+ Py_XDECREF(mod_name);
+ Py_XDECREF(it);
+ if (status 0) {
+ return NULL;
+ }
+ else {
+ return module;
+ }
+}
+
+PyObject *
+PyImport_RegisterPostImportHook(PyObject *callable, PyObject *mod_name)
+{
+ PyObject *registry = NULL, *hooks = NULL;
+ int status = -1;
+
+ if (!PyCallable_Check(callable)) {
+ PyErr_SetString(PyExc_TypeError, expected callable);
+ goto error;
+ }
+ if (!PyUnicode_Check(mod_name)) {
+ PyErr_SetString(PyExc_TypeError, expected string);
+ goto error;
+ }
+
+ registry = PyImport_GetPostImportHooks();
+ if (registry == NULL) {
+ goto error;
+ }
+
+ lock_import();
+
+ hooks = PyDict_GetItem(registry, mod_name);
+ /* module may be already loaded, get the module object from sys */
+ if (hooks == NULL || hooks == Py_None) {
+ PyObject *o, *modules;
+ PyObject *module = NULL;
+
+ modules = PyImport_GetModuleDict();
+ if (modules == NULL) {
+ goto error;
+ }
+ module = PyObject_GetItem(modules, mod_name);
+ if (module == NULL) {
+ PyErr_Clear();
+ /* somebody messed up sys.modules */
+ if (hooks
[issue1597] running test_ctypes 25 times in a row causes it to fail
New submission from Guido van Rossum: In debug mode, on my Ubuntu Linux box, this fails on the last iteration: $ ./python Lib/test/regrtest.py -R:20 test_ctypes test_ctypes beginning 25 repetitions 1234567890123456789012345 test test_ctypes failed -- Traceback (most recent call last): File /usr/local/google/home/guido/python/py3kd/Lib/ctypes/test/test_values.py, line 18, in test_an_integer self.failUnlessEqual(x*2, ctdll.get_an_integer()) AssertionError: 2818572288 != -1476395008 1 test failed: test_ctypes [104230 refs] $ Also, when using -R:19, I get some random leaks reported of 33 or -33 references leaked. Does this test use threads? It seems to have a race condition. -- assignee: theller messages: 58476 nosy: gvanrossum, theller priority: normal severity: normal status: open title: running test_ctypes 25 times in a row causes it to fail versions: Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Noam Raphael added the comment: If I were in that situation I would prefer to store the binary representation. But if someone really needs to store decimal floats, we can add a method fast_repr which always calculates 17 decimal digits. Decimal to binary conversion, in any case, shouldn't be slower than it is now, since on Gnu it is done anyway, and I don't think that our implementation should be much slower. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Guido van Rossum added the comment: If I were in that situation I would prefer to store the binary representation. But if someone really needs to store decimal floats, we can add a method fast_repr which always calculates 17 decimal digits. They can just use %.17g % x Decimal to binary conversion, in any case, shouldn't be slower than it is now, since on Gnu it is done anyway, and I don't think that our implementation should be much slower. Sure. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Guido van Rossum added the comment: I've tracked my problem to the GCC optimizer. The default optimizer setting is -O3. When I edit the Makefile to change this to -O1 or -O0 and recompile (only) doubledigits.c, repr(1e5) starts returning '10.0' again. -O2 behaves the same as -O3. Now, don't immediately start pointing fingers to the optimizer; it's quite possible that the code depends on behavior that the C standard doesn't actually guarantee. The code looks quote complicated. This is with GCC 4.0.3. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1580 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1350] IDLE - CallTips enhancement - show full doc-string in new window
Kurt B. Kaiser added the comment: This is very useful! However, it isn't fully baked. Please test more before submitting patches. Try to break them on corner cases. import CallTips CallTips.CallTips( AttributeError: 'NoneType' object has no attribute 'splitlines' def foo(): pass foo( same error. There are two conditional blocks which need to go on separate lines. The jocular test in CallTipWindow needs to be changed to avoid needless controversy. Also, the doc window's first line isn't quite right. There may be other issues, but that's as far as I got. I would like to get this into 2.6a1. However, I completely rewrote CallTips.py for 3.0. I will need another version of the patch for the latter, can you supply it once we get 2.6 put to bed? -- assignee: - kbk __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1350 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1598] unexpected response in imaplib
New submission from Scott Moser:
I'm running into a problem with imaplib where it is unable to download a
message. The example code at
http://www.python.org/doc/current/lib/imap4-example.html easily
demonstrates the problem.
#!/usr/bin/python
import getpass, imaplib
M = imaplib.IMAP4(my.imap.host.tld)
M.login(getpass.getuser(), getpass.getpass())
M.debug = 5
M.select(msg-test)
typ, data = M.search(None, 'ALL')
for num in data[0].split():
typ, data = M.fetch(num, '(RFC822)')
print 'Message %s\n%s\n' % (num, data[0][1])
M.close()
M.logout()
The majority of the messages transfer correctly, but some do not. I've
put 3 messages in the 'msg-test' folder, and one of them causes the
error below.
Traceback (most recent call last):
File test.py, line 9, in module
typ, data = M.fetch(num, '(RFC822)')
File /usr/lib/python2.5/imaplib.py, line 437, in fetch
typ, dat = self._simple_command(name, message_set, message_parts)
File /usr/lib/python2.5/imaplib.py, line 1055, in _simple_command
return self._command_complete(name, self._command(name, *args))
File /usr/lib/python2.5/imaplib.py, line 887, in _command_complete
raise self.abort('command: %s = %s' % (name, val))
imaplib.abort: command: FETCH = unexpected response: ')'
imaplib.py has a comment in _get_tagged_response:
# Some have reported unexpected response exceptions.
# Note that ignoring them here causes loops.
# Instead, send me details of the unexpected response and
# I'll update the code in `_get_response()'.
I can not provide access to the imap host, but I can help debug wherever
possible.
The most recent log messages are in the file attachment.
--
components: Library (Lib)
files: imaplib-debug.txt
messages: 58482
nosy: smoser
severity: normal
status: open
title: unexpected response in imaplib
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file8929/imaplib-debug.txt
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1598
__ 34:14.41 DPAP7 FETCH 4 (RFC822)
34:14.46 * 4 FETCH (RFC822 {3721}
34:14.46 matched r'\* (?Pdata\d+) (?Ptype[A-Z-]+)( (?Pdata2.*))?'
= ('4', 'FETCH', ' (RFC822 {3721}', '(RFC822 {3721}')
34:14.46 matched r'.*{(?Psize\d+)}$' = ('3721',)
34:14.46 read literal size 3721
34:14.55 untagged_responses[FETCH] 0 += [('4 (RFC822 {3721}', '...3883 bytes
total..')]
34:14.55 r questions.
34:14.55 untagged_responses[FETCH] 1 += [r questions. ]
34:14.55 )
34:14.55 last 10 IMAP4 interactions:
34:08.94 * 4 EXISTS
34:08.94 * 0 RECENT
34:08.94 * OK [UIDVALIDITY 25] UIDs valid
34:08.94 * OK [UIDNEXT 6] Predicted next UID
34:08.94 * FLAGS (\Flagged \Seen \Answered \Deleted \Draft)
34:08.94 * OK [PERMANENTFLAGS (\Flagged \Seen \Answered \Deleted \Draft
\*)] Permanent flags
34:08.94 DPAP2 OK [READ-WRITE] SELECT completed
34:08.94 DPAP3 SEARCH ALL
34:08.99 * SEARCH 1 2 3 4
34:08.99 DPAP3 OK SEARCH completed
the string 'r questions. ' above is the last part of the message.
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1599] IDLE hangs if os.spwanv command is given
Changes by Pooja: -- components: IDLE nosy: Pooja severity: normal status: open title: IDLE hangs if os.spwanv command is given versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1599 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1588] str.format() wrongly formats complex() numbers (Py30a2)
Mark Summerfield added the comment:
On 2007-12-11, Guido van Rossum wrote:
Guido van Rossum added the comment:
This really is a feature request -- in Python 2.x there is no formatting
code for complex numbers at all, and %.5s % complex(...) does the same
thing.
I thought Python 3 was meant to be an _improvement_:-)
I agree it would be neat to have control over complex numbers using the
same formatting language used for floats; but I note that it's easy
enough to do this manually, e.g.
{0.real:.5}+{0.imag:.5}j.format(z)
'1+0.7j'
Good point, I'll use that.
Thanks!
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1588
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
