[issue3613] base64.encodestring does not actually accept strings
New submission from Dmitry Dvoinikov [EMAIL PROTECTED]: This quote from base64.py: --- bytes_types = (bytes, bytearray) # Types acceptable as binary data ... def encodestring(s): Encode a string into multiple lines of base-64 data. Argument and return value are bytes. if not isinstance(s, bytes_types): raise TypeError(expected bytes, not %s % s.__class__.__name__) ... --- shows that encodestring method won't accept str for an argument, only bytes. Perhaps this is by design, but then wouldn't it make sense to change the name of the method ? Anyway, this behavior clashes in (the least I know) xmlrpc.client, line 1168 when basic authentication is present: --- auth = base64.encodestring(urllib.parse.unquote(auth)) --- because unquote() returns str, not bytes. -- components: Library (Lib) messages: 71513 nosy: ddvoinikov severity: normal status: open title: base64.encodestring does not actually accept strings type: behavior versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3613 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1276] LookupError: unknown encoding: X-MAC-JAPANESE
Changes by Hye-Shik Chang [EMAIL PROTECTED]: Added file: http://bugs.python.org/file11170/cjkmactemporary.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1276 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3614] typo in xmlrpc.client
New submission from Dmitry Dvoinikov [EMAIL PROTECTED]:
In xmlrpc.client:1204:
---
headers = {}
if extra_headers:
for key, val in extra_headers:
header[key] = val
---
shouldn't it read
---
headers[key] = val
^
---
?
Otherwise it bails out with
---
NameError: global name 'header' is not defined
---
--
components: Library (Lib)
messages: 71514
nosy: ddvoinikov
severity: normal
status: open
title: typo in xmlrpc.client
type: behavior
versions: Python 3.0
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3614
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3609] does parse_header really belong in CGI module?
Bill Janssen [EMAIL PROTECTED] added the comment: I imagine if they were moved (at least for a few versions) the old ones would still work, with a deprecation warning? Yes, that's what I was thinking. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2834] re.IGNORECASE not Unicode-ready
Mark Summerfield [EMAIL PROTECTED] added the comment: On 2008-08-19, Antoine Pitrou wrote: Antoine Pitrou [EMAIL PROTECTED] added the comment: Fixed in r65860. Someone should check the docs though (at least try to generate them, and review my changes a bit since English isn't my mother tongue). I've revised the ASCII and LOCALE-related texts in re.rst in r65903. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2834 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2834] re.IGNORECASE not Unicode-ready
Mark Summerfield [EMAIL PROTECTED] added the comment: On 2008-08-19, Antoine Pitrou wrote: Antoine Pitrou [EMAIL PROTECTED] added the comment: Fixed in r65860. Someone should check the docs though (at least try to generate them, and review my changes a bit since English isn't my mother tongue). And two more (tiny) fixes in r65904; that's my lot:-) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2834 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3615] Expect methods for testing.
New submission from J. Pablo Fernández [EMAIL PROTECTED]: I'm attaching a patch that adds expect methods to TestCase. They are like fail methods, but they don't fail immediately. They are useful when you want to catch more than one error at a time. I included some tests. There are docstrings but more documentation might be needed. I'll gladly write it if/when the code is good to go. The original code was written by Donovan Baarda for an internal project at Google, I only extracted the bits that made sense to publish and changed the style to me more Python-alike. -- components: Library (Lib) files: expect.diff keywords: patch messages: 71518 nosy: pupeno severity: normal status: open title: Expect methods for testing. versions: Python 3.0 Added file: http://bugs.python.org/file11171/expect.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3615 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2834] re.IGNORECASE not Unicode-ready
Antoine Pitrou [EMAIL PROTECTED] added the comment: Thanks a lot Mark! ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2834 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3607] test_multiprocessing failure (Unserializable message)
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Sorry, I did not notice the failure because test_multiprocessing have other problems on Windows. r65905 restores part of the copy_reg calls, just enough to let the tests pass. I am working on the proper fix, which is to use the custom pickler in connection.h::connection_send_obj(), instead of the standard pickle.dumps(). -- nosy: +amaury.forgeotdarc ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3607 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3616] shutil.rmtree() fails on invalid filename
New submission from STINNER Victor [EMAIL PROTECTED]:
If the directory contains invalid filenames (invalid in the system
charset), an exception is raised by os.path.join() used by
shutil.rmtree():
fullname = os.path.join(path, name)
File /home/haypo/prog/py3k/Lib/posixpath.py, line 64, in join
if b.startswith('/'):
TypeError: expected an object with the buffer interface
name is an bytes object, not a str object. My system charset is utf-8.
Example to reproduce the problem:
mkdir x
# create a file with an invalid name
touch -- $(echo -e 'x/--\0250--')
python -c import shutils; shutil.rmtree('x')
= TypeError: expected an object with the buffer interface
--
components: Library (Lib)
messages: 71521
nosy: haypo
severity: normal
status: open
title: shutil.rmtree() fails on invalid filename
versions: Python 3.0
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3616
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3611] invalid exception context
Antoine Pitrou [EMAIL PROTECTED] added the comment: I also noticed a crash in PyErr_SetObject(): in block line 68..86, tstate-exc_value value may changes and so it's possible that tstate-exc_value becomes NULL. How can tstate-exc_value become NULL at that point? Could you investigate? -- nosy: +pitrou ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3603] trivial typo in Include/pymath.h
Santiago Gala [EMAIL PROTECTED] added the comment: Notice the typo is still in a number of branches/tags (I know, tags should be static, but nothing impedes committing into a subversion tag once it is created, so I quote for reference): [EMAIL PROTECTED] ~/newcode/python.git (py3k)$ for i in $(git branch -a| sed -e s/\*//); do if git rev-parse --verify $i:Include/pymath.h /dev/null ;then PAGER= git grep doube $i:Include/pymath.h 2/dev/null ; fi; done benjaminp-testing:Include/pymath.h:extern double copysign(doube, double); okkoto-sizeof:Include/pymath.h:extern double copysign(doube, double); py3k-ctypes-pep3118:Include/pymath.h:extern double copysign(doube, double); py3k-urllib:Include/pymath.h:extern double copysign(doube, double); tags/r26a3:Include/pymath.h:extern double copysign(doube, double); tags/r26b1:Include/pymath.h:extern double copysign(doube, double); tags/r26b2:Include/pymath.h:extern double copysign(doube, double); tags/r30a5:Include/pymath.h:extern double copysign(doube, double); tags/r30a5-real:Include/pymath.h:extern double copysign(doube, double); tags/[EMAIL PROTECTED]:Include/pymath.h:extern double copysign(doube, double); tags/r30b1:Include/pymath.h:extern double copysign(doube, double); tags/r30b2:Include/pymath.h:extern double copysign(doube, double); tlee-ast-optimize:Include/pymath.h:extern double copysign(doube, double); tnelson-trunk-bsddb-47-upgrade:Include/pymath.h:extern double copysign(doube, double); trunk-math:Include/pymath.h:extern double copysign(doube, double); I just paste the list because I can't say which branches are currently active or suitable to be retaken in the future. The origin of the typo is in trunk-math. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3603 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3616] shutil.rmtree() fails on invalid filename
Antoine Pitrou [EMAIL PROTECTED] added the comment: This is certainly a consequence of #3187, which is very high priority but also very difficult to find a satisying solution to. -- nosy: +pitrou resolution: - duplicate status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3616 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3187] os.listdir can return byte strings
Antoine Pitrou [EMAIL PROTECTED] added the comment: See #3616 for a consequence of this. -- nosy: +haypo ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3187 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3616] shutil.rmtree() fails on invalid filename
Changes by Antoine Pitrou [EMAIL PROTECTED]: -- superseder: - os.listdir can return byte strings ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3616 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3608] memoryview constructor has no deallocator
Antoine Pitrou [EMAIL PROTECTED] added the comment: Well, this is not a bug in itself. Memoryview objects are designed to give access to a memory area backed by another object - they don't own the memory by themselves (in the sense that you e.g. own a reference to a PyObject). Please note by the way that the Py_buffer struct now has a reference to the original object, the obj field. PyBuffer_FillInfo() will incref it, and PyBuffer_Release() will decref it again. However, it you set this field to NULL, you are responsible for doing your own reference management. I agree that it may be nice to support your use case, but I'm not sure what the semantics should be. For clarity, perhaps it should be a derived class of memoryview. -- type: resource usage - feature request ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3608 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3608] memoryview constructor has no deallocator
Changes by Antoine Pitrou [EMAIL PROTECTED]: -- priority: - normal ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3608 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3617] Add MS EULA to the list of third-party licenses in the Windows installer
New submission from Marc-Andre Lemburg [EMAIL PROTECTED]: Since we are shipping the msvcr90.dll (+ assemblies) together with the Python installer for Windows, we need to include the MS EULA for VS2008 in the third-party licenses section as this is the license that covers the VS DLLs. -- messages: 71527 nosy: lemburg severity: normal status: open title: Add MS EULA to the list of third-party licenses in the Windows installer versions: Python 2.6, Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3617 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3617] Add MS EULA to the list of third-party licenses in the Windows installer
Marc-Andre Lemburg [EMAIL PROTECTED] added the comment: Note that there are a few gotchas in the MS EULA, such as disallowing to ship the DLLs with GPLed Python products or requiring that the PSF prevents further redistribution of the DLLs unless used in conjunction with Python. -- priority: - critical ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3617 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3615] Expect methods for testing.
Antoine Pitrou [EMAIL PROTECTED] added the comment: Interesting, but it should be discussed on the mailing-list first. Also, since this is a new feature, it must be retargeted to 2.7/3.1. -- nosy: +pitrou priority: - normal type: - feature request versions: +Python 2.7, Python 3.1 -Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3615 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Antoine Pitrou [EMAIL PROTECTED] added the comment: There's an unquote()-related failure in #3613. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3613] base64.encodestring does not actually accept strings
Antoine Pitrou [EMAIL PROTECTED] added the comment: The encodestring() function is refered to in the docs as the legacy interface. Perhaps it should be simply deprecated in 3.0? -- assignee: - georg.brandl components: +Documentation nosy: +georg.brandl, pitrou priority: - high ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3613 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3613] base64.encodestring does not actually accept strings
Matt Giuca [EMAIL PROTECTED] added the comment: Hi Dmitry, RE the method behaviour: I think it probably is correct to NOT accept a string. Given that it's base64 encoding it, it only makes sense to encode bytes, not arbitrary Unicode characters which have no well-defined binary representation. RE the method name: I agree, it should be renamed to encodestring. I argued a similar case for the array.tostring and fromstring methods (which actually act on bytes in Python 3.0) - here: http://bugs.python.org/issue3565. So far nobody replied on that issue; I think it may be too late to rename them. Best we can do is document them. RE xmlrpc.client:1168. We just checked in a patch to urllib which adds an unquote_to_bytes function (see http://docs.python.org/dev/3.0/library/urllib.parse.html#urllib.parse.unquote_to_bytes). (Unquote itself still returns a string). It should be correct to just change xmlrpc.client:1168 to call urllib.parse.unquote_to_bytes. (Though I've not tested it). -- nosy: +mgiuca ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3613 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3300] urllib.quote and unquote - Unicode issues
Matt Giuca [EMAIL PROTECTED] added the comment: Thanks for pointing that out, Antoine. I just commented on that bug. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3612] Add some basic mssing types in ctypes.wintypes
Thomas Heller [EMAIL PROTECTED] added the comment: I have no objections against this patch - feel free to check it in if it is not too late before the beta. Also I think that LPDWORD and friends are a good idea, you should extend the patch with them. -- assignee: theller - ocean-city resolution: - accepted ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3612 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3613] base64.encodestring does not actually accept strings
Matt Giuca [EMAIL PROTECTED] added the comment: it should be renamed to encodestring Huh ? It is already called that :) Um ... yes. I mean encodebytes :) Best we can do is document them. Oh well. But I don't know the rules. People are saying things like no new features after beta3 but I take it that backwards-compatibility-breaking changes are included in this. But maybe it's still OK for us to break code after the beta. Perhaps someone involved in the release can comment on this issue (and hopefully with a view to my array patch - http://bugs.python.org/issue3565 - as well). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3613 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3618] possible deadlock in IO library (Lib/io.py)
New submission from STINNER Victor [EMAIL PROTECTED]:
BufferedWriter from Lib/io.py is thread-safe, but... the Python
instruction with self._write_lock: could be interrupted when the
lock is already acquired. Especially, _lsprof.Profiler() uses ceval
hook and is called when the lock is acquired. But if the profiler (or
any other module using the hook) re-use the stream (stdout or stderr),
we get a deadlock!?
Well, this problem is really not critical since only developers
profilers (really?).
Solution: use C implementation of Lib/io.py (from Python 2.6) to avoid
ceval hook?
Example with py3k trunk:
import _lsprof
prof=_lsprof.Profiler(42)
prof.enable()
# _lsprof calls 42()
# - 42 is not callable
# - call PyErr_WriteUnraisable(42 is not callable)
# - deadlock
Traceback example:
#6 0x080ecb30 in PyThread_acquire_lock (lock=0x820f550, waitflag=1)
at Python/thread_pthread.h:352
(...)
#8 0x08162521 in PyCFunction_Call (func=0x83abfbc, arg=0xb7dc6034,
kw=0x0) at Objects/methodobject.c:81
#9 0x080b3659 in call_function (pp_stack=0xbfbf9474, oparg=0) at
Python/ceval.c:3403
#10 0x080ae7a6 in PyEval_EvalFrameEx (f=0x83b9f94, throwflag=0) at
Python/ceval.c:2205
#11 0x080b3aae in fast_function (func=0x83a25b4, pp_stack=0xbfbf9724,
n=2, na=2, nk=0) at Python/ceval.c:3491
#12 0x080b37ef in call_function (pp_stack=0xbfbf9724, oparg=1) at
Python/ceval.c:3424
#13 0x080ae7a6 in PyEval_EvalFrameEx (f=0x83b981c, throwflag=0) at
Python/ceval.c:2205
#14 0x080b1aee in PyEval_EvalCodeEx (co=0x838a328, globals=0x8330534,
locals=0x0, args=0x8373da0, argcount=2, kws=0x0, kwcount=0, defs=0x0,
defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:2840
#15 0x0814ab2e in function_call (func=0x83a3b8c, arg=0x8373d8c,
kw=0x0) at Objects/funcobject.c:628
#16 0x08118d19 in PyObject_Call (func=0x83a3b8c, arg=0x8373d8c,
kw=0x0) at Objects/abstract.c:2181
#17 0x08132eb0 in method_call (func=0x83a3b8c, arg=0x8373d8c, kw=0x0)
at Objects/classobject.c:323
#18 0x08118d19 in PyObject_Call (func=0x83037dc, arg=0x83141f4,
kw=0x0) at Objects/abstract.c:2181
#19 0x080b2ed8 in PyEval_CallObjectWithKeywords (func=0x83037dc,
arg=0x83141f4, kw=0x0) at Python/ceval.c:3283
#20 0x08141779 in PyFile_WriteObject (v=0x8398e28, f=0x83ab0dc,
flags=1) at Objects/fileobject.c:164
#21 0x08141974 in PyFile_WriteString (s=0x819a2f2 Exception ,
f=0x83ab0dc) at Objects/fileobject.c:189
#22 0x080c473c in PyErr_WriteUnraisable (obj=0x81fbd78) at
Python/errors.c:696
#23 0xb7f9612f in CallExternalTimer (pObj=0x83a7aa8)
at /home/haypo/prog/py3k/Modules/_lsprof.c:135
#24 0xb7f96984 in Stop (pObj=0x83a7aa8, self=0x826c6d8,
entry=0x826ec80) at /home/haypo/prog/py3k/Modules/_lsprof.c:337
#25 0xb7f96c60 in ptrace_leave_call (self=0x83a7aa8, key=0x81cb150)
at /home/haypo/prog/py3k/Modules/_lsprof.c:420
#26 0xb7f96d5c in profiler_callback (self=0x83a7aa8, frame=0x835a0b4,
what=6, arg=0x83ab92c) at /home/haypo/prog/py3k/Modules/_lsprof.c:471
#27 0x080b28cb in call_trace (func=0xb7f96c85 profiler_callback,
obj=0x83a7aa8, frame=0x835a0b4, what=6, arg=0x83ab92c)
at Python/ceval.c:3090
#28 0x080b35da in call_function (pp_stack=0xbfbf9d74, oparg=1) at
Python/ceval.c:3403
#29 0x080ae7a6 in PyEval_EvalFrameEx (f=0x835a0b4, throwflag=0) at
Python/ceval.c:2205
ceval hook: Python/ceval.3403:
PCALL(PCALL_CFUNCTION);
if (flags (METH_NOARGS | METH_O)) {
...
} else {
PyObject *callargs;
callargs = load_args(pp_stack, na);
READ_TIMESTAMP(*pintr0);
C_TRACE(x, PyCFunction_Call(func,callargs,NULL)); = **here**
READ_TIMESTAMP(*pintr1);
Py_XDECREF(callargs);
}
--
components: Library (Lib)
messages: 71537
nosy: haypo
severity: normal
status: open
title: possible deadlock in IO library (Lib/io.py)
type: crash
versions: Python 3.0
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3618
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3618] possible deadlock in IO library (Lib/io.py)
Antoine Pitrou [EMAIL PROTECTED] added the comment:
Yes indeed. We could use an RLock to avoid the problem but RLock's are
damn slow since they are written in pure Python (see #3001). Rewriting
the critical parts of RLock (constructor, acquire(), release(),
__enter__(), __exit__()) in C should not be too complicated, would you
want to do it? :)
Solution: use C implementation of Lib/io.py (from Python 2.6) to avoid
ceval hook?
I guess it's out of question. However, Buffered{Reader,Writer,Random}
should be rewritten in C one day, it is necessary for speed. Then the
problem will vanish since a lock will only need to be taken when
releasing the GIL, that is not when Python code is being interpreted.
--
nosy: +pitrou
priority: - high
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3618
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3612] Add some basic mssing types in ctypes.wintypes
Hirokazu Yamamoto [EMAIL PROTECTED] added the comment: I've committed basic type addition in r65908. Addition of LPDWORD and its friends will follow. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3612 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3001] RLock's are SLOW
STINNER Victor [EMAIL PROTECTED] added the comment: As suggested by pitrou, I wrote an implementation of RLock in C. Changes to Python version: - no debug message: i leave the message in #if 0 ... #endif - acquire() method argument blocking is not a keyword Notes: - RLock has no docstring! - In the Python version, RLock._release_save() replaces owner and counter attributes before release the lock. But releasing the lock may fails and no the object is in an inconsistent state -- keywords: +patch nosy: +haypo Added file: http://bugs.python.org/file11172/rlock.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3618] possible deadlock in IO library (Lib/io.py)
STINNER Victor [EMAIL PROTECTED] added the comment: @pitrou: I wrote an implementation of RLock in C (see #3001). So it would be possible to use threading.RLock instead of threading.Lock ;-) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3618 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3619] A more informative message for ImportError
New submission from Kent Tenney [EMAIL PROTECTED]: from foo import bar ImportError: cannot import name bar The error may be due to the wrong 'foo' being found, some investigation is required. If the the ImportError message included the filename for 'foo', the problem would be obvious. ImportError cannot import name bar from /usr/lib/snip/foo.pyc A c.l.p. thread on this is at http://groups.google.com/group/comp.lang.python/browse_thread/thread/88474a32877026fc/ a patch from Wojtek Walczak is here and attached http://www.stud.umk.pl/~wojtekwa/patches/from-import-py2.5.1.patch a thread about it on python-dev is here http://mail.python.org/pipermail/python-dev/2008-August/081889.html including a comment on the patch http://mail.python.org/pipermail/python-dev/2008-August/081897.html -- components: None files: from-import-py2.5.1.patch keywords: patch messages: 71542 nosy: ktenney severity: normal status: open title: A more informative message for ImportError type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file11173/from-import-py2.5.1.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3619 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3618] possible deadlock in IO library (Lib/io.py)
STINNER Victor [EMAIL PROTECTED] added the comment: Oops, I forgot to update PyInit__Thread() with my new time: - Add PyType_Ready() - Register RLockType to threading dict Here is the new patch -- keywords: +patch Added file: http://bugs.python.org/file11174/rlock.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3618 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3619] A more informative message for ImportError
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- components: +Interpreter Core -None priority: - low versions: +Python 3.1 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3619 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3001] RLock's are SLOW
STINNER Victor [EMAIL PROTECTED] added the comment: Oops, I forgot to update PyInit__Thread() with my new time: - Add PyType_Ready() - Register RLockType to threading dict Here is the new patch. Added file: http://bugs.python.org/file11175/rlock-v2.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3618] possible deadlock in IO library (Lib/io.py)
Changes by STINNER Victor [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file11174/rlock.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3618 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3618] possible deadlock in IO library (Lib/io.py)
STINNER Victor [EMAIL PROTECTED] added the comment: Ooops again, I uploaded my patch to the wrong issue! The new patch is now in the issue #3001. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3618 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3001] RLock's are SLOW
Antoine Pitrou [EMAIL PROTECTED] added the comment: Wow, that was quick. Did you try to replace threading.RLock with your implementation, and run the tests? By the way: - acquire() method argument blocking is not a keyword - In the Python version, RLock._release_save() replaces owner and counter attributes before release the lock. But releasing the lock may fails and no the object is in an inconsistent state Removing the debugging statements is fine, but apart from that the C implementation should mimick the current behaviour. Even if this behaviour has potential pitfalls. Speaking of which, it would be nice if RLock was subclassable. I don't know whether any software relies on this though. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3612] Add some basic mssing types in ctypes.wintypes
Hirokazu Yamamoto [EMAIL PROTECTED] added the comment: I've created the patch which adds LPDWORD and friends. Can you review it? Added file: http://bugs.python.org/file11176/adds_LPDWORD_and_friends.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3612 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3611] invalid exception context
STINNER Victor [EMAIL PROTECTED] added the comment: How can tstate-exc_value become NULL at that point? [error.c:86] Could you investigate? PyEval_CallObject(exception, args) may calls PyErr_SetObject(). Since the same thread state is the same, tstate-exc_value also changes during this call. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3620] test_asyncore is not cleanup after its self?
New submission from Benjamin Peterson [EMAIL PROTECTED]: This is from the sparc Unbuntu 3.0 bot. I'm having trouble reproducing it, though. test test_smtplib produced unexpected output: ** *** line 2 of actual output doesn't appear in expected output after line 1: + error: uncaptured python exception, closing channel test.test_smtplib.SimSMTPChannel 127.0.0.1:38832 at 0x268d0a8 (class 'socket.error':[Errno 9] Bad file descriptor [/home/pybot/buildarea/3.0.klose-ubuntu-sparc/build/Lib/asyncore.py|readwrite|100] [/home/pybot/buildarea/3.0.klose-ubuntu-sparc/build/Lib/asyncore.py|handle_write_event|426]) ** -- components: Tests messages: 71549 nosy: benjamin.peterson priority: critical severity: normal status: open title: test_asyncore is not cleanup after its self? versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3620 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3613] base64.encodestring does not actually accept strings
Guido van Rossum [EMAIL PROTECTED] added the comment: Did someone fix xmlrpc.client:1168 yet? IMO it's okay to add encodebytes(), but let's leave encodestring() around with a deprecation warning, since it's so late in the release cycle. -- nosy: +gvanrossum ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3613 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3611] invalid exception context
Antoine Pitrou [EMAIL PROTECTED] added the comment: Selon STINNER Victor [EMAIL PROTECTED]: How can tstate-exc_value become NULL at that point? [error.c:86] Could you investigate? PyEval_CallObject(exception, args) may calls PyErr_SetObject(). Since the same thread state is the same, tstate-exc_value also changes during this call. Hmm, indeed. However, I don't see why your Python code triggers that. Does instantiating the ProcError object somehow fail, and for what reason? Or did you witness it in other circumstances? As for the original problem (tstate-exc_traceback points to a zombi object) it would be nice to have a small snippet of Python code to reproduce it. Is it possible for you to do that? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3611] invalid exception context
Antoine Pitrou [EMAIL PROTECTED] added the comment: I retract what I said above. PyErr_SetObject() and friends only change tstate-curexc_* variables, not tstate-exc_*. The former (tstate-curexc_*) contain the current, pending (uncaught) exception state of the thread. The latter (tstate-exc_*) contain the exception currently handled by an except statement in Python code. So, theoretically, there is no way calling PyEval_CallObject() can change tstate-exc_value: - if it raises an exception or calls code that raises an exception without catching it, the exception ends up in tstate-curexc_*, not in tstate-exc_* - if it calls code that raises an exception /and catches it/, exception stacking means the exception should be discarded after the end of the except block and the last tstate-exc_* values restored. Of course, there may be bugs in the implementation of the above. The best way to find out would be to have a small snippet of Python code reproducing the problem. :-) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3611] invalid exception context
STINNER Victor [EMAIL PROTECTED] added the comment: About the PyEval_CallObject() call in errors.c, here is an example: Call exception0x81dcee0(args0x8751dc4) with exception= object : class 'AttributeError' type: type refcount: 6 address : 0x81dcee0 and args= object : (type object 'ProcError' has no attribute '__subclasscheck__',) type: tuple refcount: 1 address : 0x8751dc4 This exception may comes from PyObject_IsSubclass() which calls PyObject_GetAttr(cls, __subclasscheck__). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3621] it would be nice if installers made by bdist_wininst stored an EstimatedSize property in the Windows registry
New submission from Jason Spiro [EMAIL PROTECTED]: == Summary == Installers made by bdist_wininst never set EstimatedSize in the Windows registry. So Windows makes an estimate[1] of the installed software's size so the Add/Remove Programs control panel can tell users how much space the software is are taking up. Windows overestimates the size: it estimates the size as equal to the size of the entire C:\Python directory. Nowadays, disk space is cheaper than ever, so I assume it's uncommon for people to try to uninstall software to gain space back. So I do not think it's worth fixing this bug. Does anyone think it *is* worth fixing? == Steps to repro == You *must* be running Windows XP or higher to repro this.[2] I used Python 2.5 (which I installed using the MSI installer) but I would be extremely surprised if this was already fixed in a newer Python's distutils. - Download the attached testcase.zip - Unzip it to a temp directory - From the temp directory, run the commands: setup.py bdist_wininst cd dist foo-1.0.win32.exe - Click on Start Menu Settings Control Panel Add/Remove Programs - Scroll down to Python 2.5 foo-1.0. == Actual results == - The Size column on the right says 46.86MB (that's the size of my entire C:\Python 2.5 directory.) == Expected results == - The Size column on the right should say something close to 0.1 megabytes. == Suggested fix == - When creating an installer, bdist_wininst should look at the total size of all files to install, multiply that number by 3 (a reasonable estimate of the total size the .pyc and .pyo files will take up), and make the installer set the EstimatedSize[3] in the registry to that number. == Footnotes == ^ [1]. See the blog entry How does Add/Remove Programs get the size and other information? by Raymond Chen at http://blogs.msdn.com/oldnewthing/archive/2004/07/09/178342.aspx for info on the algorithm Windows uses. ^ [2]. Versions of Windows older than XP never try to estimate the size of installed programs. ^ [3]. This is HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\(application descriptor)\EstimatedSize and should be a DWORD representing the number of kilobytes the software takes up, according to http://forum.installsite.net/?showtopic=698#entry12501 -- components: Distutils messages: 71554 nosy: jasonspiro severity: normal status: open title: it would be nice if installers made by bdist_wininst stored an EstimatedSize property in the Windows registry type: feature request ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3621 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3565] array documentation, method names not 3.0 compliant
Matt Giuca [EMAIL PROTECTED] added the comment: A similar issue came up in another bug (http://bugs.python.org/issue3613), and Guido said: IMO it's okay to add encodebytes(), but let's leave encodestring() around with a deprecation warning, since it's so late in the release cycle. I think that's probably wise RE this bug as well - my original suggestion to REPLACE tostring/fromstring with tobytes/frombytes was probably a bit over-zealous. I'll have another go at this during some spare cycles tomorrow - basically taking my current patch and adding tostring/fromstring back in, to call tobytes/frombytes with deprecation warnings. Does this sound like a good plan? (Also policy question: When you have deprecated functions, how do you document them? I assume you say deprecated in the docs; is there a standard template for this?) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3565 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3621] it would be nice if installers made by bdist_wininst stored an EstimatedSize property in the Windows registry
Jason Spiro [EMAIL PROTECTED] added the comment: Attaching testcase. It's basically just some sample code from the distutils documentation. Added file: http://bugs.python.org/file11177/testcase.zip ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3621 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3611] invalid exception context
Antoine Pitrou [EMAIL PROTECTED] added the comment: [...] This exception may comes from PyObject_IsSubclass() which calls PyObject_GetAttr(cls, __subclasscheck__). If you look at the code for PyObject_IsSubclass(), there is a pair of PyErr_Fetch / PyErr_Restore calls around PyObject_GetAttr(cls, __subclasscheck__). So this exception should vanish immediately rather than stay around. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3611] invalid exception context
STINNER Victor [EMAIL PROTECTED] added the comment: I'm unable to write a short Python script to reproduce the bug. So download the full program: http://neudorf.hachoir.org/tmp/fusil3000.tar.gz Run in with: $ gdb python3.0 (gdb) run fusil-python --fast ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3617] Add MS EULA to the list of third-party licenses in the Windows installer
Changes by Thomas Heller [EMAIL PROTECTED]: -- nosy: +theller ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3617 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1675334] Draft implementation for PEP 364
Brett Cannon [EMAIL PROTECTED] added the comment: At this point we should probably just have PEP 364 rejected since 2to3 handles the renamings so well. -- assignee: brett.cannon - barry ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1675334 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3602] Move test.test_suport.catch_warning() to the 'warnings' module
Brett Cannon [EMAIL PROTECTED] added the comment: Just some quick notes on this. The decorator should become: def catchwarning(*, record=False, using=warnings) Name change is to follow the naming convention in 'warnings' (even though I prefer underscores). The 'using' argument is what module is being used as the 'warnings' module (mostly just for testing warings/_warnings). And they are both keyword-only (or at least in spirit in 2.6) so that the potential to support properly dealing with __warningregistry__ in the future can be added and the *args arguments can be those modules to watch. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3602] Move test.test_suport.catch_warning() to the 'warnings' module
Benjamin Peterson [EMAIL PROTECTED] added the comment: I don't think the using argument should live in warnings; it's too test specific. I recommend we still keep a catch_warning in test_support (or even just test_warnings since this seems to be the only use-case). -- nosy: +benjamin.peterson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3608] memoryview constructor has no deallocator
Roger Upole [EMAIL PROTECTED] added the comment: As background, what I need is an equivalent of PyBuffer_New(size), which creates an object that manages its own buffer memory, and is not based on another object at all. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3608 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3608] memoryview constructor has no deallocator
Antoine Pitrou [EMAIL PROTECTED] added the comment: As background, what I need is an equivalent of PyBuffer_New(size), which creates an object that manages its own buffer memory, and is not based on another object at all. Well, you can create either a bytes or bytearray object with an internal buffer of the desired length. Then you'll be able to create a memoryview out of it. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3608 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3001] RLock's are SLOW
Gregory P. Smith [EMAIL PROTECTED] added the comment: I doubt subclassability of RLock matters but who knows, people do code things. Regardless, using a C version wrapped in a simple python container class that calls the underlying C implementation's methods should be sufficient to allow sub-classing. Given the final 2.6 beta is scheduled for today, this won't make it into 2.6/3.0 so we've got some time to polish up what we want. -- versions: +Python 2.7, Python 3.1 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3612] Add some basic mssing types in ctypes.wintypes
Thomas Heller [EMAIL PROTECTED] added the comment: I think this is too fancy. I would prefer to spell the definitions out like this: LPDWORD = PDWORD = POINTER(DWORD) LPCSTR = LPSTR = c_wchar_p We could avoid the giant __all__ list when we 'import ctypes as _ctypes' and write (for example): DWORD = _ctypes.c_ulong ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3612 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1674032] Make threading.Event().wait(timeout=3) return isSet
Adam Milner [EMAIL PROTECTED] added the comment: I would like to add my support for this change. As David described, it is often useful to know why the x.wait() has returned, not just that it has. -- nosy: +carmiac ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1674032 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3608] memoryview constructor has no deallocator
Roger Upole [EMAIL PROTECTED] added the comment: Aha, thanks. I'll go that route for now. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3608 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3001] RLock's are SLOW
Antoine Pitrou [EMAIL PROTECTED] added the comment: Gregory, would you have an advice on #3618? -- versions: -Python 2.6, Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3001 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3611] invalid exception context
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: The problem comes when PyErr_SetObject triggers garbage collection which runs python code (finalizers...). I could reproduce the crash several times, and each time garbage collection was triggered by the normalization of the exception (the call to PyEval_CallObject(exception, args)). An obvious fix is to save exc_value near the /* Implicit exception chaining */ comment. However, I fear that there are other places where exc_value is reset, and exception chaining may break in subtle ways. -- nosy: +amaury.forgeotdarc ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3611] invalid exception context
Antoine Pitrou [EMAIL PROTECTED] added the comment: The problem comes when PyErr_SetObject triggers garbage collection which runs python code (finalizers...). Mmmh, normally this shouldn't change the value of tstate-exc_value once that Python code returns. That's what exception stacking is for. Having a snippet deterministically reproducing the problem would really help in any case. An obvious fix is to save exc_value near the /* Implicit exception chaining */ comment. Well, it may be a fix for the crash but I'm not sure it makes the semantics correct. If tstate-exc_value was really changed, there is a reason and I'm not sure it should be ignored. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3612] Add some basic mssing types in ctypes.wintypes
Hirokazu Yamamoto [EMAIL PROTECTED] added the comment: We could avoid the giant __all__ list when we 'import ctypes as _ctypes' How about the attached patch avoid_giant_all.patch? Added file: http://bugs.python.org/file11178/avoid_giant_all.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3612 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3612] Add some basic mssing types in ctypes.wintypes
Hirokazu Yamamoto [EMAIL PROTECTED] added the comment: And avoid_giant_all_and_add_LPs.patch adds bunch of LP(C)s. I'm not sure all LP types are needed. (Especially handle types) Added file: http://bugs.python.org/file11179/avoid_giant_all_and_add_LPs.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3612 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue504152] rfc822 long header continuation broken
Kenneth Arnold [EMAIL PROTECTED] added the comment:
This issue still seems to be present in Python 2.5's email module.
feedparser.py line 444-445 says:
# XXX reconsider the joining of folded lines
lhdr = EMPTYSTRING.join(lastvalue)[:-1].rstrip('\r\n')
I think that should be something like:
lhdr = EMPTYSTRING.join(ln.rstrip('\r\n') for ln in lastvalue)[:-1])
The resulting headers still need a fair amount of massaging, though; why
not just use Header instances for the headers?
--
nosy: +kcarnold
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue504152
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3611] invalid exception context
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Having a snippet deterministically reproducing the problem would really help in any case. Here you are. Don't ask how I found this. The attached script, when run, prints (KeyError(), ValueError()) (KeyError(), None) The current exception context (tstate-exc_value) is lost when a generator is deleted, if it was paused inside a try block. This is the cause of the crash: the gc runs inside PyErr_SetObject and collects such a generator. Added file: http://bugs.python.org/file11180/lostcontext.py ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3611] invalid exception context
STINNER Victor [EMAIL PROTECTED] added the comment: It looks that the problem is that PyErr_SetObject() is not re-entrant. The crash occurs when PyErr_SetObject() is called (indirectly) by PyErr_SetObject(): tstate-exc_value value is changed (set to NULL). As noticed by amaury.forgeotdarc, the problem is linked to be garbage collector: the crash occurs when the garbage collector calls a destructor which will reuse PyErr_SetObject(). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3614] typo in xmlrpc.client
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Corrected as r65920. Thanks for the report! -- nosy: +amaury.forgeotdarc resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3614 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3602] Move test.test_suport.catch_warning() to the 'warnings' module
Brett Cannon [EMAIL PROTECTED] added the comment: On Wed, Aug 20, 2008 at 10:29 AM, Benjamin Peterson [EMAIL PROTECTED] wrote: Benjamin Peterson [EMAIL PROTECTED] added the comment: I don't think the using argument should live in warnings; it's too test specific. I recommend we still keep a catch_warning in test_support (or even just test_warnings since this seems to be the only use-case). But decoupling from the core code of the context manager for this is not straight-forward without mucking around in sys.modules and that is always a risky thing to do. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3602] Move test.test_suport.catch_warning() to the 'warnings' module
Benjamin Peterson [EMAIL PROTECTED] added the comment: On Wed, Aug 20, 2008 at 4:51 PM, Brett Cannon [EMAIL PROTECTED] wrote: Brett Cannon [EMAIL PROTECTED] added the comment: On Wed, Aug 20, 2008 at 10:29 AM, Benjamin Peterson [EMAIL PROTECTED] wrote: Benjamin Peterson [EMAIL PROTECTED] added the comment: I don't think the using argument should live in warnings; it's too test specific. I recommend we still keep a catch_warning in test_support (or even just test_warnings since this seems to be the only use-case). But decoupling from the core code of the context manager for this is not straight-forward without mucking around in sys.modules and that is always a risky thing to do. Why would you have to much around in sys.modules? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3602 ___ -- Cheers, Benjamin Peterson There's no place like 127.0.0.1. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3611] invalid exception context
STINNER Victor [EMAIL PROTECTED] added the comment:
Great job amaury! So in ceval, here is the block responsible to clear
the execution informations:
Index: Python/ceval.c
===
--- Python/ceval.c (révision 65915)
+++ Python/ceval.c (copie de travail)
@@ -2453,11 +2453,6 @@
if (b-b_type == EXCEPT_HANDLER) {
UNWIND_EXCEPT_HANDLER(b);
- if (why == WHY_EXCEPTION) {
- Py_CLEAR(tstate-exc_type);
- Py_CLEAR(tstate-exc_value);
-
Py_CLEAR(tstate-exc_traceback);
- }
continue;
}
UNWIND_BLOCK(b);
Without these 5 lines, the bug disappears and it looks (i tried few
tests) that CPython is still ok.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3611
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3602] Move test.test_suport.catch_warning() to the 'warnings' module
Brett Cannon [EMAIL PROTECTED] added the comment: On Wed, Aug 20, 2008 at 2:53 PM, Benjamin Peterson [EMAIL PROTECTED] wrote: Benjamin Peterson [EMAIL PROTECTED] added the comment: On Wed, Aug 20, 2008 at 4:51 PM, Brett Cannon [EMAIL PROTECTED] wrote: Brett Cannon [EMAIL PROTECTED] added the comment: On Wed, Aug 20, 2008 at 10:29 AM, Benjamin Peterson [EMAIL PROTECTED] wrote: Benjamin Peterson [EMAIL PROTECTED] added the comment: I don't think the using argument should live in warnings; it's too test specific. I recommend we still keep a catch_warning in test_support (or even just test_warnings since this seems to be the only use-case). But decoupling from the core code of the context manager for this is not straight-forward without mucking around in sys.modules and that is always a risky thing to do. Why would you have to much around in sys.modules? Well, the bulk of the code needs to live in 'warnings' for it to exist if the 'test' package is missing. So any differences need to come from the test.support version. Now the module argument is so that you can control exactly what module has its showwarnings() implementation changed without worrying about what 'warnings' is set in sys.modules and really mucking up the interpreter. But if this argument is missing then warnings.catchwarnings() will have to set warnings.showwarnings() blindly since it doesn't know what module object is being tested. So if I want that change to happen on another module, I need to change what module is in sys.modules, call the context manager, and then put it all back so that what I want happen occurs. That's why you would have to mess with sys.modules. =) The argument could be renamed '_using', but that just seems silly. And with it being considered keyword-only (and I will make it the last argument listed, then most people won't ever run into it. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3602] Move test.test_suport.catch_warning() to the 'warnings' module
Benjamin Peterson [EMAIL PROTECTED] added the comment: On Wed, Aug 20, 2008 at 5:03 PM, Brett Cannon [EMAIL PROTECTED] wrote: Well, the bulk of the code needs to live in 'warnings' for it to exist if the 'test' package is missing. So any differences need to come from the test.support version. Now the module argument is so that you can control exactly what module has its showwarnings() implementation changed without worrying about what 'warnings' is set in sys.modules and really mucking up the interpreter. But if this argument is missing then warnings.catchwarnings() will have to set warnings.showwarnings() blindly since it doesn't know what module object is being tested. So if I want that change to happen on another module, I need to change what module is in sys.modules, call the context manager, and then put it all back so that what I want happen occurs. Alternatively, you could just have another copy of catch_warning in test_warnings with the extra argument. That's why you would have to mess with sys.modules. =) The argument could be renamed '_using', but that just seems silly. And with it being considered keyword-only (and I will make it the last argument listed, then most people won't ever run into it. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3602 ___ ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3611] invalid exception context
Changes by Barry A. Warsaw [EMAIL PROTECTED]: -- priority: - release blocker ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3618] possible deadlock in IO library (Lib/io.py)
Changes by Barry A. Warsaw [EMAIL PROTECTED]: -- priority: high - deferred blocker ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3618 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3622] Slight documentation quirk for random.random
New submission from Allan Crooks [EMAIL PROTECTED]: The documentation for random.random function shows this: random() - x in the interval [0, 1). That should either be [0, 1] or (0, 1). -- assignee: georg.brandl components: Documentation messages: 71582 nosy: amc1, georg.brandl severity: normal status: open title: Slight documentation quirk for random.random type: behavior versions: Python 2.3, Python 2.4, Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3602] Move test.test_suport.catch_warning() to the 'warnings' module
Brett Cannon [EMAIL PROTECTED] added the comment: On Wed, Aug 20, 2008 at 3:05 PM, Benjamin Peterson [EMAIL PROTECTED] wrote: Benjamin Peterson [EMAIL PROTECTED] added the comment: Alternatively, you could just have another copy of catch_warning in test_warnings with the extra argument. Sure, but I am not about to support that much code duplication in Python code when it is purely just to shave off an argument that can be clearly documented. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3622] Slight documentation quirk for random.random
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: [0, 1) denotes an interval, not a python object; 0 is included, 1 is excluded. And it follows (one of) the standard syntax to express intervals: http://en.wikipedia.org/wiki/Interval_notation -- nosy: +amaury.forgeotdarc resolution: - invalid status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3622 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3602] Move test.test_suport.catch_warning() to the 'warnings' module
Benjamin Peterson [EMAIL PROTECTED] added the comment: All right. You win! :) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3602 ___ ___ 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
Heikki Toivonen [EMAIL PROTECTED] added the comment: I would think most people/applications want to know to which host they are talking to. The reason I am advocating adding a default check to the stdlib is because this is IMO important for security, and it is easy to get it wrong (I don't think I have it 100% correct in M2Crypto either, although I believe it errs on the side of caution). I believe it would be a disservice to ship something that effectively teaches developers to ignore security (like the old socket.ssl does). A TLS extension also allows SSL vhosts, so static IPs are no longer strictly necessary (this is not universally supported yet, though). ___ Python 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
[issue3611] invalid exception context
Benjamin Peterson [EMAIL PROTECTED] added the comment: Unfortunately, removing those lines causes a RuntimeError about exceeding the recursion limit for about 1/3 of the tests. -- nosy: +benjamin.peterson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3623] _json: fix raise_errmsg(), py_encode_basestring_ascii() and linecol()
New submission from STINNER Victor [EMAIL PROTECTED]: _json module of python 3.0 has some bugs. (a) [_json.c] raise_errmsg() calls json.decoder.errmsg() from Python module, but this function may fails. If it fails, error should be be set to NULL. Example: import _json _json.scanstring(bxxx, 1, xxx) Erreur de segmentation (core dumped) = json.decoder.errmsg() calls linecol() which raise an error on bxxx.index(\n). (b) [_json.c] py_encode_basestring_ascii() calls PyBytes_Check(rval) but rval can be NULL if ascii_escape_str() or ascii_escape_unicode() fails. Example: import _json _json.encode_basestring_ascii(bxx\xff) Erreur de segmentation (core dumped) (c) [Lib/json/decoder.py] linecol() doesn't support bytes, but it's called with bytes argument: see point (a). For an example, see point (a). -- components: Library (Lib) files: _json.patch keywords: patch messages: 71588 nosy: haypo severity: normal status: open title: _json: fix raise_errmsg(), py_encode_basestring_ascii() and linecol() type: crash versions: Python 3.0 Added file: http://bugs.python.org/file11181/_json.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3623 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3611] invalid exception context
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
Can you try with the following patch,
throwflag is specific to a generator being deleted.
Index: Python/ceval.c
===
--- Python/ceval.c (revision 65919)
+++ Python/ceval.c (working copy)
@@ -2453,7 +2453,7 @@
if (b-b_type == EXCEPT_HANDLER) {
UNWIND_EXCEPT_HANDLER(b);
- if (why == WHY_EXCEPTION) {
+ if (why == WHY_EXCEPTION !throwflag) {
Py_CLEAR(tstate-exc_type);
Py_CLEAR(tstate-exc_value);
Py_CLEAR(tstate-exc_traceback);
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3611
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3623] _json: fix raise_errmsg(), py_encode_basestring_ascii() and linecol()
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- assignee: - bob.ippolito nosy: +bob.ippolito ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3623 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3624] Null byte \0 not listed as a possible escape sequence
New submission from Matt Aasted [EMAIL PROTECTED]: In current, future and past documentation, the valid escape sequence \0 (equivalent to \x00) is missing from the list of possible escape sequences in the documentation. As far as I can tell, it is not a case covered by any of the other elements in the list, and is valid python though I have only tested current (2.5.2) for it. Current version can be found here: http://docs.python.org/ref/strings.html -- assignee: georg.brandl components: Documentation messages: 71590 nosy: georg.brandl, voket severity: normal status: open title: Null byte \0 not listed as a possible escape sequence versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3624 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3611] invalid exception context
Antoine Pitrou [EMAIL PROTECTED] added the comment:
And if it doesn't work, try the following instead:
if (why == WHY_EXCEPTION) {
PyObject *tmp1, *tmp2, *tmp3;
tmp1 = tstate-exc_type;
tmp2 = tstate-exc_value;
tmp3 = tstate-exc_traceback;
tstate-exc_type = NULL;
tstate-exc_value = NULL;
tstate-exc_traceback = NULL;
Py_XDECREF(tmp1);
Py_XDECREF(tmp2);
Py_XDECREF(tmp3);
}
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3611
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3611] invalid exception context
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: This last proposal does not correct the behaviour of lostcontext.py. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3611] invalid exception context
Benjamin Peterson [EMAIL PROTECTED] added the comment: Here's Amaury's patch and a unittest based on lostcontext.py. -- keywords: +patch Added file: http://bugs.python.org/file11182/3611.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3611] invalid exception context
Changes by Barry A. Warsaw [EMAIL PROTECTED]: -- resolution: - accepted ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3611] invalid exception context
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Short patch review: __context__ tests are mostly found in test_raise.py (class TestContext) test_exceptions.py seems to only deal with the exception object. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3611] invalid exception context
Benjamin Peterson [EMAIL PROTECTED] added the comment: Patch was applied in r65921. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3611] invalid exception context
Benjamin Peterson [EMAIL PROTECTED] added the comment: Ok. I'll move the test after the betas. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3611] invalid exception context
Changes by Barry A. Warsaw [EMAIL PROTECTED]: -- status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3623] _json: fix raise_errmsg(), py_encode_basestring_ascii() and linecol()
Bob Ippolito [EMAIL PROTECTED] added the comment: That patch looks ok to me, but I'm not at all familiar with the changes in python 3.0 yet. Is this something that needs to be backported to 2.6? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3623 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3623] _json: fix raise_errmsg(), py_encode_basestring_ascii() and linecol()
Benjamin Peterson [EMAIL PROTECTED] added the comment: Christian, I believe, did the original 3.0 porting, so he can probably shed some light on this. -- nosy: +benjamin.peterson, christian.heimes ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3623 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3603] trivial typo in Include/pymath.h
Benjamin Peterson [EMAIL PROTECTED] added the comment: Don't worry. It's taken care of in all the active lines of development. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3603 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3612] Add some basic mssing types in ctypes.wintypes
Hirokazu Yamamoto [EMAIL PROTECTED] added the comment: Module will be deleted at the end of file anyway (delete _ctypes), maybe we could just do import ctypes and delete ctypes. Added file: http://bugs.python.org/file11183/avoid_giant_all_v2.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3612 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3373] sys recursion limit a lot shorter on trunk?
Benjamin Peterson [EMAIL PROTECTED] added the comment: Guido, can you comment? -- assignee: - gvanrossum nosy: +gvanrossum priority: high - release blocker ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3373 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3612] Add some missing basic types in ctypes.wintypes
Changes by Hirokazu Yamamoto [EMAIL PROTECTED]: -- title: Add some basic mssing types in ctypes.wintypes - Add some missing basic types in ctypes.wintypes ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3612 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
