[issue11205] Evaluation order of dictionary display is different from reference manual.
New submission from takayuki takayuki...@star.odn.ne.jp:
Running the following code shows 2 1 4 3, but in reference manual
http://docs.python.org/reference/expressions.html#expression-lists
the evaluation order described as
{expr1: expr2, expr3: expr4}
def f(i):
print i
return i
{f(1):f(2), f(3):f(4)}
I found some of past discussions about this problem, for example,
http://mail.python.org/pipermail/python-dev/2002-November/030461.html
http://mail.python.org/pipermail/python-dev/2002-November/030458.html
http://bugs.python.org/issue448679
http://svn.python.org/view?view=revrevision=30148
, but current implementation seems not to reflect these accomplishment.
In present, which behaviour is legal?
--
components: None
messages: 128482
nosy: takayuki
priority: normal
severity: normal
status: open
title: Evaluation order of dictionary display is different from reference
manual.
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11205
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11197] information leakage with SimpleHTTPServer
Georg Brandl ge...@python.org added the comment: Lowering priority. -- priority: deferred blocker - critical ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11197 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11160] ZipFile.comment expects bytes
STINNER Victor victor.stin...@haypocalc.com added the comment: can we use str.encode() function to convert string into bytes ? Can you try different ZIP archivers to check which encoding is expected? WinZip, WinRAR, 7-zip, zip command line program on Linux, etc. And do you have any reference into a ZIP documentation? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11160 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11206] test_readline unconditionally calls clear_history()
New submission from Georg Brandl ge...@python.org: This function apparently is not available in all readline versions; e.g. the GNU readline 5.2 currently installed on dinsdale. This can be fixed (together with the unconditional reliance of test_distutils and test_zipfile on zlib) after 3.2 final. -- components: Tests messages: 128485 nosy: georg.brandl priority: high severity: normal stage: needs patch status: open title: test_readline unconditionally calls clear_history() type: behavior versions: Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11206 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5231] Change format of a memoryview
Changes by Xuanji Li xua...@gmail.com: -- nosy: +xuanji ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5231 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5231] Change format of a memoryview
Xuanji Li xua...@gmail.com added the comment: Is this issue from 2 years ago still open? I checked the docs and it seems to be. If it is, I would like to work on a patch and submit it soon. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5231 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11205] Evaluation order of dictionary display is different from reference manual.
Changes by yeswanth swamiyeswa...@yahoo.com: -- nosy: +swamiyeswanth ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11205] Evaluation order of dictionary display is different from reference manual.
Skip Montanaro s...@pobox.com added the comment: Here's a patch. -- keywords: +patch nosy: +skip.montanaro versions: +Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file20753/compile.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5231] Change format of a memoryview
Nick Coghlan ncogh...@gmail.com added the comment: It is, but keep issue 10181 in mind (since that may lead to some restructuring of the memoryview code, potentially leading to a need to update your patch). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5231 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11205] Evaluation order of dictionary display is different from reference manual.
Skip Montanaro s...@pobox.com added the comment: Working on a test case too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11205] Evaluation order of dictionary display is different from reference manual.
Changes by Skip Montanaro s...@pobox.com: Removed file: http://bugs.python.org/file20753/compile.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11205] Evaluation order of dictionary display is different from reference manual.
Skip Montanaro s...@pobox.com added the comment: It's not so easy as first appeared. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Pauli Virtanen p...@iki.fi added the comment: Hi, Please focus on the constraints of the consumer not mucking with the content of `Py_buffer`, and calling `bf_releasebuffer` only with data obtained from `bf_getbuffer` and only one. If we agree on this, then how to exactly to do the implementation is just a detail. The problem in the current way is that the structure sent to `bf_releasebuffer` does not contain the same data as what was filled in by `bf_getbuffer`, and since the contents are dup-ed, `bf_releasebuffer` is called multiple times with the same data. So, `bf_releasebuffer` cannot rely on (i) the data in Py_buffer being what `bf_getbuffer` put there, and (ii) getting the same Py_buffer data only once. So, `bf_releasebuffer` cannot be used to release any resources allocated in `bf_getbuffer`. For example, Numpy's PEP 3118 implementation does not define a `bf_releasebuffer` although it needs to allocate resources in each call to `bf_getbuffer`. Instead, it has to keep a track of allocated memory, and deallocate all of them on `array_dealloc`. This is a PITA, and one that could be avoided by a small change in the PEP implementation and documentation in Python. Some worrying things here: * memoryview_getbuffer() doesn't call the original object's getbuffer. This means that if I do: m = memoryview(some_object) n = memoryview(m) m.release() n ends up holding a buffer to some_object's memory, but some_object doesn't know about it and can free the pointer at any time. Good point. There are two possible solutions to this: - Keep a count of how many buffers memoryview() has exported, and do not allow memoryview.release() if some are active. In a sense, this would be more in line with the PEP: the PyMemoryViewObject would here act as an ordinary object exporting some block of memory, and not do any magic tricks. It would guarantee that the buffers it has exported stay valid. - Add additional fields to `PyMemoryViewObject` for storing new `strides`, `format`, and `shape` that override the stuff in Py_buffer. This would allow for calling `PyObject_GetBuffer` for a second time. Both would be reasonably easy to do. *** Calling PyObject_GetBuffer to get a new hold of a buffer needs some precautions, though. For example: mem = memoryview(some_object) # do some stuff mem2 = memoryview(some_object) assert mem.format == mem2.format # not guaranteed so there is some extra work `memoryview_getbuffer` could do on top of calling PyObject_GetBuffer. * same for _get_sub_buffer_index() and _get_sub_buffer_slice0(). Actually, the whole concept of non-owner memoryviews seems flawed. If the parent memoryview keeps its the memory valid as long as such sub-memoryviews exist, such concerns go away. * the fact that slicing increments the parent memoryview's refcount means that a loop like: while len(m): # do something m = m[1:] will end up keeping N chained memoryviews on the heap. Currently only the last memoryview remains alive. This has an easy solution: if the parent is a non-owner memoryview, take a reference to its obj. This then keeps only buffer-owning view on the stack. Some other things: * why do you accept the ellipsis when indexing? what is it supposed to mean? Same meaning as in Numpy. a[...] == a * please don't use #warning. Just put the TODO in a /* ... */. Sure. * please no #if PY_VERSION_HEX = 0x0300. Just make your source py3k-compatible and we'll take care of backporting it to 2.x if your patch is accepted ;) Those are just so that the backporting would be easy. It's not on the stage of a serious patch yet :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11205] Evaluation order of dictionary display is different from reference manual.
Skip Montanaro s...@pobox.com added the comment: Okay, this looks better. I was confusing myself with leftover .pyc files I think. Test included. -- Added file: http://bugs.python.org/file20754/compile.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11205] Evaluation order of dictionary display is different from reference manual.
Skip Montanaro s...@pobox.com added the comment: Georg, I think this might need to sneak into 3.2. -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11205] Evaluation order of dictionary display is different from reference manual.
Georg Brandl ge...@python.org added the comment: I don't think so -- it's a very minor deviation from the spec and not a critical bug. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Antoine Pitrou pit...@free.fr added the comment: The problem in the current way is that the structure sent to `bf_releasebuffer` does not contain the same data as what was filled in by `bf_getbuffer`, and since the contents are dup-ed, `bf_releasebuffer` is called multiple times with the same data. Hmm, there's a misunderstanding. bf_releasebuffer is called exactly once for each call to bf_getbuffer. Of course, bf_getbuffer can be called several times! So, `bf_releasebuffer` cannot rely on (i) the data in Py_buffer being what `bf_getbuffer` put there, Well, why should it rely on that? So, `bf_releasebuffer` cannot be used to release any resources allocated in `bf_getbuffer`. AFAICT, it can. That's what the internal pointer is for: This is for use internally by the exporting object. For example, this might be re-cast as an integer by the exporter and used to store flags about whether or not the shape, strides, and suboffsets arrays must be freed when the buffer is released. The consumer should never alter this value. (http://docs.python.org/dev/c-api/buffer.html#Py_buffer.internal) Some worrying things here: * memoryview_getbuffer() doesn't call the original object's getbuffer. This means that if I do: m = memoryview(some_object) n = memoryview(m) m.release() n ends up holding a buffer to some_object's memory, but some_object doesn't know about it and can free the pointer at any time. Good point. There are two possible solutions to this: - Keep a count of how many buffers memoryview() has exported, and do not allow memoryview.release() if some are active. Where would that count be stored? In a sense, this would be more in line with the PEP: the PyMemoryViewObject would here act as an ordinary object exporting some block of memory, and not do any magic tricks. Well, that sounds wrong to me. The memoryview doesn't export anything; the original object does. It would guarantee that the buffers it has exported stay valid. How would it, since it doesn't know the original object's semantics? - Add additional fields to `PyMemoryViewObject` for storing new `strides`, `format`, and `shape` that override the stuff in Py_buffer. This would allow for calling `PyObject_GetBuffer` for a second time. Sounds better to me :) Calling PyObject_GetBuffer to get a new hold of a buffer needs some precautions, though. For example: mem = memoryview(some_object) # do some stuff mem2 = memoryview(some_object) assert mem.format == mem2.format # not guaranteed Well, if the original object decides to change the format between two calls, then memoryview() should simply reflect that. * same for _get_sub_buffer_index() and _get_sub_buffer_slice0(). Actually, the whole concept of non-owner memoryviews seems flawed. If the parent memoryview keeps its the memory valid as long as such sub-memoryviews exist, such concerns go away. So release() wouldn't do what it claims to do? That sounds misleading. Some other things: * why do you accept the ellipsis when indexing? what is it supposed to mean? Same meaning as in Numpy. a[...] == a Yes, but why we would do that in core Python? a[...] might have a meaning in NumPy, but it has none in core Python currently. I'm not against it, but it would warrant discussion on python-dev. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5302] Allow package_data globs match directories
Alexis Metaireau ametair...@gmail.com added the comment: The MANIFEST.in is definitely gone in distutils2. Can we close that? (don't have the rights to do so ‑ it can be handy on distutils2 bugs) -- nosy: +alexis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5302 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5243] Missing dependency in distutils build
Alexis Metaireau ametair...@gmail.com added the comment: Has the patch been applied on distutils(1/2) ? -- nosy: +alexis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11205] Evaluation order of dictionary display is different from reference manual.
Skip Montanaro s...@pobox.com added the comment: 3.2 and earlier versions are all frozen, but for 3.3 it might make sense to bump the version number of the bytecode and change STORE_MAP to take the key and value in the opposite order, thus allowing to remove the ROT_TWO I had to add to make this work. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Pauli Virtanen p...@iki.fi added the comment:
Hmm, there's a misunderstanding. bf_releasebuffer is called exactly
once for each call to bf_getbuffer.
Wrong: http://bugs.python.org/issue7433
static int
memory_getbuf(PyMemoryViewObject *self, Py_buffer *view, int flags)
{
int res = 0;
CHECK_RELEASED_INT(self);
if (self-view.obj != NULL)
res = PyObject_GetBuffer(self-view.obj, view, flags);
if (view)
dup_buffer(view, self-view);
return res;
}
After this, PyBuffer_Release will be called twice: once on the data in *view,
by whoever acquired the buffer from memoryview, and once on self-view, by
memory_dealloc. Both with the same bit-by-bit content of the Py_buffer
structure.
Because there are two Py_buffer structures here, setting view.obj to NULL in
PyBuffer_Release does not guarantee correct calls to bf_releasebuffer.
Note that the view.internal pointer is also clobbered above.
So, `bf_releasebuffer` cannot rely on (i) the data in Py_buffer
being what `bf_getbuffer` put there,
Well, why should it rely on that?
Because that makes implementing the exporter much easier. Also, writing an
implementation for MemoryViewObject does not require clobbering the structure,
and I doubt it helps much.
So, `bf_releasebuffer` cannot be used to release any resources
allocated in `bf_getbuffer`.
AFAICT, it can. That's what the internal pointer is for.
Sure, guaranteeing that view-internal pointer is not toyed with would also be
enough.
But the documentation should spell out very explicitly what the
bf_releasebuffer call can rely on.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10181
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11205] Evaluation order of dictionary display is different from reference manual.
R. David Murray rdmur...@bitdance.com added the comment: Interesting. I would actually have expected the observed behavior. I think of the : in a dictionary literal as an assignment. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue901727] extra_path kwarg to setup() undocumented
Alexis Metaireau ametair...@gmail.com added the comment: I've applied the patch on distutils2. This can now be closed. -- nosy: +alexis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue901727 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6087] distutils.sysconfig.get_python_lib gives surprising result when used with a Python build
Changes by Alexis Metaireau ametair...@gmail.com: -- nosy: +alexis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6087 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11205] Evaluation order of dictionary display is different from reference manual.
Georg Brandl ge...@python.org added the comment: BTW, it would be nice to know if this behavior was consistent with the docs at any time (the merge of the AST branch in 2.5 might be an obvious candidate where it was broken). Also interesting would be what other implementations of Python do. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Antoine Pitrou pit...@free.fr added the comment:
Hmm, there's a misunderstanding. bf_releasebuffer is called exactly
once for each call to bf_getbuffer.
Wrong: http://bugs.python.org/issue7433
This is a different issue.
static int
memory_getbuf(PyMemoryViewObject *self, Py_buffer *view, int flags)
{
int res = 0;
CHECK_RELEASED_INT(self);
if (self-view.obj != NULL)
res = PyObject_GetBuffer(self-view.obj, view, flags);
if (view)
dup_buffer(view, self-view);
return res;
}
After this, PyBuffer_Release will be called twice: once on the data in
*view, by whoever acquired the buffer from memoryview
, and once on self-view, by memory_dealloc.
PyObject_GetBuffer() is called twice too: once when creating the
memoryview, once when calling memory_getbuf.
So again, bf_getbuffer is called the same number of times as
bf_releasebuffer.
Note that the view.internal pointer is also clobbered above.
Are you sure? memoryobject.c doesn't touch that pointer at all.
So, `bf_releasebuffer` cannot be used to release any resources
allocated in `bf_getbuffer`.
AFAICT, it can. That's what the internal pointer is for.
Sure, guaranteeing that view-internal pointer is not toyed with would
also be enough.
But the documentation should spell out very explicitly what the
bf_releasebuffer call can rely on.
Yes.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10181
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2200] find_executable fails to find .bat files on win32
Alexis Metaireau ale...@notmyidea.org added the comment: Have the patch been applied ? (the state is still open since last message) -- nosy: +alexis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2200 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Pauli Virtanen p...@iki.fi added the comment: [clip] This is a different issue. It is the issue relevant for this discussion. As written in my comment: So, `bf_releasebuffer` cannot rely on (i) the data in Py_buffer being what `bf_getbuffer` put there, and (ii) getting the same Py_buffer data only once. PyObject_GetBuffer() is called twice too: once when creating the memoryview, once when calling memory_getbuf. So again, bf_getbuffer is called the same number of times as bf_releasebuffer. Yes, it is called twice, but with exactly the same data in Py_buffer. So I would rather say that bf_releasebuffer is called twice on the Py_buffer returned by the first Getbuffer, and zero times for the buffer returned by the second one. Note that the view.internal pointer is also clobbered above. Are you sure? memoryobject.c doesn't touch that pointer at all. dup_buffer does *dst = *src, which overwrites the view.internal pointer obtained from one GetBuffer call with a pointer obtained from a previous one. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Antoine Pitrou pit...@free.fr added the comment: dup_buffer does *dst = *src, which overwrites the view.internal pointer obtained from one GetBuffer call with a pointer obtained from a previous one. Ah, ok, then it deserves fixing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11205] Evaluation order of dictionary display is different from reference manual.
Skip Montanaro s...@pobox.com added the comment: As Georg suggested, it is correct in 2.4, wrong in 2.5. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11205] Evaluation order of dictionary display is different from reference manual.
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7546] msvc9compiler.py: add .asm extension
Changes by Alexis Metaireau ale...@notmyidea.org: -- nosy: +alexis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7546 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Pauli Virtanen p...@iki.fi added the comment: Ok, good, that diversion was then avoided :) *** So, am I on the right track that there would not be many objections to clarifying the docs of Py_buffer spec by stating: - For each buffer yielded by `bf_getbuffer`, `bf_releasebuffer` is called exactly once. Each `bf_releasebuffer` call is guaranteed to get the same view-internal pointer as filled in previously by the corresponding `bf_getbuffer`. All other fields in `Py_buffer` may be modified by the consumer, and `bf_releasebuffer` may not assume they contain valid data. - The exporter of the buffer must ensure that apart from the contents of the memory pointed to by `buf`, the contents of the returned Py_buffer (format, strides, shape, etc.) remain unchanged. If the latter is not true, it will lead to no end of trouble in e.g. multithreaded programs. What about the more strict requirement: - `bf_releasebuffer` is guaranteed that all fields except `obj` are not modified? This could simplify implementation of exporters, and I suspect that MemoryViewObject is a special case, as most consumers probably would not want to make such modifications. I can try preparing an updated patch based on some combination of the above, taking into account your comments. BTW, should I take this discussion to Python-dev? So far, I kept it here, as this bug report seemed to be about general issues in the current implementation and spec. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5302] Allow package_data globs match directories
Éric Araujo mer...@netwok.org added the comment: Even if MANIFEST.in is gone, we still have a way to include files, so the request to allow globs to match directories still apply. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5302 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5243] Missing dependency in distutils build
Éric Araujo mer...@netwok.org added the comment: If we haven’t closed it, it’s because it has not been. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue901727] extra_path kwarg to setup() undocumented
Éric Araujo mer...@netwok.org added the comment: You shouldn’t have :) apiref.rst is very outdated in d2, because the setup function does not exist. The docs could be adjusted to document Distribution instead of setup, but we’re not even sure Distribution will stay. I think I will make a compromise here and apply the patch to distutils1 doc, so that the information is found on the official docs. -- components: +Distutils -Distutils2 versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3 -3rd party ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue901727 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2200] find_executable fails to find .bat files on win32
Éric Araujo mer...@netwok.org added the comment: Not yet. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2200 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue901727] extra_path kwarg to setup() undocumented
Alexis Metaireau ale...@notmyidea.org added the comment: Still, the extra_path argument exists and can be used, it's worth to have it documented somewhere, especially if someone have done it. That's also true that apiref.rst is outdated in d2, and will need a complete reshape :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue901727 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1083299] Distutils doesn't pick up all the files it should.
Changes by Alexis Metaireau ale...@notmyidea.org: -- components: -Distutils2 nosy: +alexis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1083299 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1083299] Distutils doesn't pick up all the files it should.
Changes by Éric Araujo mer...@netwok.org: -- components: +Distutils2 nosy: -BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1083299 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Changes by Alexis Metaireau ale...@notmyidea.org: -- nosy: +alexis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294032] Distutils writes keywords comma-separated
Changes by Alexis Metaireau ale...@notmyidea.org: -- nosy: +alexis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294032 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1092365] Distutils needs a way *not* to install files
Changes by Alexis Metaireau ale...@notmyidea.org: -- nosy: +alexis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1092365 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Antoine Pitrou pit...@free.fr added the comment: - For each buffer yielded by `bf_getbuffer`, `bf_releasebuffer` is called exactly once. Each `bf_releasebuffer` call is guaranteed to get the same view-internal pointer as filled in previously by the corresponding `bf_getbuffer`. All other fields in `Py_buffer` may be modified by the consumer, and `bf_releasebuffer` may not assume they contain valid data. - The exporter of the buffer must ensure that apart from the contents of the memory pointed to by `buf`, the contents of the returned Py_buffer (format, strides, shape, etc.) remain unchanged. Yes! Can you write a patch that does these docs changes and also fixes the internal pointer issue? What about the more strict requirement: - `bf_releasebuffer` is guaranteed that all fields except `obj` are not modified? Well, if you manage to change the memoryview implementation for that, then fine. But I don't know how you plan to manage ownership of fields such as strides and friends. BTW, should I take this discussion to Python-dev? So far, I kept it here, as this bug report seemed to be about general issues in the current implementation and spec. I don't think you need to. Nick and Mark follow this issue (and so does Travis if he's still alive ;)). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1635363] Add command line help to windows unistall binary
Changes by Alexis Metaireau ale...@notmyidea.org: -- nosy: +alexis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1635363 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1011113] Make “install” find the build_base directory
Changes by Alexis Metaireau ale...@notmyidea.org: -- nosy: +alexis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue103 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9298] binary email attachment issue with base64 encoding
Changes by Yves Dorfsman y...@zioup.com: Removed file: http://bugs.python.org/file20742/issue9298-test.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9298 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9298] binary email attachment issue with base64 encoding
Changes by Yves Dorfsman y...@zioup.com: Removed file: http://bugs.python.org/file20743/issue9298.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9298 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9298] binary email attachment issue with base64 encoding
Yves Dorfsman y...@zioup.com added the comment: encoders.py: Fixes the issue of base64'ed being 76 chars test_email.py: -test that base64'ed binary is split into 76 chars lines -WARRNING: Changes the test for MIMEApplication.test_body: -it changes the name of the variable 'bytes' to 'bytesdata' -it strip()s the base64ed payload before it compares it to the expected payload. With the change above (using encodebytes instead of b64encode in encoders.py), this test, as is, fails, because there is an extra newline at the end. Extra newlines are part of base64 and should not be an issue, as a matter of fact, you obtain the original bytes when you decode, regardless of having extra newlines. It would be good to know the intent of the original author of this test. Was the intent to ensure there were no newline? If so, why? Or was the intent to simply confirm the base64 encoding conform to the standard? If the latter, my change should not be an issue. All test (make test) passed with this patch. -- Added file: http://bugs.python.org/file20755/issue9298-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9298 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Pauli Virtanen p...@iki.fi added the comment: Ok, here's a patch with some suggested documentation changes + the minimal changes in memoryview to make bf_releasebuffer behave as advertised. Probably shouldn't be applied as-is, though. Problems remain. Suppose `bf_getbuffer` for memoryview is implemented so that it returns a view exported by the original object (and not the memoryview). Consider an example: obj = PictureSet() # exposes a buffer, say, to pic_1 a = memoryview(obj) # points to pic_1 Here, `a` grabs a lock to pic_1. obj.choose_picture(2)# switches the exposed buffer to pic_2 b = memoryview(obj) # points to pic_2 c = memoryview(a) Here, PyObject_GetBuffer in bf_getbuffer for `a` grabs a lock to pic_2 and passes it on to `c`. The spec specifies no ways to get additional locks on pic_1. a.release() Now lock on pic_1 is released, and the buffer may be freed (also, if the handling of shape/stride arrays in memoryview is as it is now, also those are invalidated). One of the two is now true: `memoryview(a)` does not always describe the same area of memory as `a`, OR, `c` ends up with a lock on the wrong area of memory and the program hits a SEGV. [clip] In a sense, this would be more in line with the PEP: the PyMemoryViewObject would here act as an ordinary object exporting some block of memory, and not do any magic tricks. Well, that sounds wrong to me. The memoryview doesn't export anything; the original object does. Having the memoryview own the exported buffer would be a simple solution to the above issue. The alternative would be to adjust the spec so that the above type of behavior is forbidden (any buffers and the shape/stride arrays ever exported must remain valid until the last one is released). Not sure if it makes sense to do this if the only gain is a simplification in the implementation of memoryview. It would guarantee that the buffers it has exported stay valid. How would it, since it doesn't know the original object's semantics? The original object must guarantee that the buffers remain valid until released, as specified in the PEP. Of course, this requires that memoryview counts how many buffers it has exported, and allows release() only if the count is zero. -- Added file: http://bugs.python.org/file20756/buffer-interface-clarify.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Antoine Pitrou pit...@free.fr added the comment: Problems remain. Suppose `bf_getbuffer` for memoryview is implemented so that it returns a view exported by the original object (and not the memoryview). Consider an example: obj = PictureSet() # exposes a buffer, say, to pic_1 a = memoryview(obj) # points to pic_1 Here, `a` grabs a lock to pic_1. obj.choose_picture(2)# switches the exposed buffer to pic_2 That's a very bad API to begin with. Anyone thinking it is reasonable to have the concept of a current element in a container should write PHP code instead. If you have individual pictures, please use individual objects. b = memoryview(obj) # points to pic_2 c = memoryview(a) Here, PyObject_GetBuffer in bf_getbuffer for `a` grabs a lock to pic_2 and passes it on to `c` So what? c will represent pic_2 anyway, so the behaviour is right. Awful certainly for the user, but that's because PictureSet implements a braindead API. , and the buffer may be freed (also, if the handling of shape/stride arrays in memoryview is as it is now, also those are invalidated). One of the two is now true: `memoryview(a)` does not always describe the same area of memory as `a`, OR, `c` ends up with a lock on the wrong area of memory and the program hits a SEGV. This all points to completely broken logic in the imaginary PictureSet class. If someone doesn't get their semantics right, it is not the buffer API's problem. bf_getbuffer and bf_releasebuffer must implement symmetric operations; perhaps that's not explicitly worded, but it seems quite obvious to me. The alternative would be to adjust the spec so that the above type of behavior is forbidden (any buffers and the shape/stride arrays ever exported must remain valid until the last one is released). Why would you adjust the spec? This just stems from common sense. If you provide a pointer to a consuming API, you have to ensure the pointer remains valid as long as the consuming API is using that pointer. Actually, that's *exactly* why there's a bf_releasebuffer method at all. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Antoine Pitrou pit...@free.fr added the comment: That said: Having the memoryview own the exported buffer would be a simple solution to the above issue. If you can implement that without exhibing the issues we discussed above (e.g. O(N) memory consumption when doing repetitive slicing), then why not. Also, thanks for the patch. Please refrain from spurious formatting changes, though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11149] [PATCH] Configure should enable -fwrapv for clang
Ismail Donmez ism...@namtrac.org added the comment: @Antoine Pitrou , that is tracked by http://bugs.python.org/issue1621 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11149 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11205] Evaluation order of dictionary display is different from reference manual.
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: sigh If only a test had been checked-in eight years ago ... It looks like a number of things have to be changed in order to bring behavior back to what the docs promise. Dict literals and dict comprehensions need to be fixed in both the compile.py and compile.c. To avoid introducing a ROT_TWO, the store STORE_MAP and MAP_ADD opcodes need minor modifications (just switch the u and w variable assignments). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11205] Evaluation order of dictionary display is different from reference manual.
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: takayuki, a special thanks to you for submitting such a well-researched bug report :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11205] Evaluation order of dictionary display is different from reference manual.
Skip Montanaro s...@pobox.com added the comment: To avoid introducing a ROT_TWO, the store STORE_MAP and MAP_ADD opcodes need minor modifications (just switch the u and w variable assignments). Either of which would not be possible in anything other that 3.3 or later, right? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11207] Pythong seg fault with PIL/numpy
New submission from David Knapp psychicsurg...@gmail.com:
Python had a seg fault with the following simple code.
import PIL.Image as Img
import numpy as np
i = Img.open('/home/falmarri/Dropbox/obey.jpg')
n = np.array(bytearray(i.tostring()),dtype=np.uint16)
zsh: segmentation fault python
Running it under gdb gave the following
(gdb) run g19_framebuffer.py
Starting program: /usr/bin/python g19_framebuffer.py
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
_unaligned_strided_byte_copy (dst=0xcb9543 \366\377\177, outstrides=1,
src=0x73503da5 Address 0x73503da5 out of bounds,
instrides=4969607, N=1, elsize=value optimized out) at
/usr/include/bits/string3.h:52
warning: Source file is more recent than executable.
52return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
It could be that I'm doing it wrong though.
--
messages: 128523
nosy: David.Knapp
priority: normal
severity: normal
status: open
title: Pythong seg fault with PIL/numpy
type: crash
versions: Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11207
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11207] Pythong seg fault with PIL/numpy
Brett Cannon br...@python.org added the comment: Can you give a longer backtrace? Since that failure is happening in a system library we need to know where the segfault first occurs in either PIL, numpy, or CPython. And have you tried this in Python 2.7? -- nosy: +brett.cannon status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11207 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Nick Coghlan ncogh...@gmail.com added the comment: I'm still not comfortable with a convention that relies on *clients* of the PEP 3118 API not mucking with the internals of the Py_buffer struct. I'm *much* happier with the rule based on malloc/free semantics where the *pointer* passed to PyObject_GetBuffer must match a single later call to PyObject_ReleaseBuffer. This is also a convention that should be quite familiar to any C/C++ developers using the API directly. Note my comment earlier, pointing out that under those rules, dup_buffer actually does the right thing given the way it is used in the current implementation, but there's one current bug (issue 9990) where the wrong address is passed to the release buffer call - get_buffer is called with a stack address, the contents are copied to a heap address, then the heap address is used in the release_buffer call. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Nick Coghlan ncogh...@gmail.com added the comment: As far as the question of re-exporting the underlying view or not goes, I agree having memoryview(a) potentially refer to different underlying memory from a itself (because the source object has changed since the first view was exported) is a recipe for confusion. It is also important for ensuring memoryview slicing works correctly. From a didactic point of view, this would also have the benefit of providing a canonical example of managing exported Py_buffer structs in the CPython source code. The repeated slicing issue is definitely a concern, though. If we declare memoryview objects officially immutable, then we can avoid that by shortcutting the chaining with a typecheck on the referenced object (i.e. call GetBuffer on the source object directly if it is a memoryview, but on the memoryview we're copying otherwise) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Nick Coghlan ncogh...@gmail.com added the comment: I should note that the idea of using a Py_buffer's internal field as the unique ID rather than the Py_buffer's address does have some merit, but I still overall prefer a design that places fewer constraints on API consumers. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Antoine Pitrou pit...@free.fr added the comment: I'm still not comfortable with a convention that relies on *clients* of the PEP 3118 API not mucking with the internals of the Py_buffer struct. Which clients? Those who export the buffer, or those who consume it? I'm *much* happier with the rule based on malloc/free semantics where the *pointer* passed to PyObject_GetBuffer must match a single later call to PyObject_ReleaseBuffer. Agreed that Py_buffer should have been a PyObject from the start, but the PEP chose differently. We now have backwards compatibility constraints. What do we do with PyMemoryView_FromBuffer? Also, there's probably some code out there that likes to copy Py_buffers around. As far as the question of re-exporting the underlying view or not goes, I agree having memoryview(a) potentially refer to different underlying memory from a itself (because the source object has changed since the first view was exported) is a recipe for confusion. If an object changes its buffer while it's exported somewhere, it will always result in confusion for the user, regardless of how the memoryview object is implemented. All normal uses of the buffer API assume that the buffer's memory doesn't change while it's being accessed by its consumer (what would it mean to SHA1-hash or zlib-compress a changing piece of memory?). So I don't know why the memoryview object *in particular* should care about this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11208] example misprint in documentation whatsnew/3.2
New submission from July Tikhonov july.t...@gmail.com: list(accumulate(8, 2, 50)) fails. Correct version is list(accumulate([8, 2, 50])) -- assignee: docs@python components: Documentation files: whatsnew.3.2.accumulate.example.diff keywords: patch messages: 128529 nosy: docs@python, july priority: normal severity: normal status: open title: example misprint in documentation whatsnew/3.2 versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file20757/whatsnew.3.2.accumulate.example.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11208 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11205] Evaluation order of dictionary display is different from reference manual.
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: How much to change and how far to backport may make for a good python-dev discussion. ISTM that changing generated code goes hand-in-hand with changing opcode semantics (as long as the magic number gets bumped). OTOH, none of this may be worth backporting at all since no one seems to have noticed or cared for eight years. I don't have any feelings about it one way or the other, but it would great to see Py3.2.1 get fixed properly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11207] Pythong seg fault with PIL/numpy
David Knapp psychicsurg...@gmail.com added the comment: Sorry I'm not all that experienced with gdb. Let me know if there's more to get. (gdb) bt #0 _unaligned_strided_byte_copy (dst=0xcb9623 \366\377\177, outstrides=1, src= 0x73503da5 Address 0x73503da5 out of bounds, instrides=4969607, N=1, elsize=value optimized out) at /usr/include/bits/string3.h:52 #1 0x75ee2cca in _strided_buffered_cast (dptr=value optimized out, dstride=value optimized out, delsize=value optimized out, dswap=value optimized out, dcopyfunc=value optimized out, sptr=value optimized out, sstride=4969607, selsize=1, sswap=0, scopyfunc=0x75eec340 UBYTE_copyswapn, N=1, buffers=0x7fffd7d0, bufsize=1, castfunc=0x75edbf30 UBYTE_to_USHORT, dest=0x9634a0, src=0xa3d7e0) at numpy/core/src/multiarray/convert_datatype.c:164 #2 0x75ee2c66 in _strided_buffered_cast (dptr=value optimized out, dstride=value optimized out, delsize=value optimized out, dswap=value optimized out, dcopyfunc=value optimized out, sptr=value optimized out, sstride=4969607, selsize=1, sswap=0, scopyfunc=0x75eec340 UBYTE_copyswapn, N=13039280, buffers=0x7fffd7d0, bufsize=1, castfunc=0x75edbf30 UBYTE_to_USHORT, dest=0x9634a0, src=0xa3d7e0) at numpy/core/src/multiarray/convert_datatype.c:175 #3 0x75f13337 in _broadcast_cast (out=0x9634a0, in=0xa3d7e0, castfunc=value optimized out, iswap=value optimized out, oswap=value optimized out) at numpy/core/src/multiarray/convert_datatype.c:255 #4 0x75f14e48 in _array_copy_into (dest=0x9634a0, src=0xa3d7e0, usecopy=value optimized out) at numpy/core/src/multiarray/ctors.c:861 #5 0x75f16d3b in PyArray_FromArray (arr=0xa3d7e0, newtype=value optimized out, flags=value optimized out) at numpy/core/src/multiarray/ctors.c:2021 #6 0x75f0f4ae in PyArray_FromAny (op=bytearray at remote 0xb869f0, newtype=0x761527e0, min_depth=0, max_depth=0, flags=112, context=value optimized out) at numpy/core/src/multiarray/ctors.c:1785 #7 0x75f214e6 in PyArray_CheckFromAny (op=bytearray at remote 0xb869f0, descr=0x761527e0, min_depth=-212845147, max_depth=228, requires=112, context=unknown at remote 0x1) at numpy/core/src/multiarray/ctors.c:1934 #8 0x75f2283a in _array_fromobject (__NPY_UNUSED_TAGGEDignored=value optimized out, args=value optimized out, kws=value optimized out) at numpy/core/src/multiarray/multiarraymodule.c:1500 #9 0x004a5ce4 in do_call (f=Frame 0x91ac90, for file g19_framebuffer.py, line 121, in module (), throwflag=value optimized out) at ../Python/ceval.c:3965 #10 call_function (f=Frame 0x91ac90, for file g19_framebuffer.py, line 121, in module (), throwflag=value optimized out) at ../Python/ceval.c:3773 #11 PyEval_EvalFrameEx (f=Frame 0x91ac90, for file g19_framebuffer.py, line 121, in module (), throwflag=value optimized out) at ../Python/ceval.c:2412 #12 0x004a6bd1 in PyEval_EvalCodeEx (co=0x77f06a80, globals=value optimized out, locals=value optimized out, args= 0x0, argcount=value optimized out, kws=value optimized out, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:3000 #13 0x004a6ca2 in PyEval_EvalCode (co=0xcb9623, globals=unknown at remote 0x1, locals=unknown at remote 0x73503da5) at ../Python/ceval.c:541 #14 0x004c702e in run_mod (fp=value optimized out, filename=0x7fffe232 g19_framebuffer.py, start=value optimized out, globals=value optimized out, locals=value optimized out, closeit=1, flags=0x7fffde30) at ../Python/pythonrun.c:1351 #15 PyRun_FileExFlags (fp=value optimized out, filename=0x7fffe232 g19_framebuffer.py, start=value optimized out, globals=value optimized out, locals=value optimized out, closeit=1, flags=0x7fffde30) at ../Python/pythonrun.c:1337 #16 0x004c7244 in PyRun_SimpleFileExFlags (fp=value optimized out, filename=0x7fffe232 g19_framebuffer.py, closeit=1, flags=0x7fffde30) at ../Python/pythonrun.c:941 #17 0x004180c1 in Py_Main (argc=-135348096, argv=value optimized out) at ../Modules/main.c:577 #18 0x769dad8e in __libc_start_main (main=value optimized out, argc=value optimized out, ubp_av=value optimized out, init=value optimized out, fini=value optimized out, rtld_fini=value optimized out, stack_end=0x7fffdf48) at libc-start.c:226 #19 0x004172c9 in _start () If it matters, I figured out I was trying to do what I was doing incorrectly. So I've found a better way to do it. The problem is specific to the bytearray() here, so it could very well be a problem with either bytearray or numpy. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11207 ___
[issue11207] Pythong seg fault with PIL/numpy
Antoine Pitrou pit...@free.fr added the comment: Judging from the traceback, you should probably report that issue to numpy instead. -- nosy: +pitrou resolution: - invalid status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11207 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7330] PyUnicode_FromFormat segfault
Changes by Ray.Allen ysj@gmail.com: Removed file: http://bugs.python.org/file18305/issue_7330.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7330 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7330] PyUnicode_FromFormat segfault
Changes by Ray.Allen ysj@gmail.com: Removed file: http://bugs.python.org/file19132/issue_7330.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7330 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7330] PyUnicode_FromFormat segfault
Changes by Ray.Allen ysj@gmail.com: Removed file: http://bugs.python.org/file20731/issue_7330.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7330 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9523] Improve dbm modules
Changes by Ray.Allen ysj@gmail.com: Removed file: http://bugs.python.org/file18402/issue8634.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9523 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9523] Improve dbm modules
Changes by Ray.Allen ysj@gmail.com: Removed file: http://bugs.python.org/file19987/issue_9523.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9523 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9523] Improve dbm modules
Changes by Ray.Allen ysj@gmail.com: Removed file: http://bugs.python.org/file20726/issue_9523.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9523 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1635741] Interpreter seems to leak references after finalization
Changes by Ray.Allen ysj@gmail.com: -- nosy: +ysj.ray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1635741 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11209] Example for itertools.count is misleading
New submission from Johannes Ammon johannes.am...@gmail.com: The example code for itertools.count (http://docs.python.org/library/itertools.html#itertools.count) says # count(2.5, 0.5) - 3.5 3.0 4.5 ... I think that should read # count(2.5, 0.5) - 2.5 3.0 3.5 ... -- assignee: docs@python components: Documentation messages: 128533 nosy: docs@python, jammon priority: normal severity: normal status: open title: Example for itertools.count is misleading versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11209 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11209] Example for itertools.count is misleading
Alex alex.gay...@gmail.com added the comment: Patch for 2.7. -- keywords: +patch nosy: +alex Added file: http://bugs.python.org/file20758/python-11209.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11209 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11209] Example for itertools.count is misleading
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Fixed in 2.7 and 3.1. Was already fixed in 3.2. Thanks for the report. -- nosy: +rhettinger resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11209 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3710] Reference leak in thread._local
Changes by Ray.Allen ysj@gmail.com: -- nosy: +ysj.ray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3710 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
