Stefan Krah added the comment:
Confirmed. The test case quickly uses 8GB of memory.
--
nosy: +ezio.melotti, pitrou, skrah
stage: -> needs patch
versions: +Python 3.1, Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Stefan Krah added the comment:
test_trace still fails on 2.7 on the no-threads bot:
http://www.python.org/dev/buildbot/all/builders/AMD64%20Fedora%20without%20threads%202.7/builds/22/steps/test/logs/stdio
Could you have a short look at the patch. I think it should be correct;
the tests pass
Stefan Behnel added the comment:
I don't see this having much to do with the DRY principle. It's "explicit is
better than implicit" and "better safe than sorry" that applies here.
--
___
Python tracker
<
New submission from Stefan Krah :
With Python 2.7, the FreeBSD AMD64 bot has sporadic failures in
test_smtplib. Since these failures don't occur in other branches,
I wonder if the timeout of 3 seconds is too low in 2.7. The timeout
is 15 seconds in 3.3.
test test_smtplib failed -- Trac
Stefan Krah added the comment:
Indeed, increasing the timeout to 15 solves the problem (I ran the
test with the -F option for about 100 times).
Since the timeout has been increased before to deal with flaky tests
(52682bd738a7), I guess it's ok to do the same for 2.7.
--
key
Stefan Krah added the comment:
Hmm, testVRFY occurs twice, once with timeout=15 and once with
timeout=3. So there might be another reason why the test passes on
3.3 but not on 2.7.
Anyway, increasing the timeout to 15 throughout does solve
(or suppress) the problem
Stefan Krah added the comment:
See also: Issue 11439
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue12221>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
> Distutils doesn't validate PyPI server certificate, so this change
> doesn't prevent from MITM attacks, but at least it makes package
> submissions over wireless channels and public networks safer.
Is that so? It's been a while, but I
New submission from Stefan Krah :
The implicit timeout in regrtest.py makes it harder to write automated
test scripts for 3rd party modules. First, you have to remember to
set --timeout=0 for long running tests. Then, you have to remember
not to use the --timeout option when compiling --without
Stefan Krah added the comment:
STINNER Victor wrote:
> > The implicit timeout in regrtest.py makes it harder to write automated
> > test scripts for 3rd party modules. First, you have to remember to
> > set --timeout=0 for long running tests.
>
> Ah? Which test is
Stefan Krah added the comment:
I think there should be a warning that the connection is unauthenticated
(i.e. not secure). Users tend to be upset if they see 'https' and later
find out that no certificates were verified.
A reasonably secure alternative is to publish the p
Stefan Krah added the comment:
Mark Dickinson wrote:
> Here's a patch. Stefan, could you please review?
Mark, sorry for not replying earlier. The patch looks great.
I've also tested the patch in practice: I ran 700,000,000 random tests with
an exponent range of [-9, 999
Stefan Krah added the comment:
Hmm, in http://bugs.python.org/issue7511#msg106420 Tarek appeared to
be supportive of the patch.
Re DISTUTILS_USE_SDK:
I don't think many users are aware of this variable. Also, it is not
needed at all; it is sufficient to execute vcvars64.bat manually
b
Stefan Krah added the comment:
panel.h is not found. You'll need to install the package that
provides libpanel together with the header files:
error: panel.h: No such file or directory
This does not look like a Python bug, so I'll set the issue to
'pending'. You can
Stefan Krah added the comment:
Marc-Andre Lemburg wrote:
> Wouldn't it be better to have distutils tell the user about the
> possible options, instead of guessing and then possibly compiling
> extensions which later on don't import or import, but don't work
> as e
Stefan Krah added the comment:
Marc-Andre Lemburg wrote:
> >> >> Regarding the latest patch: This is not the right approach, since
> >> >> find_vcvarsall() is supposed to return the path to the vcvarsall.bat
> >> >> file and not an architecture sp
Changes by Stefan Krah :
Removed file: http://bugs.python.org/file15854/py3k_help_unify.diff
___
Python tracker
<http://bugs.python.org/issue7652>
___
___
Python-bug
Changes by Stefan Krah :
Removed file: http://bugs.python.org/file15855/trunk_help_unify.diff
___
Python tracker
<http://bugs.python.org/issue7652>
___
___
Python-bug
Changes by Stefan Krah :
--
hgrepos: +25
___
Python tracker
<http://bugs.python.org/issue7652>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Changes by Stefan Krah :
Added file: http://bugs.python.org/file22303/ad05c2fdb3b2.diff
___
Python tracker
<http://bugs.python.org/issue7652>
___
___
Python-bugs-list m
Changes by Stefan Krah :
Removed file: http://bugs.python.org/file22303/ad05c2fdb3b2.diff
___
Python tracker
<http://bugs.python.org/issue7652>
___
___
Python-bugs-list m
Changes by Stefan Krah :
Added file: http://bugs.python.org/file22304/9a10e3232445.diff
___
Python tracker
<http://bugs.python.org/issue7652>
___
___
Python-bugs-list m
Stefan Krah added the comment:
Just a couple of remarks about the diff I created:
The changes to decimal.py are exploratory (i.e. done quite hastily)
and serve the purpose to fulfill PEP-399.
library/cdecimal.rst is completely out of date.
The rest should be very stable
Changes by Stefan Krah :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue7652>
___
___
Python-bugs-list mailing list
Unsubscri
Stefan Krah added the comment:
Yes, this is fixed in 3.2. I just left the issue open as a reminder
for the release branch.
--
resolution: -> fixed
stage: -> committed/rejected
___
Python tracker
<http://bugs.python.org/i
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue3067>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Changes by Stefan Krah :
Removed file: http://bugs.python.org/file22304/9a10e3232445.diff
___
Python tracker
<http://bugs.python.org/issue7652>
___
___
Python-bugs-list m
Changes by Stefan Krah :
Added file: http://bugs.python.org/file22404/49433f35a5f8.diff
___
Python tracker
<http://bugs.python.org/issue7652>
___
___
Python-bugs-list m
Stefan Krah added the comment:
The latest patch is based on a relatively stable revision of 3.3. To my
knowledge, _decimal.c and decimal.py are now fully compatible in the
sense of PEP-399.
libmpdec
o New test suite with comprehensive tests against decNumber.
o Full
Stefan Krah added the comment:
I agree with Éric: This is a duplicate.
--
nosy: +skrah
resolution: -> duplicate
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Stefan Krah added the comment:
Building matplotlib with the 2.7.2 release fails due to this issue:
Traceback (most recent call last):
File "setup.py", line 162, in
if check_for_tk() or (options['build_tkagg'] is True):
File "/home/stefan/src/matplotlib-1.0.1/s
Stefan Krah added the comment:
STINNER Victor wrote:
> > Yes, this is fixed in 3.2.
> > I just left the issue open as a reminder for the release branch.
>
> The issue is still open, can it be closed? What do you mean by "release
> branch"?
This one: http:
Stefan Krah added the comment:
I remember that I could reproduce it at the time. The issue was indeed
fixed in r85904.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue10
Stefan Schwarzer added the comment:
It turned out that although the addinfourl instance had the `__iter__`
attribute in `addbase.__init__` correctly assigned, `__iter__` wasn't found by
the `iter` builtin. It seems that `iter` always tries to use the `__iter__`
method of the _class
Stefan Krah added the comment:
[Nick]
> Another idea we may want to revisit is the PyManagedBuffer concept,
> which would be a true PyObject that existed solely to simplify sharing
> of Py_buffer structs.
> If memoryview used such an object internally, then copying and slicing
>
Stefan Schwarzer added the comment:
I was able to get some error output with the code of the OP. However, I only
saw the "opposite" message, such as:
Retrieval of
'ftp://ftp.gnome.org/pub/debian/dists/stable/main/source/Sources.bz2' failed
with error: [Errno ftp err
Stefan Schwarzer added the comment:
> I converted the script to be executable with manual intervention (see
> attachment).
This should have been "without manual intervention". :)
--
___
Python tracker
<http://bugs.pyth
Stefan Schwarzer added the comment:
I can confirm the bug for the Python 2.7 tip (changeset b11e7bc76d07) after
using the script urllibftpbug-non-interactive.py.
--
___
Python tracker
<http://bugs.python.org/issue1067
Stefan Schwarzer added the comment:
After running the adapted test script three times for Python 3 tip (changeset
c5b0585624ef), I didn't get an error message / exception.
--
Added file: http://bugs.python.org/file22485/urllibftpbug-non-interactive-p
Stefan Schwarzer added the comment:
The traceback and its context for the exception raised in Python 2.7 is:
...
###
99
Stefan Schwarzer added the comment:
Hi Senthil,
I don't yet understand what was going on before it resulted in the traceback. I
also don't understand _why_ the patch fixes _this_ bug. (That's not to say it
doesn't, but I think it's not obvious either. :-) )
Were
Stefan Krah added the comment:
Nick, you know a lot about this issue and I'm probably missing many things
here. I misunderstood your concept of PyManagedBuffer, so my previous
posting might have been hard to understand.
I'd appreciate if you (or anyone in this thread) could comm
Stefan Krah added the comment:
Pauli Virtanen wrote:
> skrah writes:
> > For example, an exporting object could provide a sliced view by adding
> > a getslicedbufferproc to PyBufferProcs:
> >
> > int PyObject_GetSlicedBuffer(PyO
Stefan Krah added the comment:
Nick Coghlan wrote:
[Snip liberally]
> The lifecycle problem is unrelated to the details of the buffer *contents*
though - it's entirely about the fact that clients can't safely copy all
those pointers (as some may refer to addresses inside th
Stefan Krah added the comment:
Hello,
The PyPI bug tracker is over here (you can find the link on the front
page of http://pypi.python.org/pypi):
http://sourceforge.net/tracker/?group_id=66150&atid=513503
That said, having checksums come from the master server exclusively
seems li
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue12468>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Stefan Krah :
After 151142c0c5b1 Valgrind finds an invalid read in symtable.c, line 907:
st->st_cur = (PySTEntryObject *)PyList_GET_ITEM(st->st_stack, size - 2);
==14301== Memcheck, a memory error detector
==14301== Copyright (C) 2002-2010, and GNU GPL'd
New submission from Stefan Krah :
I'm getting the dreaded "python_d.exe has stopped working" popups
in test_faulthandler on Windows 7 + VisualStudioPro + "Debug|x64".
--
components: Tests
messages: 139691
nosy: haypo, skrah
priority: normal
severity:
Stefan Krah added the comment:
For test_capi the patch in #9116 works. For test_faulthandler it
doesn't, unfortunately.
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
"Instead of skipping the test, I prefer to disable temporary the popup by
setting the right registry key (and then restore the previous value or delete
the key)."
Do you mean that the user should change/restore the key or that the
Python tests should
Stefan Krah added the comment:
Related issues with patches: #9116 and #11732
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue5619>
___
___
Pytho
Stefan Krah added the comment:
In order to have a basis for discussion, I've set up a repo at
http://hg.python.org/features/pep-3118#memoryview
with an implementation of PyManagedBuffer. The whole test suite
passes, also with refleak counting and Valgrind.
Review is most welcome. I
Changes by Stefan Krah :
Added file: http://bugs.python.org/file22564/bbe70ca4e0e5.diff
___
Python tracker
<http://bugs.python.org/issue10181>
___
___
Python-bugs-list m
Stefan Krah added the comment:
Nick Coghlan wrote:
> The reason redirecting all requests to the underlying object doesn't work
> is because repeated calls to getbuffer on mutable objects are allowed to
> return *different* answers. Assume we have a mutable array type that al
Stefan Krah added the comment:
Pauli Virtanen wrote:
> Comment on the patch: it seems you do not track the re-export count in
> memory_getbuf:
>
> a = memoryview(obj)
> b = numpy.asarray(a)
> a.release()
> b[0] = 123 # <-- BOOM: the buffer was already
Stefan Krah added the comment:
[I agree that multi-dimensional support should not be part of this
patch. I was thinking about creating a separate branch for that.]
Nick Coghlan wrote:
> As far as the rule of disallowing shape changes while a buffer is exported,
> I actually think th
Stefan Krah added the comment:
Nick, Pauli, thanks for all the comments. I'm busy implementing the easy
changes; then it'll be easier to deal with the flags issues.
Pauli:
Does numpy use the (undocumented) smalltable array in the Py_buffer
structure? We would like
Changes by Stefan Krah :
Added file: http://bugs.python.org/file22577/718801740bde.diff
___
Python tracker
<http://bugs.python.org/issue10181>
___
___
Python-bugs-list m
Stefan Krah added the comment:
I've uploaded a revised version that addresses several suggestions. I think
we have agreement on those now:
- Officially ditch smalltable.
- Comment static storage fields inside PyMemoryViewObject.
- Improve refcounting in PyMemoryView_FromB
Stefan Krah added the comment:
I'm slightly confused about the implication chain in the flags. PyBUF_STRIDES
seem to allow for discontiguous arrays, yet STRIDES -> ND -> C_CONTIGUOUS.
PyB
Stefan Krah added the comment:
Antoine Pitrou wrote:
> My issue is that until now sliced memoryviews are independent objects
> and are not affected by the releasing of the original memoryview. With
> this patch, they are, and that's why I'm advocating for a subtler
>
Stefan Krah added the comment:
Antoine is right, this needs to be fixed. I think that for *practical*
purposes, the existing release() method already behaves like a tryrelease()
method:
Traceback (most recent call last):
File "", line 1, in
BufferError: Existing exports of da
Stefan Krah added the comment:
[The first part of the message again, this time via the web interface.]
Antoine is right, this needs to be fixed. I think that for *practical*
purposes, the existing release() method already behaves like a tryrelease()
method:
>>> b = bytearray(b&
New submission from Stefan Sperling :
In Python-2.7.2 (I have not checked other versions, sorry),
the configure script doesn't not define LDLIBRARY on OpenBSD.
Because of this libpython.so does not get built.
--
components: Build
files: python-2.7.2-configure.diff
keywords:
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue12555>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Krah :
--
assignee: -> skrah
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue12560>
___
___
Python-bugs-list mailing list
Un
Stefan Krah added the comment:
Behavior for mixed operations varies greatly between Python versions.
The first table over here lists the differences and should be valid
for decimal.py:
http://www.bytereef.org/mpdecimal/doc/cdecimal/index.html#floatoperation-signal
As an extension, cdecimal
Stefan Krah added the comment:
This is a duplicate of #12560.
--
nosy: +skrah
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> libpython.so not built on OpenBSD
type: -> behavior
___
Changes by Stefan Krah :
--
nosy: +rpointel
___
Python tracker
<http://bugs.python.org/issue12560>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Unassigning: I tested on OpenBSD 4.5 and get other (probably unrelated
errors).
--
assignee: skrah ->
___
Python tracker
<http://bugs.python.org/issu
Stefan Krah added the comment:
I know, the OpenBSD libpthread has problems. I listed some possible
candidates in #8712.
For instance:
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/lang/python/2.6/patches/Attic/patch-Lib_test_test_signal_py?rev=1.3;content-type=text%2Fplain
The
Stefan Krah added the comment:
I forgot: readline support is enabled, and there are known problems:
http://marc.info/?t=12832732933&r=1&w=2
--
___
Python tracker
<http://bugs.python.or
Stefan Krah added the comment:
No, I didn't commit it. Currently I don't have an amd64 OpenBSD install to do
further testing.
The problem could be #12181, it could also be qemu, which sometimes has
issues with OpenBSD.
--
___
Python trac
Stefan Krah added the comment:
For the record: The other failures I mentioned were almost certainly
OpenBSD 4.5 / autoconf specific, so I didn't bother. Cairo has a
workaround, but I think that goes too far.
http://cairo.sourcearchive.com/documentation/1.9.4/cairo-atomic-private_8h-source
Stefan Krah added the comment:
The Fedora bot fails because here ...
locale.setlocale(locale.LC_CTYPE, loc)
loc = ('tr_TR', 'ISO8859-9'), and apparently setlocale can only
handle "tr_TR", but not "tr_TR.ISO8859-9":
144 if (locale
Stefan Krah added the comment:
Stefan Krah wrote:
> (gdb) p result = setlocale(category, "tr_TR.ISO8859-9")
> $8 = 0x0
> (gdb) p result = setlocale(category, "tr_TR")
> $9 = 0x96d770 "tr_TR"
> (gdb) p locale
> $10 = 0x70f6a5b0 "tr_TR.
Stefan Krah added the comment:
Yes, it's a bug. This works:
#include
#include
int
main(void)
{
char *s;
printf("%s\n", setlocale(LC_CTYPE, "tr_TR.ISO8859-9"));
printf("%s\n", setlocale(LC_CTYPE, NULL));
s = setlocale(LC_CTYPE, "tr_
Stefan Krah added the comment:
Fedora bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=726536
--
___
Python tracker
<http://bugs.python.org/issue1
Stefan Krah added the comment:
Unrelated to the Fedora issue: The test is currently skipped on the
FreeBSD bot, but completes successfully with:
diff -r 0b52b6f1bfab Lib/test/test_locale.py
--- a/Lib/test/test_locale.py Tue Aug 02 10:16:45 2011 +0200
+++ b/Lib/test/test_locale.py Tue Aug
Stefan Krah added the comment:
As I wrote on python-dev, this test also fails on Debian lenny, which has
the same setlocale() bug as Fedora.
So, indeed the test should be skipped on a multitude of platforms.
--
___
Python tracker
<h
Stefan Krah added the comment:
[Re-opening to fix the skips]
Yes, the test works on:
Ubuntu Lucid (libc-2.11.1), OpenSUSE (libc-2.11.1), FreeBSD-8.2
Failure:
Fedora 14 (libc-2.13), Debian lenny (libc-2.7), Gentoo (libc-2.13-r2)
So perhaps this test should be marked as expected
Stefan Krah added the comment:
Just a guess: it might be a stack overflow. Could you try to reduce
Py_DEFAULT_RECURSION_LIMIT in Python/ceval.c and see if you get
a RuntimeError instead?
See also: issue #1212900
--
___
Python tracker
<h
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue10588>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue10744>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Krah :
Added file: http://bugs.python.org/file22873/78fb1181787a.diff
___
Python tracker
<http://bugs.python.org/issue10181>
___
___
Python-bugs-list m
Stefan Krah added the comment:
I thought it might be productive to switch to documentation/test driven
development for PEP-3118 in general. So I updated the documentation,
trying to spell out the responsibilities of both exporter and consumer
as clearly as possible.
In order to have a PEP-3118
Stefan Krah added the comment:
This should be fixed with the ManagedBuffer implementation from #10181.
--
dependencies: +Problems with Py_buffer management in memoryobject.c (and
elsewhere?)
nosy: +skrah
___
Python tracker
<http://bugs.python.
Stefan Krah added the comment:
The crash is fixed in the features/pep-3118 repo:
>>> from numpy import array
>>> y=array([ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11])
>>> y.shape = 3,4
>>> view=memoryview(y)
>>> view2 = view[0]
Traceback (
Stefan Krah added the comment:
This should be fixed in features/pep-3118.
--
dependencies: +Problems with Py_buffer management in memoryobject.c (and
elsewhere?)
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue7
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue10746>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Krah :
--
Removed message: http://bugs.python.org/msg141927
___
Python tracker
<http://bugs.python.org/issue12730>
___
___
Python-bugs-list m
New submission from Stefan Krah :
It is somewhat complicated to calculate the number of members in
a Struct, so I propose to add Struct.nmemb (in 3.3, 3.2 and 2.7):
>>> import struct
>>> s = struct.Struct("Pxx3L3s")
>>> s.size
47
>>> s.nmemb
5
Stefan Krah added the comment:
I like random tests in the stdlib, otherwise the same thing gets tested
over and over again. `make buildbottest` prints the seed, and you can do
it for a single test as well:
$ ./python -m test -r test_heapq
Using random seed 5857004
[1/1] test_heapq
1 test OK
Stefan Krah added the comment:
Thanks for the patch. I agree with the interpretation of the format string.
One thing is unclear though: Using this interpretation the multi-dimensional
array notation in format strings only seems useful for pointers to arrays.
The PEP isn't so clear on
Stefan Krah added the comment:
Just to throw in a new name: Struct.nitems would also be possible.
--
___
Python tracker
<http://bugs.python.org/issue12
Changes by Stefan Krah :
--
nosy: +amaury.forgeotdarc, belopolsky
___
Python tracker
<http://bugs.python.org/issue11835>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
Including the format string in the error output is a good idea. Meador,
was this a constructed failure to show the output or did it really
occur?
--
___
Python tracker
<http://bugs.python.org/issue12
Changes by Stefan Krah :
Added file: http://bugs.python.org/file22909/70a8ccd53ade.diff
___
Python tracker
<http://bugs.python.org/issue10181>
___
___
Python-bugs-list m
Stefan Krah added the comment:
70a8ccd53ade fixes conversion of NumPy-style arrays to a suboffset
representation. The previous representation did not work for
slicing non-contiguous arrays with backward strides.
Also, I've added long comments that hopefully explain how slicing
with arbi
Stefan Krah added the comment:
I think PyBUF_SHADOW was the renamed version of PyBUF_UPDATEIFCOPY
from the PEP. :)
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue10
201 - 300 of 4949 matches
Mail list logo
