Stefan Krah added the comment:
I guess if some of the pickling stuff get's rewritten, we can drop
__name__.
The other thing is that traditionally the types were "decimal.Decimal"
etc., so I'm not sure if it is good idea to have "_decimal.Decimal" and
"_py
Stefan Krah added the comment:
_decimal already lies about its name (for pickling).
--
___
Python tracker
<http://bugs.python.org/issue19232>
___
___
Python-bug
Stefan Krah added the comment:
I can't apply the patch that was created with diff --git, so here is
another one that is less readable but applies.
--
Added file: http://bugs.python.org/file32066/issue19232-2.patch
___
Python tracker
Stefan Krah added the comment:
Antoine Pitrou wrote:
> You can apply it using "hg import --no-commit", I think.
mercurial 2.1 throws an exception even though the patch was created with
that version. Now I upgraded to 2.7.2 and it works.
Rietveld also seems to choke on the fi
Stefan Krah added the comment:
To be fair, for the startup time I can't really detect any difference between
importing _operator directly and the current setup.
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
About IDLE I can't say anything, but I'm not entirely sure if the
PEP-399 import method is easier to understand for users, see e.g.:
http://stackoverflow.com/questions/13194384/instantiate-decimal-class
I get the impression that the posters at first di
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue19254>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
trap() is a bit ambiguous, since in floating point operations it
means that something is actually raised and not suppressed. So one
could write:
from decimal import *
c = getcontext()
c.traps[Inexact] = True
>>> Decimal(9) / 11 # raises now!
with tra
Stefan Krah added the comment:
Zero Piraeus wrote:
> 'Ignore' and 'suppress' are not synonyms:
I wrote "synonyms here", meaning that in *this context* they are practically
synonyms. "suppress" describes the mechanics more pr
Stefan Krah added the comment:
Unfortunately the tests pass when I run them manually. On my FreeBSD
bot thsi may be relevant:
o LC_* is "C".
o The filesystem encoding is ascii.
--
nosy: +skrah
___
Python tracker
<http://bu
Stefan Krah added the comment:
I've looked at this, and the question is: Do we really need a capsule
API? All relevant symbols in _decimal start with Py* and shouldn't
need to be static.
--
___
Python tracker
<http://bugs.python.o
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
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.
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 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 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
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 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
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 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
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
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 Krah added the comment:
Memoryview sends a *request* to ctypes to fill in a Py_buffer struct according
to the buffer *protocol*. IOW, memoryview knows nothing about ctypes.
For some reason ctypes fills in 'B' as the format if _pack_ is set. I do not
know if that is intended
2201 - 2300 of 3396 matches
Mail list logo
