[issue10517] test_concurrent_futures crashes with --with-pydebug on RHEL5 with Fatal Python error: Invalid thread state for this thread
Graham Dumpleton graham.dumple...@gmail.com added the comment: Did anyone test this fix for case of fork() being called from Python sub interpreter? Getting a report of fork() failing in sub interpreters under mod_wsgi that may be caused by this change. Still investigating. Specifically throwing up error: Couldn't create autoTLSkey mapping -- nosy: +grahamd ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10517 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13130] test_gdb: attempt to dereference a generic pointer
New submission from Stefan Krah stefan-use...@bytereef.org:
The Fedora bot fails since yesterday:
Breakpoint 1, builtin_id (self=module at remote 0x77f6fc90, v=Traceback
(most recent call last):
File /home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py, line
1329, in to_string
return pyop.get_truncated_repr(MAX_OUTPUT_LEN)
File /home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py, line
213, in get_truncated_repr
self.write_repr(out, set())
File /home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py, line
1199, in write_repr
proxy = self.proxyval(visited)
File /home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py, line
1166, in proxyval
Py_UNICODEs = [int(field_str[i]) for i in safe_range(field_length)]
RuntimeError: Attempt to dereference a generic pointer.
) at Python/bltinmodule.c:927
927 return PyLong_FromVoidPtr(v);
#0 builtin_id (self=module at remote 0x77f6fc90, v=Traceback (most
recent call last):
File /home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py, line
1329, in to_string
return pyop.get_truncated_repr(MAX_OUTPUT_LEN)
File /home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py, line
213, in get_truncated_repr
self.write_repr(out, set())
File /home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py, line
1199, in write_repr
proxy = self.proxyval(visited)
File /home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py, line
1166, in proxyval
Py_UNICODEs = [int(field_str[i]) for i in safe_range(field_length)]
RuntimeError: Attempt to dereference a generic pointer.
) at Python/bltinmodule.c:927
#1 0x004b667f in call_function (pp_stack=0x7fffd6e8, oparg=1) at
Python/ceval.c:3988
#2 0x004b0787 in PyEval_EvalFrameEx (f=Frame 0x77f409c0, for file
string, line 1, in module (), throwflag=0) at Python/ceval.c:2625
#3 0x004b44ca in PyEval_EvalCodeEx (_co=code at remote
0x77f3c880, globals={'__builtins__': module at remote 0x77f6fc90,
'__name__': '__main__', '__doc__': None, '__package__': None},
locals={'__builtins__': module at remote 0x77f6fc90, '__name__':
'__main__', '__doc__': None, '__package__': None}, args=0x0, argcount=0,
kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at
Python/ceval.c:3375
#4 0x004a4668 in PyEval_EvalCode (co=code at remote 0x77f3c880,
globals={'__builtins__': module at remote 0x77f6fc90, '__name__':
'__main__', '__doc__': None, '__package__': None}, locals={'__builtins__':
module at remote 0x77f6fc90, '__name__': '__main__', '__doc__': None,
'__package__': None}) at Python/ceval.c:770
#5 0x004edc20 in run_mod (mod=0x9b0560, filename=0x619622 string,
globals={'__builtins__': module at remote 0x77f6fc90, '__name__':
'__main__', '__doc__': None, '__package__': None}, locals={'__builtins__':
module at remote 0x77f6fc90, '__name__': '__main__', '__doc__': None,
'__package__': None}, flags=0x7fffe3c0, arena=0x92e070) at
Python/pythonrun.c:1795
#6 0x004ed91e in PyRun_StringFlags (str=0x710e1418
id('\\U0001d121')\n, start=257, globals={'__builtins__': module at remote
0x77f6fc90, '__name__': '__main__', '__doc__': None, '__package__': None},
locals={'__builtins__': module at remote 0x77f6fc90, '__name__':
'__main__', '__doc__': None, '__package__': None}, flags=0x7fffe3c0) at
Python/pythonrun.c:1729
#7 0x004ebfb6 in PyRun_SimpleStringFlags (command=0x710e1418
id('\\U0001d121')\n, flags=0x7fffe3c0) at Python/pythonrun.c:1302
#8 0x0050b41f in run_command (command=0x8e0500 Lid('\\U0001d121')\n,
cf=0x7fffe3c0) at Modules/main.c:260
#9 0x0050bf70 in Py_Main (argc=4, argv=0x77faf040) at
Modules/main.c:634
#10 0x00416e97 in main (argc=4, argv=0x7fffe5a8) at
./Modules/python.c:59
--
components: Tests
messages: 145161
nosy: haypo, loewis, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: test_gdb: attempt to dereference a generic pointer
type: behavior
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13130
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13122] Out of date links in the sidebar of the documentation index of versions 3.1 and 3.2
Georg Brandl ge...@python.org added the comment: Nobody said 3.2 was not stable... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13122 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13060] allow other rounding modes in round()
Mark Dickinson dicki...@gmail.com added the comment: I'm warming to this idea. We already have several round-to-integer functions (but not round-to-an-arbitrary-number-of-decimal-places) available in the math module (under the names floor, ceil and trunc). This *does* seem to be a common need, and it's easy to get roll-your-own implementations wrong (e.g., check what the implementation in msg145140 does for negative numbers). I suspect that once we get more people shifting to py3k we're going to get more complaints about round doing round-half-to-even. Rather than expanding the signature of round, it might be worth considering a new math-module function (with name to be determined) that does round-half-up for floats. We might later extend it to other types in the same way as is currently done for floor and ceil (with __floor__ and __ceil__ magic methods); introduction of such magic methods would probably require a PEP though. At issue: *which* round-half-up function do we want? The one that rounds halfway cases away from zero (what Wikipedia calls Round half away from zero), or the one that rounds halfway cases towards +infinity? I'm inclined towards the former. I don't think it's worth implementing both. I guess we should follow floor / ceil's lead of returning integer output for float input in the case where number of places to round to isn't given (though personally I would have been happier if floor / ceil had continued to return float output for float input, as in Python 2.x). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10517] test_concurrent_futures crashes with --with-pydebug on RHEL5 with Fatal Python error: Invalid thread state for this thread
Charles-François Natali neolo...@free.fr added the comment: Hello, Did anyone test this fix for case of fork() being called from Python sub interpreter? Not specifically, unless it's part of the test suite. Anyway, unless this problem is systematic - which I doubt - it probably wouldn't have helped. Getting a report of fork() failing in sub interpreters under mod_wsgi that may be caused by this change. Still investigating. Specifically throwing up error: Couldn't create autoTLSkey mapping Hmmm. If you can, try strace or instrument the code (perror() should be enough) to see why it's failing. pthread_setspecific() can fail with: - EINVAL, if the TLS key is invalid (which would be strange since we call pthread_key_delete()/pthread_key_create() just before) - or ENOMEM, if you run out of memory/address space The later seems much more likely (e.g. if many child processes and subinterpreters are created). BTW, if this is a bug report from someone else, tell him to post here, it'll be easier. And we don't byte :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10517 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10141] SocketCan support
Charles-François Natali neolo...@free.fr added the comment: Working fine on the buildbots and Vinay's box, closing! -- resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10141 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13131] FD leak in urllib2
New submission from Valery Khamenya khame...@gmail.com: Explanation from dablitz's comment at https://bugs.pypy.org/issue867 : quote urllib2 in the stdlib leaks fd's if an exception is raised while opening a connection. The issue occurs due to a socket being opened then an exception being raised before an object with the socket is returned, leaving no way to explicitly close the object. On cpython this would not be an issue as the object would lose all references almost immediately however it lingers around with a proper GC causing FD's to build up if the same condition happens repeatedly (eg a loop/web crawling) The file enclosed is a script to generate the leakage, to run invok it as follows python leak.py pypy should start leaking FD's and can be see in /proc/pid of leak.py/fd /quote Related issues: http://bugs.python.org/issue3066 http://bugs.python.org/issue1208304 http://bugs.python.org/issue1601399 -- components: IO, Library (Lib) files: leak.py messages: 145166 nosy: Valery.Khamenya priority: normal severity: normal status: open title: FD leak in urllib2 type: resource usage versions: Python 2.7 Added file: http://bugs.python.org/file23344/leak.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13131 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8087] Unupdated source file in traceback
Diego Mascialino dmascial...@gmail.com added the comment: On Fri, Oct 7, 2011 at 5:25 PM, Ezio Melotti rep...@bugs.python.org wrote: Ezio Melotti ezio.melo...@gmail.com added the comment: I'm not sure this is useful to have. If you changed your code you know that you have to reload, so why would you want a warning that tells you that you changed the code? The source line showed in the traceback could not be the same line executed. Take a look to this example: k.py: def f(): a,b,c = 1,2 Traceback (most recent call last): File stdin, line 1, in module File k.py, line 2, in f a,b,c = 1,2 ValueError: need more than 2 values to unpack k.py: def f(): # blah a,b = 1,2 Traceback (most recent call last): File stdin, line 1, in module File k.py, line 2, in f # blah ValueError: need more than 2 values to unpack For some reason I always had the opposite problem (i.e. after a reload the traceback was still showing the original code, and not the new one), while IIUC you are saying that it shows the new code even if the module is not reloaded. I tried your code and indeed it does what you say, so either I am mistaken and I've been misreading the tracebacks, or this changed from 2.6 to 2.7, or in some cases even the behavior (I think) I observed might happen. I'll have to verify this next time it happens. That is strange, I think Python does not save the original code in any place. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8087 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8087] Unupdated source file in traceback
Ezio Melotti ezio.melo...@gmail.com added the comment: The source line showed in the traceback could not be the same line executed. My point is that when I see an error and modify the source to fix it, then I know that I'll have to reload. If for some reason I forget to reload, I'll get the wrong line in the traceback and then reload, but I don't think that ever happened to me. So to me, your warning will only be useful in the case where I modified the source, forgot to reload and got the same error again with a wrong line displayed. Also note that reloading is not so common; usually you just restart your application and that will give you the right traceback. Also I'm not sure the warning you proposed is the best way to handle this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8087 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13131] FD leak in urllib2
Valery Khamenya khame...@gmail.com added the comment: by the way, timeout parameter should be set to 0.2 as for my 13Mbit ADSL line. With 0.002 it is not reproducible for my environment -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13131 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11812] transient socket failure to connect to 'localhost'
Charles-François Natali neolo...@free.fr added the comment: Attached patch reads the name of the server socket instead of using HOST or 'localhost'. By the way, why do we use 'localhost' instead of '127.0.0.1' for support.HOST? '127.0.0.1' doesn't depend on the DNS configuration of the host (especially its hosts file, even Windows has such file). This might be a good idea. Apparently, Windows 7 doesn't use its hosts file (yes, it does have one) to resolve 'localhost', but its DNS resolver, see http://serverfault.com/questions/4689/windows-7-localhost-name-resolution-is-handled-within-dns-itself-why Depending on the DNS setup, it could lead to a latency which might explain such failures. Seems a clear race condition. The code looks correct: a threading.Event is set by the server once it called listen(), point at which incoming connections should be queued (SYN/ACK is sent before accept()). So I'd bet either on resolution delay (on Unix /etc/nsswitch.conf), or an overloaded machine. -- nosy: +neologix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11812 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13132] distutils sends non-RFC compliant HTTP request
New submission from Mitchell Hashimoto xmit...@gmail.com:
In ``Lib/distutils/command/register.py`` as well as ``upload.py``, the
following code exists to build the HTTP request body to send to the cheese shop
server:
body.write('\nContent-Disposition: form-data; name=%s'%key)
body.write(\n\n)
RFC2616 page 31 (http://tools.ietf.org/html/rfc2616#page-31) states that
headers must be separated by CRLF. Specifically, the above \n\n for the
header separator is causing issues with some minimal RFC-compliant web servers.
--
assignee: tarek
components: Distutils
messages: 145171
nosy: eric.araujo, mitchellh, tarek
priority: normal
severity: normal
status: open
title: distutils sends non-RFC compliant HTTP request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13132
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13132] distutils sends non-RFC compliant HTTP request
Mitchell Hashimoto xmit...@gmail.com added the comment: Patch attached. -- keywords: +patch Added file: http://bugs.python.org/file23345/issue13132.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13132 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8087] Unupdated source file in traceback
Diego Mascialino dmascial...@gmail.com added the comment: So to me, your warning will only be useful in the case where I modified the source, forgot to reload and got the same error again with a wrong line displayed. Also note that reloading is not so common; usually you just restart your application and that will give you the right traceback. I know the case when this happens is really unsusual, but the interperter could be able to alert you than that line of the traceback is wrong. Also I'm not sure the warning you proposed is the best way to handle this. I agree that, another approach is to save a copy of the source file associated to the compiled code (like a .pys). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8087 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12192] Doc that collection mutation methods return item or None
Mike Hoy mho...@gmail.com added the comment: Created a patch based on suggestions here. -- keywords: +patch Added file: http://bugs.python.org/file23346/return-none.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12192 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13130] test_gdb: attempt to dereference a generic pointer
Antoine Pitrou pit...@free.fr added the comment: Following patch seems to fix it: diff --git a/Tools/gdb/libpython.py b/Tools/gdb/libpython.py --- a/Tools/gdb/libpython.py +++ b/Tools/gdb/libpython.py @@ -1152,7 +1152,7 @@ class PyUnicodeObjectPtr(PyObjectPtr): field_str = field_str.cast(_type_unsigned_char_ptr) elif repr_kind == 2: field_str = field_str.cast(_type_unsigned_short_ptr) -elif repr_kind == 3: +elif repr_kind == 4: field_str = field_str.cast(_type_unsigned_int_ptr) else: # Python 3.2 and earlier -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13130 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12192] Doc that collection mutation methods return item or None
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 352d075839f7 by Georg Brandl in branch 'default': Closes #12192: Document that mutating list methods do not return the instance (original patch by Mike Hoy). http://hg.python.org/cpython/rev/352d075839f7 -- nosy: +python-dev resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12192 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13130] test_gdb: attempt to dereference a generic pointer
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset ef1f0434c79c by Antoine Pitrou in branch 'default': Fix test_gdb following the small unicode struct change in c25262e97304 (issue #13130) http://hg.python.org/cpython/rev/ef1f0434c79c -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13130 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13130] test_gdb: attempt to dereference a generic pointer
Antoine Pitrou pit...@free.fr added the comment: Let's wait for the buildbots. -- resolution: - fixed stage: needs patch - committed/rejected status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13130 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13112] backreferences in comprehensions
yoch yoch.me...@gmail.com added the comment: Okay, thanks ;) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13112 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13130] test_gdb: attempt to dereference a generic pointer
Antoine Pitrou pit...@free.fr added the comment: Seems to have cleared the buildbot failures. -- status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13130 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13125] test_all_project_files() expected failure
Antoine Pitrou pit...@free.fr added the comment:
Could you arrange to silence stdout/stderr in non-verbose mode?
$ ./python -m test -uall test_lib2to3
[1/1] test_lib2to3
ParseError on file /home/antoine/cpython/default/Lib/lib2to3/main.py bad input:
type=22, value='=', context=('', (81, 38))
ParseError on file
/home/antoine/cpython/default/Lib/lib2to3/tests/pytree_idempotency.py bad
input: type=22, value='=', context=('', (47, 33))
--- /home/antoine/cpython/default/Lib/lib2to3/tests/data/bom.py 2011-08-01
15:24:54.045209157 +0200
+++ @ 2011-10-08 20:31:41.981242859 +0200
@@ -1,2 +1,2 @@
-# coding: utf-8
+# coding: utf-8
print BOM BOOM!
1 test OK.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13125
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13133] FD leaks in ZipFile.read(), ZipFile.extract() and also using explicit arc_member.close()
New submission from Valery Khamenya khame...@gmail.com: The attached file reproduces 3 types of FD leaks and leads to the error like: IOError: [Errno 24] Too many open files: '/tmp/1019' For example if executed with pypy. -- components: IO, Library (Lib) files: zipfiletest.py messages: 145182 nosy: Valery.Khamenya priority: normal severity: normal status: open title: FD leaks in ZipFile.read(), ZipFile.extract() and also using explicit arc_member.close() type: resource usage versions: Python 2.7 Added file: http://bugs.python.org/file23347/zipfiletest.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13133 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13131] FD leak in urllib2
Valery Khamenya khame...@gmail.com added the comment: the problem seems to be fixed with the patch attached. Thanks go to fijal@freenode -- keywords: +patch Added file: http://bugs.python.org/file23348/urllib2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13131 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13131] FD leak in urllib2
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +orsenthil ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13131 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13131] FD leak in urllib2
Ezio Melotti ezio.melo...@gmail.com added the comment: Pay attention not to introduce regressions like the one in #12576 while fixing this. I'm not sure there are similar tests for urllib2 -- if not they should be added. -- nosy: +ezio.melotti stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13131 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13133] FD leaks in ZipFile.read(), ZipFile.extract() and also using explicit arc_member.close()
Meador Inge mead...@gmail.com added the comment: I can't reproduce this problem in either 2.7.2 or 3.3.0a0. For example if executed with pypy. Do you mean that this problem is only reproducible when the attached script is run with pypy? -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13133 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13134] speed up finding of one-character strings
New submission from Antoine Pitrou pit...@free.fr:
In stringlib/fastsearch, instead of using our own loops, we can use memchr()
(and, if available, memrchr()) when looking for one-character strings. memchr()
is generally quite optimized; on this Linux/glibc machine, I get speedups of
5x-10x:
./python -m timeit -s large='a'*1+'b' large.find('b')
- before: 10.5 usec per loop
- after: 0.889 usec per loop
./python -m timeit -s large='b'+'a'*1 large.rfind('b')
- before: 7.06 usec per loop
- after: 1.94 usec per loop
--
components: Interpreter Core
messages: 145186
nosy: haypo, loewis, pitrou
priority: normal
severity: normal
status: open
title: speed up finding of one-character strings
type: performance
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13134
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13134] speed up finding of one-character strings
Changes by Antoine Pitrou pit...@free.fr: -- keywords: +patch Added file: http://bugs.python.org/file23349/memchr.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13134 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13134] speed up finding of one-character strings
Antoine Pitrou pit...@free.fr added the comment: With MSVC there seems to be no difference, meaning Windows probably has a naïve memchr() implementation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13134 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13133] FD leaks in ZipFile.read(), ZipFile.extract() and also using explicit arc_member.close()
Valery Khamenya khame...@gmail.com added the comment: I can't reproduce this problem in either 2.7.2 or 3.3.0a0. You probably mean CPython implementation of Python. No, I didn't mean this implementation. Do you mean that this problem is only reproducible when the attached script is run with pypy? I can't say only. I just could say yes, it is reproducible with pypy. Perhaps, there are others Python implementations that will suffer from the bug in current implementation of ZipFile -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13133 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13134] speed up finding of one-character strings
Antoine Pitrou pit...@free.fr added the comment: New patch with a couple of tests. -- Added file: http://bugs.python.org/file23350/memchr2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13134 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13135] Using type() as a constructor doesn't support new class keyword arguments
New submission from Marty Alchin ma...@martyalchin.com: PEP 3115 introduced keyword arguments to class definitions and changed metaclasses to use them instead. Unfortunately, `type()` doesn't seem to have been updated to accept those keyword arguments as well. What this amounts to is that using `type()` as a constructor can no longer fully replicate the behavior of a class definition. Therefore, classes that use keyword arguments can't be created dynamically. I would attempt a patch, but I don't have a development environment capable of compiling Python, so I wouldn't have any chance to test it. -- messages: 145190 nosy: gulopine priority: normal severity: normal status: open title: Using type() as a constructor doesn't support new class keyword arguments type: feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13135 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13133] FD leaks in ZipFile.read(), ZipFile.extract() and also using explicit arc_member.close()
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Yes, in 2.7 many parts of the stdlib relies on reference counting to close files. But 3.2 introduced a ResourceWarning which is emitted (in debug mode) each time a __del__ closes a valuable resource like a file or a socket. This was done exactly for this reason - help other implementations with a different garbage collector. Now Lib/zipfile.py is probably much more gc-friendly: see how it uses a new member close_fileobj, and the with statement in ZipFile.read(). PyPy will benefit of this when it migrates to 3.2; meanwhile, you could apply the same changes in pypy's own copy of zipfile.py. -- nosy: +amaury.forgeotdarc resolution: - out of date status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13133 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13136] speed-up conversion between unicode widths
New submission from Antoine Pitrou pit...@free.fr: This patch speeds up _PyUnicode_CONVERT_BYTES by unrolling its loop. Example micro-benchmark: ./python -m timeit -s a='x'*1;b='\u0102'*1000;c='\U0010' a+b+c - before: 10 loops, best of 3: 14.9 usec per loop - after: 10 loops, best of 3: 9.19 usec per loop -- components: Interpreter Core files: unroll_convert_bytes.patch keywords: patch messages: 145192 nosy: pitrou priority: normal severity: normal stage: patch review status: open title: speed-up conversion between unicode widths type: performance versions: Python 3.3 Added file: http://bugs.python.org/file23351/unroll_convert_bytes.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13136] speed-up conversion between unicode widths
Marc-Andre Lemburg m...@egenix.com added the comment: Antoine Pitrou wrote: New submission from Antoine Pitrou pit...@free.fr: This patch speeds up _PyUnicode_CONVERT_BYTES by unrolling its loop. Example micro-benchmark: ./python -m timeit -s a='x'*1;b='\u0102'*1000;c='\U0010' a+b+c - before: 10 loops, best of 3: 14.9 usec per loop - after: 10 loops, best of 3: 9.19 usec per loop Before going further with this, I'd suggest you have a look at your compiler settings. Such optimizations are normally performed by the compiler and don't need to be implemented in C, making maintenance harder. The fact that Windows doesn't exhibit the same performance difference suggests that the optimizer is not using the same level or feature set as on Linux. MSVC is at least as good at optimizing code as gcc, often better. I tested using memchr() when writing those naive loops. It turned out that using memchr() was slower than using the direct loops. memchr() is inlined by the compiler just like the direct loop and the generated code for the direct version is often easier to optimize for the compiler than the memchr() one, since it receives more knowledge about the used data types. -- nosy: +lemburg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13136] speed-up conversion between unicode widths
Antoine Pitrou pit...@free.fr added the comment: Before going further with this, I'd suggest you have a look at your compiler settings. They are set by the configure script: gcc -pthread -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. -I./Include-DPy_BUILD_CORE -o Objects/unicodeobject.o Objects/unicodeobject.c Such optimizations are normally performed by the compiler and don't need to be implemented in C, making maintenance harder. The fact that the glibc includes such optimization (in much more sophisticated form) suggests to me that many compilers don't perform these optimizations automically. I tested using memchr() when writing those naive loops. memchr() is mentioned in another issue, #13134. memchr() is inlined by the compiler just like the direct loop I don't think so. If you look at the glibc's memchr() implementation, it's a sophisticated routine, not a trivial loop. Perhaps you're thinking about memcpy(). and the generated code for the direct version is often easier to optimize for the compiler than the memchr() one, since it receives more knowledge about the used data types. ?? Data types are fixed in the memchr() definition, there's no knowledge to be gained by inlining. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13137] from __future__ import division breaks ad hoc numeric types
New submission from Blair bidih...@gmail.com: I believe that the use of __future__.division may have unintended consequences with user types that define division. The following fails: from __future__ import division class NumericType(object): def __init__(self,x): self.x = x def __div__(self,rhs): return self.x/rhs print NumericType(3.0) / 2.0 with the error message File C:\proj_py\learning\future_bug\future.py, line 10, in module print NumericType(3.0) / 2.0 TypeError: unsupported operand type(s) for /: 'NumericType' and 'float' Remove the line `from __future__ import division` and everything works fine. I am using Python 2.7.2 -- components: None messages: 145195 nosy: gumtree priority: normal severity: normal status: open title: from __future__ import division breaks ad hoc numeric types type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13137 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13137] from __future__ import division breaks ad hoc numeric types
Benjamin Peterson benja...@python.org added the comment: You have to implement __truediv__. -- nosy: +benjamin.peterson resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13137 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13135] Using type() as a constructor doesn't support new class keyword arguments
Benjamin Peterson benja...@python.org added the comment: That's not true. You simply call the metaclass itself. -- nosy: +benjamin.peterson resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13135 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13135] Using type() as a constructor doesn't support new class keyword arguments
Marty Alchin ma...@martyalchin.com added the comment: Hrm, that does seem to satisfy the case I was immediately concerned with, but I was thinking there was another issue with it, but now I'm having trouble pinning down an example. I'll just assume I was getting ahead of myself. Thanks for the sanity lesson. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13135 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13138] ElementTree's Element.iter() lacks versionadded
New submission from Andreas Stührk andy-pyt...@hammerhartes.de: See http://docs.python.org/whatsnew/2.7.html#updated-module-elementtree-1-3 -- assignee: docs@python components: Documentation files: Element_iter_versionadded.patch keywords: patch messages: 145199 nosy: Trundle, docs@python priority: normal severity: normal status: open title: ElementTree's Element.iter() lacks versionadded versions: Python 2.7 Added file: http://bugs.python.org/file23352/Element_iter_versionadded.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13138 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13136] speed-up conversion between unicode widths
Meador Inge mead...@gmail.com added the comment: On Sat, Oct 8, 2011 at 5:34 PM, Antoine Pitrou rep...@bugs.python.org wrote: Antoine Pitrou pit...@free.fr added the comment: Before going further with this, I'd suggest you have a look at your compiler settings. They are set by the configure script: gcc -pthread -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/unicodeobject.o Objects/unicodeobject.c Such optimizations are normally performed by the compiler and don't need to be implemented in C, making maintenance harder. The fact that the glibc includes such optimization (in much more sophisticated form) suggests to me that many compilers don't perform these optimizations automically. I agree. This is more of an optimized runtime library problem than code optimization problem. I tested using memchr() when writing those naive loops. memchr() is mentioned in another issue, #13134. Yeah, this conversation is really more relevant to issue13134, but I will reply to these here anyway memchr() is inlined by the compiler just like the direct loop I don't think so. If you look at the glibc's memchr() implementation, it's a sophisticated routine, not a trivial loop. Perhaps you're thinking about memcpy(). Without link-time optimization enabled, I doubt the toolchain can inline 'memchr' in the traditional sense (i.e. inserting the body of the routine inline). Even if it could, the inline heuristics would most likely choose not to. I don't think we use LTO with GCC, but I think we might with VC++. GCC does something else called builtin folding that is more likely. For example, 'memchr (bca, 'c', 3)' gets replace with instructions to compute a pointer index into bca. This won't happen in this case because all of the 'memchr' arguments are all variable. and the generated code for the direct version is often easier to optimize for the compiler than the memchr() one, since it receives more knowledge about the used data types. ?? Data types are fixed in the memchr() definition, there's no knowledge to be gained by inlining. I think what Marc-Andre is alluding to is that the first parameter of 'memchr' is 'void *' which could (in theory) limit optimization opportunities. Where as if it knew that the data being searched is a 'char *' or something it could take advantage of that. -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10399] AST Optimization: inlining of function calls
Changes by Meador Inge mead...@gmail.com: -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10399 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13139] multiprocessing.map skips finally blocks
New submission from Daniel Wagner-Hall dawag...@gmail.com:
import random
from multiprocessing import Pool
from time import sleep
def Process(x):
try:
print x
sleep(random.random())
raise Exception('Exception: ' + x)
finally:
print 'Finally: ' + x
Pool(3).map(Process, ['1','2','3'])
Expect all three Finally blocks to be called (or at least, one Finally per x
printed by line 8)
Actually, only one (occasionally two) are printed.
Same behaviour exhibited on dual-core Mac running OSX 10.6 with Python 2.7, and
single core Ubuntu running Python 2.6.
--
components: None
messages: 145201
nosy: illicitonion
priority: normal
severity: normal
status: open
title: multiprocessing.map skips finally blocks
type: behavior
versions: Python 2.6, Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13139
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13132] distutils sends non-RFC compliant HTTP request
Éric Araujo mer...@netwok.org added the comment: Hi Mitchell, thanks for your interest in Python. Using CLRF was requested before (#10510) and rejected on the ground that the RFC (at least for HTTP 1.0) allows LF. CRLF is preferred but not required. Hence, we deem it is not a bug. The register, upload and upload_docs commands in distutils2 do use CRLF. BTW, I think your patch was incomplete: You stripped one newline, replaced one LF with CRLF, and left many other LFs. -- assignee: tarek - eric.araujo nosy: +orsenthil versions: -Python 2.6, Python 3.1, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13132 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12533] python-celementtree prevents me from running python develop.py to compile Imprudence Viewer
Éric Araujo mer...@netwok.org added the comment: Closing, please reopen if there is more info. -- resolution: - invalid stage: - committed/rejected status: pending - closed versions: -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12533 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12967] AttributeError distutils\log.py
Éric Araujo mer...@netwok.org added the comment: I stand by my opinion that running setup.py from IDLE is not supported. -- resolution: - wont fix stage: - committed/rejected status: open - closed type: compile error - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12967 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13136] speed-up conversion between unicode widths
Martin v. Löwis mar...@v.loewis.de added the comment: Marc-Andre: gcc will normally not unroll loops, unless -funroll-loops is given on the command line. Then, it will unroll many loops, and do so with 8 iterations per outer loop. This typically causes significant code bloat, which is why unrolling is normally disabled and left to the programmer. For those who want to experiment with this, I attach a C file with just the code in question. Compile this with your favorite compiler settings, and see what the compile generates. clang, on an x64 system, compiles the original loop into LBB0_2: ## =This Inner Loop Header: Depth=1 movzbl (%rdi), %eax movw%ax, (%rdx) incq%rdi addq$2, %rdx decq%rsi jne LBB0_2 and the unrolled loop into LBB1_2: ## %.lr.ph6 ## =This Inner Loop Header: Depth=1 movzbl (%rdi,%rcx), %r8d movw%r8w, (%rdx) movzbl 1(%rdi,%rcx), %r8d movw%r8w, 2(%rdx) movzbl 2(%rdi,%rcx), %r8d movw%r8w, 4(%rdx) movzbl 3(%rdi,%rcx), %r8d movw%r8w, 6(%rdx) addq$8, %rdx addq$4, %rcx cmpq%rax, %rcx jl LBB1_2 -- nosy: +loewis Added file: http://bugs.python.org/file23353/unroll.c ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch
Éric Araujo mer...@netwok.org added the comment: Note the existing test doesn't actually perform a build so the new test also doesn't, but it does check the core logic Sounds good to me. +def manifest_setup_ldargs I’d make all new methods private ones (i.e. leading underscore). an embedded manifests Typo: extra s return None if not temp_manifest else (temp_manifest, mfid) Using a ternary expression runs afoul of PEP 291: distutils should remain compatible with 2.3. (I’m not sure it is right now, we use modern unittest methods in tests and all, but it is no reason for making it worse in new code :) Your patch will also need an entry in Misc/NEWS; at first glance, there is no documentation file to edit. Will you port the patch to packaging in 3.3? I can do it if you don’t have the time, but I’m not set up yet to test on Windows, so I can ask you to test a patch. Also, for the distutils2 backport (which I can do too), we would need to run tests with all versions from 2.4 to 3.3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12436] Missing items in installation/setup instructions
Éric Araujo mer...@netwok.org added the comment: In addition to Notepad++ do you think it would be a good idea to at least mention Vim and Emacs with a disclaimer about the learning curve? No. If someone is looking at this page and doesn’t already have a text editor they’re familiar with, I think Notepad++ is the right tool to suggest. Do you think it would be a good idea to add instructions on how to add Python to the Path in Windows? The doc already has that somewhere, unless I misremember. Yes, but isn't there a script somewhere that does that already? One or more in Tools/scripts and maybe in PC or PCbuild too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12436 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13123] bdist_wininst uninstaller does not remove pycache directories
Éric Araujo mer...@netwok.org added the comment: I don’t have a Windows VM set up yet, but I can try to write a patch in the coming weeks and ask you to test it. Deal? -- stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13123 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3902] Packages containing only extension modules have to contain __init__.py
Éric Araujo mer...@netwok.org added the comment: We’re working on a patch on the core-mentorship list. I emailed the diff to the Core-Mentorship list, but since there was no reply I will just attach it here. I added that message here to avoid someone else working on the same bug. I did not reply to the mailing list because it’s not easy to review emailed patches and I don’t have Internet access each day. Please review patch and let me know if you want any changes. Done. You should have received an email; if not, follow the link titled “review” on the right of your patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3902 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch
Mark Hammond skippy.hamm...@gmail.com added the comment: Thanks for the review. One note: | +def manifest_setup_ldargs | I’d make all new methods private ones (i.e. leading underscore). They aren't strictly private and are designed to be overridden by subclasses (although in practice, subclassing the compiler is much harder than it should be, so pywin32 monkey-patches the instance.) This is actually the entire point of my updated patch - to give setup.py authors some level of control over the manifest behaviour. I do intend forward-porting to 3.3 and also to check it is is too late for 3.2 (a quick check before implied it might be OK, but I'm not sure) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch
Éric Araujo mer...@netwok.org added the comment: They aren't strictly private and are designed to be overridden by subclasses OK. I do intend forward-porting to 3.3 and also to check it is is too late for 3.2 (a quick check before implied it might be OK, but I'm not sure) 2.7 and 3.2 are open for bug fixes, as indicated by the versions field of this bug (it’s actually a matrix: component distutils + versions 2.7, 3.2, 3.3, component distutils2 + version 3.3 == packaging and distutils2 + third-party == the distutils2 backport :) -- assignee: tarek - mhammond ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used for 'runtime_library_dirs'
Éric Araujo mer...@netwok.org added the comment: This was fixed in 2.7 and 3.2; no luck for 3.1. -- resolution: accepted - fixed stage: - committed/rejected status: open - closed versions: +Python 2.7, Python 3.2 -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6164 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10945] bdist_wininst depends on MBCS codec, unavailable on non-Windows
Éric Araujo mer...@netwok.org added the comment: haypo: Can't you only work with Unicode and avoid the MBCS encoding? It is not code under the users’ control (i.e. setup.py) that uses MBCS, but the bdist_wininst command itself. It used to be runnable from linux, which is great to provide binary installers for Windows users who typically don’t have a compiler. This is what the bug is about. -- versions: -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10945 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11638] pysetup un sdist crashes with weird trace if version is unicode by accident
Éric Araujo mer...@netwok.org added the comment: Does someone want to write a test for this? We have examples of creating tarball sdists in Lib/distutils/tests/test_sdist.py, one would just need to copy one example and use a version with a unicode version. -- keywords: +easy resolution: remind - versions: +Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11638 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12967] IDLE RPC Proxy for standard IO streams lacks 'errors' attribute
Ned Deily n...@acm.org added the comment: I don't have a strong opinion about whether running setup.py in IDLE is supported. But that's not the real issue here. The problem is that the IDLE RPC proxy of the standard IO streams is incomplete, in particular, the 'errors' attribute of io.TextIOWrapper streams. Looking back, it appears that the `errors` attribute was added to file objects and io streams in 2.6 but support for that was not added to IDLE. I think that should be fixed. -- assignee: eric.araujo - ned.deily components: +IDLE -Distutils resolution: wont fix - stage: committed/rejected - needs patch status: closed - open title: AttributeError distutils\log.py - IDLE RPC Proxy for standard IO streams lacks 'errors' attribute versions: +Python 2.7, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12967 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12967] IDLE RPC Proxy for standard IO streams lacks 'errors' attribute
Changes by Éric Araujo mer...@netwok.org: -- nosy: -eric.araujo, tarek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12967 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
