Stefan Krah added the comment:
I believe you, but I'd like to understand why. :)
It seems to me that a module and also PyInit_xxx() can be loaded portably.
Say the handles to the module are cached somewhere after loading and
initializing. I think this already happens in Python/dynload_sh
Stefan Krah added the comment:
The hpux bot fails at the compile stage:
http://buildbot.python.org/all/builders/IA64%20HP-UX%2011iv3%20%5BSB%5D%203.x/builds/2152/steps/compile/logs/stdio
ld -b
build/temp.hp-ux-B.11.31-ia64-3.4-pydebug/home/cpython/buildslave/3.x.snakebite-hpux11iv3-ia64-1
Stefan Krah added the comment:
A test order problem is indeed unlikely: I ran the tests as the buildbot user
with the same random seed and they passed. Let's blame the buildbot software. ;)
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
Marc-Andre Lemburg wrote:
> This may work on Linux (and probably does if you use the right
> DL flags), but I don't think this works reliably or at all on other
> platforms such as Windows. Symbols from shared libs are not necessarily
> avail
Stefan Krah added the comment:
The --without-threads buildbot fails, so I guess all tests need to be
skipped in that case:
http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/5333/steps/test/logs/stdio
--
nosy: +skrah
New submission from Stefan Krah:
I'm splitting this off of #19262, since certain failures (hanging for
one hour) remind me of #15599, which is an issue of epic proportions.
Also it should not be a release blocker, since threading failures under
FreeBSD-9 (running under KVM!) aren'
Stefan Krah added the comment:
If the FreeBSD-9.0 bot is heavily loaded, some tests have to be relaxed
(see patch). I can make them conditional on FreeBSD if you prefer.
The hanging still occurs sporadically.
--
___
Python tracker
<h
Changes by Stefan Krah :
--
keywords: +patch
Added file: http://bugs.python.org/file32209/issue19285.patch
___
Python tracker
<http://bugs.python.org/issue19
Changes by Stefan Behnel :
--
nosy: -scoder
___
Python tracker
<http://bugs.python.org/issue16612>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Stefan Krah:
I'm referring to msg200288. I guess this is low priority, since
not many people will want to use asyncio on a build --without-threads.
--
keywords: buildbot
messages: 200399
nosy: gvanrossum, skrah
priority: low
severity: normal
stage: needs
Stefan Krah added the comment:
Meanwhile, the patch addresses the buildbot failure. I currently don't
have access to the machine with my ssh-key, so I can't commit the patch
right now.
--
keywords: +patch
Added file: http://bugs.python.org/file3/issue1
New submission from Stefan Krah:
unittest produces the following resource warnings:
$ ./python -m test -uall test_asyncio
[1/1] test_asyncio
/home/stefan/hg/master/Lib/unittest/case.py:571: ResourceWarning: unclosed
testMethod()
/home/stefan/hg/master/Lib/unittest/case.py:571
Stefan Krah added the comment:
Yes, the fix can certainly be delayed -- it's just a minor thing that's
as little distracting.
--
___
Python tracker
<http://bugs.python.o
Stefan Krah added the comment:
I think the failure is not only on AIX. The FreeBSD bots had similar
failures, and here is one on PPC Linux:
http://buildbot.python.org/all/builders/PPC64%20PowerLinux%203.x/builds/881/steps/test/logs/stdio
Timeout (1:00:00)!
Thread 0x008074e46670:
File
Stefan Krah added the comment:
Ok, the timings have been adjusted, so I'm making #19293 a superseder
for the hanging issue.
--
resolution: -> duplicate
status: open -> closed
superseder: -> test_asyncio failures on AIX
___
Python
Changes by Stefan Krah :
--
title: test_asyncio failures on AIX -> test_asyncio hanging for 1 hour
___
Python tracker
<http://bugs.python.org/issue19293>
___
_
Stefan Krah added the comment:
> Not sure if I'll ever want to support this...
I think it can be closed as "wont-fix". We had a poll on python-dev
about --without-threads a while ago, and the only systems that needed
it were older OpenBSD systems and a Fujitsu supercompute
Stefan Krah added the comment:
It looks like it happened again:
http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/5223/steps/test/logs/stdio
==
ERROR: test_default_timeout
Stefan Krah added the comment:
I'm also in favor of a clean separation between the concrete and abstract
APIs (see also #12965). Why can't the concrete functions be locked down
with *CheckExact()? If there's any breakage in third party modules,
it's easy to fix (probably
Stefan Krah added the comment:
The build --without-doc-strings still fails on the FreeBSD-9.0 bot.
Antoine, could we make that option official on my build slave? Currently
I'm subverting the build system by exporting an environment variable.
It does not seem to be a heavy maintenance b
Stefan Krah added the comment:
Antoine Pitrou wrote:
> Done. Can you please watch for failures and ensure they get fixed?
Thanks! Yes, I'll keep an eye on it.
--
___
Python tracker
<http://bugs.python.org
Stefan Krah added the comment:
Matej Cepl wrote:
> Is this the same as when tests with python-3.3.2 fails on me with RHEL-6?
If LC_CTYPE is UTF-8 and LC_NUMERIC something like ISO-8859-2 then it's
the same issue.
--
___
Python tracke
Stefan Krah added the comment:
Here's the fix for --without-doc-strings (can't commit right now).
--
Added file: http://bugs.python.org/file32297/issue19030-without-docstrings.patch
___
Python tracker
<http://bugs.python.o
Stefan Krah added the comment:
Matej Cepl wrote:
> To #200912: now, system locale is UTF-8 all the way:
> santiago:python3 (el6) $ locale
> LANG=en_US.utf8
> LC_CTYPE="en_US.utf8"
> LC_NUMERIC=en_IE.utf8
> LC_TIME=en_IE.utf8
> LC_COLLATE="en_US.utf8&quo
Stefan Krah added the comment:
Matej Cepl wrote:
> >>> import locale
> >>> locale.localeconv()
> {'p_cs_precedes': 127, 'n_sep_by_space': 127, 'n_sign_posn': 127,
> 'n_cs_precedes': 127, 'grouping': [], '
Stefan Krah added the comment:
Ethan Furman wrote:
> Stefan, do the other tests in PydocWithMetaClasses continue to work on your
> FreeBSD 9.0 box without docstrings? Because they all fail on my Linux Ubuntu
> 13.04 box.
I tested on Debian, and the remaining tests seem to work (
Stefan Krah added the comment:
STINNER Victor wrote:
> The following PostgreSQL issue looks to be the same than this Python issue:
> http://www.postgresql.org/message-id/20100422015552.4b7e0754...@cvs.postgresql.org
>
> The fix changes temporarly the LC_CTYPE encoding:
So d
Stefan Krah added the comment:
Victor, thanks for the comments. I also think we should set LC_CTYPE closer
to the actual call to mbstowcs(), otherwise there are many API calls in
between.
So it should happen somewhere in PyUnicode_DecodeLocaleAndSize(). Perhaps
we can create
Stefan Krah added the comment:
Matej Cepl wrote:
> santiago:optimized (el6) $ ./python -m test test_format
> [1/1] test_format
> 1 test OK.
It looks like some other test in the test suite did not restore a changed
locale. If you're motivated enough, you could try if it still
Stefan Krah added the comment:
STINNER Victor wrote:
> "So it should happen somewhere in PyUnicode_DecodeLocaleAndSize(). Perhaps we
> can create _PyUnicode_DecodeLocaleAndSize() which would take an LC_CTYPE
> parameter?"
>
> For this issue, it means that Python
Stefan Krah added the comment:
Christian, could you have a look? I think this was added in #19324.
--
nosy: +christian.heimes, skrah
___
Python tracker
<http://bugs.python.org/issue19
New submission from Stefan Krah:
Lifting this from #7442:
"Very plain checkout of git and ./configure && make && make test leads to
another failed test, but not this one (issue #19353). So either we do
something wrong in all those Fedora patches, or this has been fixed
si
Stefan Krah added the comment:
Here's a quick-and-dirty version of mbstowcs_l(). The difference in the
benchmark to the plain mbstowcs() is 0.82s vs 0.55s. In the context of
a Python function this is unlikely to be measurable.
--
___
Python tr
Changes by Stefan Krah :
Added file: http://bugs.python.org/file32306/mbstowcs_l.c
___
Python tracker
<http://bugs.python.org/issue7442>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
> I see a crash in test_capi and a couple of crashes
> in test_faulthandler but these don't seem to be related.
Perhaps the same as #9116.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.
Stefan Behnel added the comment:
-1 on any changes that make the specific C-API functions less specific. They
are perfectly adequate for gaining speed in well defined situations.
+0 on any changes that special case concrete types in abstract calls if they
prove to be worth the hassle.
+1 for
New submission from Stefan Krah:
The attached syntax error should probably be handled by clinic.py.
--
components: Demos and Tools
files: syntax-err-1.patch
keywords: patch
messages: 201246
nosy: skrah
priority: normal
severity: normal
status: open
title: clinic.py: unhandled syntax
Changes by Stefan Krah :
--
nosy: +larry
___
Python tracker
<http://bugs.python.org/issue19390>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
Nick Coghlan added the comment:
> Antoine Pitrou added the comment:
>> To be clear: the problem is with CPython calling the concrete APIs when
>> it shouldn't, rather than with the concrete APIs not behaving properly.
>
> The boiler
Stefan Krah added the comment:
Larry Hastings wrote:
> You're proposing that Clinic allow => ?
No, but it should print an error message and exit. Currently it silently
generates garbage which does not compile.
[I've noticed that you handle many other syntax e
Stefan Krah added the comment:
Yeah, HAVE_DOCSTRINGS was added when we were not sure whether to skip C
and Python docstrings separately.
I agree that the right thing is to have both requires_c_docstrings
and requires_py_docstrings.
--
___
Python
Stefan Krah added the comment:
For reference see #17041 and msg180774. Separating the decorators
makes things clearer (after all we're dealing with extremely obscure
features here), merging them could mean less work.
--
___
Python tracker
Stefan Krah added the comment:
I'm getting a couple of Valgrind leaks, starting with 1edff836c954:
valgrind --suppressions=Misc/valgrind-python.supp --leak-check=full ./python -c
"pass"
All of them seem to be in _PySys_Init().
--
nosy: +skrah
Added file: http://
Stefan Krah added the comment:
One example of a leaked object is "hexversion", from sysmodule.c:1615.
I tried adding it to sys_deletes[] in import.c, but it did not help.
See valgrind.out for other leaks.
--
___
Python trac
Stefan Krah added the comment:
IMO we have two references to many newly created values in _PySys_Init():
SET_SYS_FROM_STRING("hexversion",
PyLong_FromLong(PY_VERSION_HEX));
One from PyLong_FromLong() and the other from PyDict_SetItemString() in the
Stefan Krah added the comment:
Victor, could you look at the end of #10241? Starting from 31796b188bec,
many values in _PySys_Init() have 2 references. Why is that required?
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue18
Stefan Krah added the comment:
See also 31796b188bec.
--
___
Python tracker
<http://bugs.python.org/issue10241>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Antoine Pitrou wrote:
> Does pulling the Py_DECREF before the "if" fix the leaks?
Yes, but I get an additional failure in test_capi. Apparently not all values
require the DECREF. Got to look on a case
Stefan Krah added the comment:
Ah, thanks. I was wondering if there was some obscure reason that escaped me.
--
___
Python tracker
<http://bugs.python.org/issue18
Stefan Krah added the comment:
Valgrind is happy after the recent 5eb00460e6e8.
--
___
Python tracker
<http://bugs.python.org/issue10241>
___
___
Python-bug
Stefan Krah added the comment:
Serhiy, probably a false positive:
https://bugs.kde.org/show_bug.cgi?id=298281
--
___
Python tracker
<http://bugs.python.org/issue3
New submission from Stefan Krah:
There's a leak in _hashopenssl.c. Patch attached.
--
files: _hashopenssl.patch
keywords: patch
messages: 201527
nosy: skrah
priority: normal
severity: normal
status: open
title: Leak in _hashopenssl.c
Added file: http://bugs.python.org/file
New submission from Stefan Krah:
I'm getting the following test_multiprocessing_fork failures on Debian
Wheezy. Perhaps this is related to #19227:
test_default_timeout (test.test_multiprocessing_fork.WithThreadsTestBarrier)
... Exception in thread Thread-344:
Traceback (most recent call
Stefan Krah added the comment:
The issue is probably different from #19227, since it already occurs
with 4e79c3ae8a12.
--
components: +Extension Modules
nosy: +sbt
stage: -> needs patch
type: -> behavior
versions: +Python 3.3, Python 3.4
___
Stefan Krah added the comment:
I've seen the failure very often, without any particular load.
Now I noticed that during test_tools there were several ksoftirqd
processes consuming 20% CPU on 4 cores. That seemed unusual to
me, so I followed the advice of a certain MIT koan and reb
Stefan Krah added the comment:
I understand the desire to speed things up, but either the four-line facade
module or else a single module is probably required by PEP-399.
--
title: operator.py: move the Python implementation in the else block of
try/except ImportError -> operator
Stefan Behnel added the comment:
How about actually allowing a list in addition to a tuple? And, in fact, any
sequence? I can't see a reason not to.
For reference, lxml only expects it to be either None or an iterable.
Essentially, I consider it more of a set-like filter, since the l
Stefan Krah added the comment:
Since this is tagged "crash", I'm curious if you managed to crash
_decimal. The unhandled return in convert_op_cmp should result in
AtrributeError("object does not have a numerator attribute").
The exception that wasn't set in dec_f
New submission from Stefan Behnel:
The "tp_print" slot is still documented as it was in Py2, although it is no
longer used in Py3.
http://docs.python.org/3.4/c-api/typeobj.html?highlight=tp_print#PyTypeObject.tp_print
Given that it no longer serves any purpose, it should a
Stefan Krah added the comment:
Ok, I found it. It was an assert() in debug mode that the MemoryError from
PyObject_IsInstance() was swallowed. In production mode AttributeError
would have been raised.
Program received signal SIGABRT, Aborted.
0x771e0475 in *__GI_raise (sig=) at
Stefan Behnel added the comment:
Brecht Machiels, 03.11.2013 11:58:
> With Python 3.2, I subclassed ElementTree.XMLParser to set
> ExternalEntityRefHandler on the XMLParser's (expat) 'parser' member
This sounds like a request for a missing feature to me. Here is how l
Stefan Krah added the comment:
Yes, I saw the comments. I'm still wondering if we should just write an
mbstowcs_l() function instead.
Even then, there would still be a small chance that a C extension that
creates its own thread picks up the wrong LC_
Stefan Krah added the comment:
STINNER Victor wrote:
> What is this locale_t type used for the locale parameter of mbstowcs_l()?
> Are you sure that it is a string? According to this patch, it looks like a
> structure:
> http://www.winehq.org/pipermail/wine-cvs/2010-May/067264.ht
Stefan Krah added the comment:
R. David Murray wrote:
> So the question is, if there is no longer a reference to the docstring, why
> isn't it garbage collected? (I tested adding a gc.collect(), and it didn't
> make any difference.)
I think it probably is garbage coll
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue19537>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
It looks like the memory management is based directly on Py_Arenas:
def f():
"""squeamish ossifrage"""
pass
Breakpoint 1, PyArena_Free (arena=0x9a5120) at Python/pyarena.c:159
159 assert(arena);
(gdb) p arena-&g
Stefan Krah added the comment:
Andreas Schwab wrote:
> (gdb) p sizeof(PyASCIIObject)
> $1 = 22
m68k again? ;)
--
___
Python tracker
<http://bugs.python.org/i
New submission from Stefan Richter:
When using urllib2 and specifying a HTTPS proxy when setting up a ProxyHandler,
the library does not encrypt the traffic sent to the proxy server. This results
in unpredictable behavior.
Either the support should be implemented or an error raised
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue19537>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
The comment says that semaphores are broken up to FreeBSD-8, so
linking with -lrt is disabled. This looks correct to me and our
FreeBSD 9 and 10 buildbots work.
If you have a specific problem, please re-open the issue.
--
nosy: +skrah
resolution
Changes by Stefan Krah :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue19554>
___
___
Python-bugs-list mailing list
Unsubscrib
Stefan Krah added the comment:
I looked at patch set 1, which actually *reduced* functionality for FreeBSD >=
9.
Now there is a second patch set, so I'm re-opening.
--
___
Python tracker
<http://bugs.python.org
Changes by Stefan Krah :
--
resolution: invalid ->
stage: committed/rejected ->
status: closed -> open
___
Python tracker
<http://bugs.python.or
Changes by Stefan Krah :
--
dependencies: +Automatically regenerate platform-specific modules
nosy: +lemburg
___
Python tracker
<http://bugs.python.org/issue19
Stefan Krah added the comment:
See also #19554.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue12619>
___
___
Python-bugs-list mailing list
Unsub
Stefan Krah added the comment:
-1 on complicating the code further. It would be possible to pass
an existing memoryview to mbuf_add_view(). That would save the line
mv = memory_alloc().
But:
a) You need to check that ndim is correct (shape, strides and
suboffsets are allocated via
Stefan Krah added the comment:
You could experiment with multiple freelists, one for each ndim.
I'm skeptical however that the gain will be substantial. I've tried
freelists for _decimal and the gain was in the order of 2% (no
Stefan Krah added the comment:
> With the patch, the deletion succeeded even if you get a MemoryError. The
> bytearray object is consistent. It's just that its buffer could be smaller
> (it wastes memory).
I think intuitively I'd expect the object to be unmodified if
Stefan Krah added the comment:
Can you suppress the MemoryError if deletion succeeds? That would be ok IMO.
--
___
Python tracker
<http://bugs.python.org/issue19
Stefan Behnel added the comment:
Thanks!
--
nosy: +scoder
___
Python tracker
<http://bugs.python.org/issue19609>
___
___
Python-bugs-list mailing list
Unsub
Stefan Krah added the comment:
To my surprise, this line is 10% faster with a freelist:
./python -m timeit -s "import array; a = array.array('B', [0]*100); m =
memoryview(a)" "m[30:40]"
I think the reason is that PyOb
Changes by Stefan Krah :
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue19638>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
The leaks still exist here.
--
___
Python tracker
<http://bugs.python.org/issue13090>
___
___
Python-bugs-list mailing list
Unsub
New submission from Stefan Holek:
This test passed in Python <= 3.3 but fails in 3.4:
def testTestSuiteConsumesTest(self):
class MyTestCase(unittest.TestCase):
def testMethod(self):
pass
test = MyTestCase('testMethod')
Stefan Holek added the comment:
I have some complex test fixtures that I have written tests for, and one of
them started to fail because it assumed that the suite would still be valid
after having run.
That said, I was able to work around the issue and if you don't care neither
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue19655>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
David is correct: No data is copied, but new memoryview objects with different
shape and strides are created. That is relatively cheap.
--
nosy: +skrah
resolution: -> invalid
stage: -> committed/rejected
status: open -> closed
type: en
Stefan Krah added the comment:
I think it's possible to get used to the markers. However, to bikeshed a
little, I would prefer "preprocessor" instead of "clinic", since jokes
tend to wear off if one sees then too often.
--
nosy: +skrah
_
Stefan Krah added the comment:
Development of libmpdec has effectively happened on hg.python.org
since I included _decimal. That's also one of the reasons why there
isn't any public VCS. The mailing list isn't archived because I'm
using ezmlm and ezmlm's retrieva
Stefan Krah added the comment:
I have prepared Python-3.3+ for use with libmpdec.so.2:
cbd78679080b
9d07b3eb34e3
Here is a prerelease for mpdecimal:
http://www.bytereef.org/software/mpdecimal/releases/mpdecimal-2.4-rc1.tar.gz
sha256sum
Changes by Stefan Krah :
--
nosy: +Arfrever
___
Python tracker
<http://bugs.python.org/issue19732>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Matthias Klose wrote:
> 2.4~rc1:
> - configure.ac should call AC_CANONICAL_HOST, config,guess and
>config.sub should be included.
Hmm. configure.ac doesn't use any of the variables set by that macro, and this
appears to work:
./configure --h
Stefan Krah added the comment:
Matthias Klose wrote:
> > ./configure --host=arm CC=arm-linux-gnueabi-gcc-4.7
>
> sure, but this should work without explicitly setting CC.
I can't get it to work without passing CC even with config.guess and
config.sub. If you want it to work,
Stefan Krah added the comment:
Apparently the build failed because only arm-linux-gnueabi-gcc-4.7 was installed
but not arm-linux-gnueabi-gcc.
But the cross build succeeds with the original 2.4-rc1, except that
arm-linux-gnueabi-ar
isn't picked up:
$ ./configure --host=arm-linux-gn
Stefan Krah added the comment:
> (gdb) p sizeof(PyASCIIObject)
> $1 = 22
If the only issue is that the size should be 24 instead of 22,
could we perhaps add an unused uint16_t to the struct just
for this architecture?
--
nosy: +skrah
___
Stefan Krah added the comment:
I've fixed cross-compiling and a couple of small issues in the
repo from msg20434. Cross-compiling seems to work also without
config-guess, but I've included it anyway.
--
___
Python tracker
<http://bu
Changes by Stefan Richter :
--
versions: +Python 2.6, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python
3.5
___
Python tracker
<http://bugs.python.org/issue19
Stefan Krah added the comment:
Memoryview currently only knows the types from the struct module.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue19
Stefan Krah added the comment:
>>> class B1(ctypes.Structure):
... _fields_ = [("data", ctypes.c_uint8 * 256), ]
... _pack_ = 1
...
>>> a= B1()
>>> x = memoryview(a)
>>> x.format
'B'
In the first case the format is
Stefan Behnel added the comment:
If (as I assume) XML 1.1 isn't supported, then rejecting anything but "1.0"
would be correct.
Not for Py2.7 anymore, though, I guess, more something to fix for 3.4.
--
___
Python tracker
<http
3301 - 3400 of 4952 matches
Mail list logo
