[issue2121] complex constructor doesn't accept string with nan and inf
New submission from Christian Heimes: This is a reminder. The issue makes the complex(repr(...)) round-trip impossible when either the real or imag part is nan or infinite. -- components: Interpreter Core messages: 62422 nosy: tiran priority: normal severity: normal status: open title: complex constructor doesn't accept string with nan and inf versions: Python 2.6, Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2121 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2120] broken links in advocacy HOWTO
Changes by Christian Heimes: -- assignee: - georg.brandl priority: - normal type: - behavior __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2120 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2118] smtplib.SMTP() raises socket.error rather than SMTPConnectError
Christian Heimes added the comment: Why is this a bug? Do the docs promise that smtplib only raises SMTPConnectError? -- nosy: +tiran priority: - normal __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2118 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2111] mmap segfaults when trying to write a block opened with PROT_READ
Christian Heimes added the comment: Fixed in r60830 (trunk) Martin, is the fix a candidate for 2.5.3, too? -- assignee: - loewis nosy: +loewis, tiran priority: - high resolution: - accepted status: open - pending versions: +Python 2.5 -Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2111 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2112] mmap.error should be a subclass of EnvironmentError and not a direct EnvironmentError
Christian Heimes added the comment: Sounds fine with me -- keywords: +easy, patch nosy: +tiran priority: - normal __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2112 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2120] broken links in advocacy HOWTO
Ori Avtalion added the comment: Removing the spaces is wrong. They should be replaced with '~'. I also found two other punctuation problems: * A period that should be a colon. * A comma that should be a dash/semicolon/something else. I'm not really sure what's the best replacement. See the attached advocacy.patch Added file: http://bugs.python.org/file9435/advocacy.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2120 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2122] mmap.flush does not check for errors on windows
New submission from Ralf Schmitt:
mmap.flush returns the result of the call to FlushViewOfFile as an
integer, and does not check for errors. On unix it does check for
errors. The function should return None and raise an exception if an
error occurs...
This bug can lead to data loss...
Here's the current version of that function:
static PyObject *
mmap_flush_method(mmap_object *self, PyObject *args)
{
Py_ssize_t offset = 0;
Py_ssize_t size = self-size;
CHECK_VALID(NULL);
if (!PyArg_ParseTuple(args, |nn:flush, offset, size))
return NULL;
if ((size_t)(offset + size) self-size) {
PyErr_SetString(PyExc_ValueError, flush values out of range);
return NULL;
}
#ifdef MS_WINDOWS
return PyInt_FromLong((long) FlushViewOfFile(self-data+offset, size));
#elif defined(UNIX)
/* XXX semantics of return value? */
/* XXX flags for msync? */
if (-1 == msync(self-data + offset, size, MS_SYNC)) {
PyErr_SetFromErrno(mmap_module_error);
return NULL;
}
return PyInt_FromLong(0);
#else
PyErr_SetString(PyExc_ValueError, flush not supported on this system);
return NULL;
#endif
}
--
components: Library (Lib)
messages: 62427
nosy: schmir
severity: major
status: open
title: mmap.flush does not check for errors on windows
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2122
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2120] broken links in advocacy HOWTO
Robert Lehmann added the comment: Right, the second link requires a tilde -- I just tried the first one (which works without). You should change all lines to be 80 characters wide maximum, though (can quickly be done by any commiter, not worth a new patch IMO). The dash thing looks okay, --- is used a couple of times throughout the docs. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2120 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2123] ctypes pointer not always keeping target alive
New submission from Armin Rigo: It's hard to tell for sure, given the lack of precise definition, but I believe that the attached piece of code should work. What it does is make p1 point to c_long(20). So ctypes should probably keep the c_long(20) alive as long as p1 is alive (and not further modified). This test shows that the c_long(20) gets freed instead, making the p1.contents reference garbage. -- components: Extension Modules files: x.py messages: 62429 nosy: arigo severity: normal status: open title: ctypes pointer not always keeping target alive Added file: http://bugs.python.org/file9436/x.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2123 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2124] xml.sax and xml.dom fetch DTDs by default
New submission from A.M. Kuchling: The W3C posted an item at http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic describing how their DTDs are being fetched up to 130M times per day. The Python parsers are part of the problem, as noted by Paul Boddie on the python-advocacy list: There are two places which stand out: xml/dom/xmlbuilder.py xml/sax/saxutils.py What gives them away is the way as the cause of the described problem is that they are both fetching things which are given as system identifiers - the things you get in the document type declaration at the top of an XML document which look like a URL. If you then put some trace statements into the code and then try and parse something using, for example, the xml.sax API, it becomes evident that by default the parser attempts to fetch lots of DTD-related resources, not helped by the way that stuff like XHTML is now modular and thus employs lots of separate files in the DTD. This is obvious because you get something like this printed to the terminal: saxutils: opened http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-inlstyle-1.mod saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-framework-1.mod saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-datatypes-1.mod saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-qname-1.mod saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-events-1.mod saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-attribs-1.mod saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml11-model-1.mod saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-charent-1.mod saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-lat1.ent saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-symbol.ent saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-special.ent saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-text-1.mod saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-inlstruct-1.mod saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-inlphras-1.mod saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-blkstruct-1.mod saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-blkphras-1.mod Of course, the best practice with APIs like SAX is that you define your own resolver or handler classes which don't go and fetch DTDs from the W3C all the time, but this isn't the out of the box behaviour. Instead, implementers have chosen the most convenient behaviour which arguably involves the least effort in telling people how to get hold of DTDs so that they may validate their documents, but which isn't necessarily the right thing in terms of network behaviour. Naturally, since defining specific resolvers/handlers involves a lot of boilerplate (and you should try it in Java!) then a lot of developers just incur the penalty of having the default behaviour, instead of considering the finer points of the various W3C specifications (which is never really any fun). Anyway, I posted a comment saying much the same on the blog referenced at the start of this thread, but we should be aware that this is default standard library behaviour, not rogue application developer behaviour. -- components: XML messages: 62430 nosy: akuchling severity: normal status: open title: xml.sax and xml.dom fetch DTDs by default versions: Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2124 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2124] xml.sax and xml.dom fetch DTDs by default
Changes by A.M. Kuchling: -- type: - resource usage __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2124 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2124] xml.sax and xml.dom fetch DTDs by default
A.M. Kuchling added the comment:
Here's a simple test to demonstrate the problem:
from xml.sax import make_parser
from xml.sax.saxutils import prepare_input_source
parser = make_parser()
inp = prepare_input_source('file:file.xhtml')
parser.parse(inp)
file.xhtml contains:
?xml version=1.0 encoding=UTF-8?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN
http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd;
html xmlns=http://www.w3.org/1999/xhtml; /
If you insert a debug print into saxutils.prepare_input_source,
in the branch which uses urllib.urlopen(), you get the above list of
inputs accessed: the XHTML 1.1 DTD, which is nicely modular and pulls in
all those other files.
I don't see a good way to fix this without breaking backward
compatibility to some degree. The
external-general-entities features defaults to 'on', which enables this
fetching; we could change the default to 'off', which would save the
parsing effort, but would also mean that entities like eacute; weren't
defined.
If we had catalog support, we could ship the XHTML 1.1 DTDs and any
other DTDs of wide usage, but we don't.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2124
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2124] xml.sax and xml.dom fetch DTDs by default
Changes by A.M. Kuchling: -- priority: - urgent __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2124 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2125] [patch] Read support for Records in msilib
New submission from Floris Bruynooghe: The msilib documentation mentions that read support of MSI files is supported, however the actual methods on the Record class for it are missing. This patch wraps two more functions from the MSI API to the record class, enabling to read integers and strings. The only one left then (AFAIK) is Stream but I didn't need that so couldn't test it. -- components: Extension Modules, Library (Lib), Windows files: msilib.diff messages: 62432 nosy: flub severity: normal status: open title: [patch] Read support for Records in msilib versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file9437/msilib.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2125 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1813] Codec lookup failing under turkish locale
Árni Már Jónsson added the comment:
There is more to this bug than appears. I'm guessing that the name
mangling code in locale (e.g. the normalizing code) is locale dependent.
See this example:
#!/usr/bin/python2.5
import locale
print 'TR', locale.normalize('tr')
print locale.setlocale(locale.LC_ALL, ('tr_TR', 'ISO8859-9'))
# first issue, not quite the same coming out, as came in
print locale.getlocale()
# and this fails
print locale.setlocale(locale.LC_ALL, ('tr_TR', 'ISO8859-9'))
First, the value returned from getlocale is ('tr_TR', 'so8859-9'), not
('tr_TR', 'ISO8859-9'), and the second setlocale fails.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1813
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2101] xml.dom documentation doesn't match implementation
Changes by A.M. Kuchling: -- keywords: +easy __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2101 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1390] toxml generates output that is not well formed
Changes by A.M. Kuchling: -- keywords: +patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1390 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2115] __slots__ make attribute setting 10x slower
Amaury Forgeot d'Arc added the comment: __instancecheck__ is not only slower, it can also cause crashes: import abc class MyABC: __metaclass__ = abc.ABCMeta __slots__ = [a] class Unrelated: pass MyABC.register(Unrelated) u=Unrelated() assert isinstance(u, MyABC) MyABC.a.__set__(u, 3) # Boom The patch I proposed above correctly raises the error: TypeError: descriptor 'a' for 'MyABC' objects doesn't apply to 'Unrelated' object __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2115 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2072] SimpleXMLRPCServer documentation about rpc_paths might be wrong
Changes by A.M. Kuchling: -- assignee: - akuchling nosy: +akuchling __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2072 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2123] ctypes pointer not always keeping target alive
Thomas Heller added the comment: May I ask: do you have a real use case for this, or is it a carefully constructed example? Of course I take all the blame for not defining/documenting this stuff. My current view is this: Python code C code === ptr = POINTER(c_long)() int *ptr = NULL; x = c_long(42) int x = 42; ptr.contents = xptr = x; a = ptr[0] int a = *ptr; b = ptr[n] int b = ptr[n]; Assigning to .contents changes 'where the pointer points to'. __setitem__ changes the pointed to memory location; __getitem__ retrieves the pointed to memory location. Having said that, it is no longer clear to me what reading the .contents attribute should mean. Would making the .contents attribute write-only help - is it impossible to construct this 'bug' without assigning to .contents? -- assignee: - theller nosy: +theller __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2123 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1061803] Source code encoding in IDLE console
Kurt B. Kaiser added the comment: No response from OP, closing. -- assignee: loewis - kbk resolution: - rejected _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1061803 _ ___ 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
Kurt B. Kaiser added the comment: No response from OP, closing. -- status: open - closed __ 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
[issue1734234] Fast path for unicodedata.normalize()
Virgil Dupras added the comment:
It's a very interesting patch. I wonder why it fell into oblivion. stuff
like unicode.normalize('NFC', u'\xe9') was more than twice as fast for
me.
Making sure that all unicode is normalized can be a bottleneck in a lot
of applications (it somewhat is in my apps).
The downside is that it makes test_codecs and test_unicode_file fail.
--
nosy: +vdupras
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1734234
_
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2115] __slots__ make attribute setting 10x slower
Amaury Forgeot d'Arc added the comment: I think I fixed the issue. svn annotate showed that the exact same optimization was applied on __slots__ read access, five years ago: r28297. -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2115 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2050] IDLE - make ScriptBinding event handlers return 'break'
Kurt B. Kaiser added the comment: r60843. Thanks for the patch! -- resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2050 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1948] Cant open python gui using VISTA
Kurt B. Kaiser added the comment: Please switch to the recently released 2.5.2 and let us know if the problem is still there. -- priority: high - normal __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1948 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2067] file.__exit__ does not call subclass' close method
Ralf Schmitt added the comment: The patch looks good, I've tested it on trunk and also release25-maint. It applies with fuzz and one has to add a from __future import with_statement. I think this should also be applied to release25-maint. IMHO, this is a rather severe problem, as it can easily lead to data loss. -- nosy: +schmir severity: normal - major versions: +Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2067 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1777134] minidom pretty xml output improvement
Virgil Dupras added the comment: If the patch would have better styling (if(onetextnode == True):), correct the test it breaks, and even better, add new ones, I guess it would be an acceptable one. -- nosy: +vdupras _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1777134 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2061] IDLE - autocompletion to support alternate patch separators
Kurt B. Kaiser added the comment: Why do we care about Python 2.2? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2061 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1334] IDLE - Fix several highlighting bugs
Kurt B. Kaiser added the comment: r60844. Thanks for the patch! -- resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1334 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1061803] Source code encoding in IDLE console
Changes by Kurt B. Kaiser: -- status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1061803 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1334] IDLE - Fix several highlighting bugs
Changes by Kurt B. Kaiser: Removed file: http://bugs.python.org/file8618/IDLE_highlighting.071026.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1334 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2124] xml.sax and xml.dom fetch DTDs by default
Martin v. Löwis added the comment: On systems that support catalogs, the parsers should be changed to support public identifiers, using local copies of these DTDs. However, I see really no way how the library could avoid resolving the DTDs altogether. The blog is WRONG in claiming that the system identifier is not a downloadable URL, but a mere identification (the namespace is a mere identification, but our parsers would never try to download anything). The parser needs the DTDs in case external entities occur in the document (of course, download could be delayed until the first reference occurs). -- nosy: +loewis __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2124 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2118] smtplib.SMTP() raises socket.error rather than SMTPConnectError
stranger4good added the comment: Not in so many words, but yes it does I cite: exception SMTPException Base exception class for all exceptions raised by this module ... exception SMTPConnectError Error occurred during establishment of a connection with the server. ... Note the word all. So, at least one should be able to catch SMTPException, but it is not the case Just my 2 cents. I do believe it is a great piece of work. Regards --- Christian Heimes [EMAIL PROTECTED] wrote: Christian Heimes added the comment: Why is this a bug? Do the docs promise that smtplib only raises SMTPConnectError? -- nosy: +tiran priority: - normal __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2118 __ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2118 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue960406] unblock signals in threads
Changes by sandy: -- components: +XML type: - rfe Tracker [EMAIL PROTECTED] http://bugs.python.org/issue960406 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue960406] handler
Changes by sandy: -- severity: normal - critical title: unblock signals in threads - handler type: rfe - security Tracker [EMAIL PROTECTED] http://bugs.python.org/issue960406 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue960406] unblock signals in threads
sandy added the comment: undoing spam -- components: -XML nosy: +sandylovesedward severity: critical - normal title: handler - unblock signals in threads type: security - Tracker [EMAIL PROTECTED] http://bugs.python.org/issue960406 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue960406] unblock signals in threads
Guido van Rossum added the comment: restore nosy list -- nosy: -sandylovesedward Tracker [EMAIL PROTECTED] http://bugs.python.org/issue960406 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1124861] subprocess fails on GetStdHandle in interactive GUI
Andrew Trusty added the comment: I agree with Daniel, I think this bug or a variant is still present in 2.5.1 because my wxPython app on Windows XP would fail to execute a Popen with only stdout using PIPE but succeeded with the described workaround of having stdout, stderr, and stdin set to PIPE. -- nosy: +atrusty versions: +Python 2.5 -Python 2.4 _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1124861 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2118] smtplib.SMTP() raises socket.error rather than SMTPConnectError
Christian Heimes added the comment: I see! You are right. Either the docs or the code need an update -- keywords: +easy resolution: - accepted __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2118 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
