New submission from Stefan Krah:
This issue is for the _decimal specific parts from #4555. The patch
depends on _Pragma (C99) and gcc >= 4.0 for the contents of the pragma.
I think it will work for clang, too.
Should the libmpdec API symbols (i.e. the ones starting with mpd_*)
be hidden
Stefan Krah added the comment:
Adding everyone from issue #4555, in case you can think of a different
(portable) solution for hiding symbols (with minimal effort).
--
nosy: +christian.heimes, dmalcolm, doko, lemburg, loewis, pitrou
___
Python tracker
Stefan Krah added the comment:
Meador Inge wrote:
> Personally I prefer using attributes instead of pragmas. The GCC manual
> recommends such as well.
I followed www.akkadia.org/drepper/dsohowto.pdf . Drepper seems to be fine
with the use of pragmas in internal headers.
> There
New submission from Stefan Krah:
This is strictly a buildbot issue. #include seems broken on
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%203.3/builds/248/steps/compile/logs/stdio
In file included from /usr/include/ctype.h:83,
from
/usr/home
Changes by Stefan Krah :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Stefan Krah added the comment:
Hmm. Judging by the numbers for the Python version, my machine appears
to be slower than Stefan (Behnel)'s machine, and yet the C version is
much faster here than the posted Cython numbers.
If I adjust the results for the machine differences, the C version
Stefan Krah added the comment:
I've managed to build the Cython version now. It's in fact between 4 and 6
times slower here than the C version.
--
___
Python tracker
<http://bugs.python.o
Stefan Krah added the comment:
Thanks, it's really a FreeBSD issue then. I was wondering how this
could go undetected in a production release. The reason is probably
that __GNUC_STDC_INLINE__ (which libmpdec uses) is quite rare.
--
resolution: -> invalid
stage: -> committ
Stefan Krah added the comment:
On second thought, gcc defines __GNUC_STDC_INLINE__ to 1, so probably
libmpdec should do the same.
--
___
Python tracker
<http://bugs.python.org/issue16
Stefan Krah added the comment:
Perhaps I misunderstood something, but test_decimal.py *is* using the
exact idiom from PEP-399 and it works. Why do you want to "fix" the
usage of this idiom?
--
nosy: +skrah
___
Python tracker
<http://bu
Stefan Krah added the comment:
I finally understood the issue. So this does not work:
./python -m unittest discover Lib/test/ 'test_dec*.py'
Neither does this:
./python -m unittest discover Lib/test/ 'test_multipro*.py'
And this fails, too (still hanging):
Changes by Stefan Krah :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue9709>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
I think this is the same as #9709. Please just reopen if it isn't.
--
nosy: +skrah
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> test_distutils warning: initfunc exported
Stefan Krah added the comment:
Yes, currently the C version is also used for unpickling. Actually
this problem was one of the reasons why _decimal sets its name to
"decimal".
from test.support import import_fresh_module
import pickle, sys
C = import_fresh_module('xml.et
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue16748>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Daniel Shahaf wrote:
> Is there a requirement that it loads a particular module? Would etree
> users notice the difference if pickle.load() returns an instance of the
> "other" Element implementation than the one they pickled?
Stefan Krah added the comment:
unicode-leak.patch doesn't fix #16143 though. unicode_empty and
unicode_latin1 need to be initialized, too.
Actually we could close this in favor of #16143.
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
Closing as a duplicate of #10156, which has several patches.
--
resolution: -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder: -> Initialization of globals in uni
Changes by Stefan Krah :
--
nosy: +Gregory.Andersen, georg.brandl, kushou, pitrou
___
Python tracker
<http://bugs.python.org/issue10156>
___
___
Python-bugs-list m
Changes by Stefan Krah :
--
priority: high -> critical
___
Python tracker
<http://bugs.python.org/issue10156>
___
___
Python-bugs-list mailing list
Unsubscri
Stefan Krah added the comment:
The utf_32_le_decode invalid access is gone; for Valgrind the issue
is fixed (I didn't look at the patch, no time ATM, sorry).
--
___
Python tracker
<http://bugs.python.org/i
Stefan Krah added the comment:
Nick, I'm adding you to the nosy list since this issue seems related to PEP 432.
Quick summary: Globals are used in unicodeobject.c before they are initialized.
Also, Unicode objects are created before PyType_Ready(&PyUnicode_Type) has been
called.
Thi
Stefan Krah added the comment:
Nick Coghlan wrote:
> There should still be a check in tp_new (IIRC) that calls PyType_Ready on
> unready types.
Indeed there is one in type_new(), but that isn't used here AFAICS. If
you apply this patch and start up python, there are many &quo
Stefan Krah added the comment:
What is the output of this?
>>> locale.localeconv()
{'mon_decimal_point': ',', 'frac_digits': 2, 'p_sign_posn': 1, 'thousands_sep':
'.', 'p_sep_by_space
Stefan Krah added the comment:
127 means "no-more-grouping", so Python behaves as instructed by the OS.
As you see, the OS prescribes 1.345.677,222 for *monetary* quantities
and 1345677,222 otherwise.
According to http://de.wikipedia.org/wiki/DIN_1333 , for non monetary
quantitie
Stefan Krah added the comment:
I agree, we can't really do anything here.
--
resolution: -> invalid
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.pyth
New submission from Stefan Krah:
This issue proposes an additional 'm' format specifier that behaves like
'n', but uses mon_grouping, mon_decimal_point and mon_thousands_sep.
See #16944 for the rationale.
--
components: Interpreter Core
messages: 179955
nosy: Pet
Stefan Krah added the comment:
In the absence of an enum type, string constants are nicer to read in
the REPL, so here's a patch. Translating between strings and ints is
fast if you use the module constants.
--
keywords: +patch
Added file: http://bugs.python.org/file28736/issue
Stefan Krah added the comment:
In the version I committed the string constants are interned, so
anything but legacy strings should be reasonably fast.
--
assignee: -> skrah
components: +Extension Modules
resolution: -> fixed
stage: -> committed/rejected
status: open
New submission from Stefan Krah:
_ssl is not built on the Fedora buildbot:
http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/3798/steps/test/logs/stdio
building '_ssl' extension
gcc -fPIC -Wno-unused-result -g -O0 -Wall -Wstrict-prototypes -I./
Stefan Krah added the comment:
In 3.3 libffi has been updated to 3.0.11. Our clang buildbot does not
show this particular warning, but still fails to compile libffi:
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%2Bclang%203.3/builds/320/steps/compile/logs/stdio
It
Stefan Krah added the comment:
Thanks for the link. The diff was committed last week to the upstream
libffi development tree, so I backported it.
--
assignee: -> skrah
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: -> behavior
versio
Stefan Krah added the comment:
Fixed in OpenBSD 5.2.
--
resolution: -> out of date
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Stefan Krah added the comment:
All threading issues are fixed in OpenBSD 5.2.
--
resolution: -> out of date
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Stefan Krah added the comment:
On OpenBSD 5.2 this is fixed. The AIX buildbot looks okay and I doubt
that anyone will commit something for Solaris 9.
--
nosy: +skrah
resolution: -> out of date
stage: test needed -> committed/rejected
status: open -&g
Stefan Krah added the comment:
Could we merge this with #6419?
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue16952>
___
___
Python-bugs-list m
Stefan Krah added the comment:
This is a duplicate of #11729, which is fixed.
--
nosy: +skrah
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> libffi assembler relocation check is not robust, fails with
clang
type: ->
Stefan Krah added the comment:
Trent, do you want to keep this open? I think sys.mk is behaving exactly
as intended.
--
___
Python tracker
<http://bugs.python.org/issue15
Stefan Krah added the comment:
Does this apply to Python 3.3 as well? I don't think we're going to
fix this in 2.7.
--
nosy: +skrah
status: open -> pending
___
Python tracker
<http://bugs.pytho
Changes by Stefan Krah :
--
assignee: -> skrah
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: +Python 3.4
___
Python tracker
<http://bugs.python
Stefan Krah added the comment:
Since this occurs only on 2.7 and *very* rarely, let's close it.
--
resolution: out of date -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.
Changes by Stefan Krah :
--
assignee: -> skrah
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python
Stefan Krah added the comment:
What is in sample.txt? I cannot reproduce this with a source build
(Windows 7, 64-bit pgo build):
Python 2.7.3+ (default, Jan 17 2013, 20:26:24) [MSC v.1500 64 bit (AMD64)] on
win32
Type "help", "copyright", "
New submission from Stefan Krah:
Since 5e33b27c71a8 SHLIB_EXT is not set in configure.ac, since
the block in which $SO is defined has been moved below this line:
AC_DEFINE_UNQUOTED(SHLIB_EXT, "$SO", [Define this to be extension of shared
libraries (including the dot!).])
Thi
Stefan Krah added the comment:
I tend to agree with the argument that the removal of intobject.h was
a good thing, since it avoids subtle errors.
Probably no one wants to reinstate intobject.h at this point, so unless
there are objections, I'll update the docs in a couple of
Changes by Stefan Krah :
--
assignee: -> skrah
keywords: +3.3regression
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python
Stefan Krah added the comment:
koobs wrote:
> Stefan, can we merge this to the 2.7 branch as well please?
If Benjamin is okay with it, yes. The problem with these configure fixes
is that they might break other systems in unexpected ways. I already hesitated
to put it into 3.3, but
Stefan Krah added the comment:
The buildbot coverage is good, but the number of (OS, shell, compiler)
combinations is much higher.
--
___
Python tracker
<http://bugs.python.org/issue11
Stefan Krah added the comment:
Several 2.7 buildbots are failing.
> Unfortunately I have only platforms where sizeof(int) == sizeof(long) ==
sizeof(size_t).
You can use your cpython ssh key to login to all snakebite buildbot
machines. They are tagged with [SB].
http://mail.python.
Changes by Stefan Krah :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.3, Python 3.4 -Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.o
Stefan Krah added the comment:
Serhiy, test_pathext_checking still fails on many Windows buildbots:
http://buildbot.python.org/all/waterfall?category=3.x.stable&category=3.x.unstable
--
nosy: +skrah
status: closed -> open
___
Python tracker
Stefan Krah added the comment:
I just ran the 2.7 tests while dealing with another issue, and
I'm getting a memory error or excessive swapping in test_ucn:
The statement
x = b'\\N{SPACE' + b'x' * int(_testcapi.UINT_MAX + 1) + b'}'
uses over 8GB on my
Stefan Krah added the comment:
The test is fixed here, thanks.
The limits appear to be different in 2.7 and 3.4: In 2.7 the bigmem tests
are executed with -M x > 16G, in 3.4 with -M x >= 12G.
I don't know if that's deliberate, ju
Stefan Krah added the comment:
> It is in the combination with jumpahead(), getstate(), setstate() that you'll
> experience random() to produce values >= 1.0
Let me reiterate what David said: Can you post a self-contained program
that exhibits the issue?
-
Stefan Krah added the comment:
Since Rietveld didn't mail me this time: I left some comments on the 2.7 patch.
--
versions: +Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
The 2.7 comments also apply to the 3.2 patch. Otherwise the 3.2 patch
(without the _sre changes :) looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue10
Stefan Krah added the comment:
Floris van Manen wrote:
> From what i understand is that issue14591 was able to reproduce the same
> feature as it seems related to the jumpahead() malfunctioning.
I'm also quite sure that it's the same issue. It would be nice to have
confirm
Stefan Krah added the comment:
Nice. I think the latest patches are commit-ready.
--
___
Python tracker
<http://bugs.python.org/issue10156>
___
___
Python-bug
Stefan Krah added the comment:
Floris van Manen wrote:
> Did compile that version and it launches.
> To test with my code i do not want to have it interfere with my current
> version.
> I remember it is possible to setup n isolated environment with pip en
> virtualenv.
> Bu
Stefan Krah added the comment:
I've already committed a decorator in 5c7f92bfe785, but it isn't
quite robust. I think the one in issue17041-decorator.diff should
do the trick.
Also, we then can use support.HAVE_DOCSTRINGS for some doctests.
--
Added file: http://bugs.
Stefan Krah added the comment:
Serhiy Storchaka wrote:
> > It seems like it would make more sense to combine both checks into one
> > decorator.
>
> These are different cases. @unittest.skipIf(sys.flags.optimize >= 2) is about
> docstrings in Python
Stefan Krah added the comment:
Please don't change this: It's a common pattern in C to undo memory
allocations in the opposite order.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.o
New submission from Stefan Krah:
Found this in test_codecs running under Valgrind (Python 3.3):
test_bug1251300 (test.test_codecs.UnicodeInternalTest) ... ==11511== Invalid
read of size 1
==11511==at 0x44AF37: _PyUnicode_DecodeUnicodeInternal
(unicodeobject.c:6133)
==11511==by
Stefan Krah added the comment:
Same in test_codeccallbacks:
test_badhandlerresults (test.test_codeccallbacks.CodecCallbackTest) ...
==11604== Invalid read of size 1
==11604==at 0x44AF37: _PyUnicode_DecodeUnicodeInternal
(unicodeobject.c:6133)
==11604==by 0x4DEB5C
Stefan Krah added the comment:
The patches are really small, so +1 for committing this before the
rc1 for 2.7.4 is released.
--
___
Python tracker
<http://bugs.python.org/issue17
Stefan Krah added the comment:
I left some comments but have no indication that they got mailed.
--
___
Python tracker
<http://bugs.python.org/issue17041>
___
___
Stefan Krah added the comment:
Buildbots etc. look all good. Thanks for fixing this.
--
___
Python tracker
<http://bugs.python.org/issue10156>
___
___
Python-bug
Changes by Stefan Krah :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10156>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Stefan Krah :
--
resolution: -> fixed
stage: patch review -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue10156>
___
___
Stefan Krah added the comment:
Moderately opposed, yes. PyMem_Malloc()/PyMem_Free() and PyMem_New()/PyMem_Del()
are already explained in depth above.
--
___
Python tracker
<http://bugs.python.org/issue17
Stefan Krah added the comment:
Right, keeping the cases separate is indeed clearer.
Serhiy, in case you are waiting for my "stick to minimal changes" comment to be
resolved: People apparently *do* use --without-doc-strings, so the additional
code in test_pydoc.py is r
Stefan Krah added the comment:
doctests_without_docstrings.patch looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue17041>
___
___
Python-bug
Stefan Krah added the comment:
Serhiy, if you have time, I think it would be nice to get the remaining
fix into the upcoming release candidates.
--
___
Python tracker
<http://bugs.python.org/issue17
Stefan Krah added the comment:
This is mainly about Py_CLEAR(), right? The initializations to NULL should
be guaranteed by the C standard.
--
___
Python tracker
<http://bugs.python.org/issue17
Stefan Krah added the comment:
Yes, it's guaranteed:
6.7.8 Initialization
10) If an object that has automatic storage duration is not initialized
explicitly, its value is indeterminate. If an object that has static
storage duration is not initialized expli
Stefan Krah added the comment:
Thanks for the report. I cannot reproduce it with the latest 3.2 version.
Perhaps the version shipped with Ubuntu 11.04 has this problem.
--
nosy: +doko, skrah
___
Python tracker
<http://bugs.python.org/issue17
Stefan Krah added the comment:
IOW, my advice is to get Python 3.3 from hg.python.org and see if
you can reproduce the issue.
--
___
Python tracker
<http://bugs.python.org/issue17
Stefan Krah added the comment:
Thanks for testing. The problem with the Ubuntu Python
"Python 3.2 (r32:88445, Oct 20 2012, 14:09:50)"
is that it seems to be a patched 3.2.0, while we're already at 3.2.3.
So it might be worth reporting this issue to Ubuntu.
--
resolu
Stefan Krah added the comment:
Theoretically int may be 16 bits (C99):
5.2.4.2.1 Sizes of integer types
-- maximum value for an object of type int
INT_MAX +32767 // 2**15 − 1
I agree that Python wouldn't compile on such a platform anyway.
--
nosy: +
Stefan Krah added the comment:
Hmm, Mark was faster. ;)
--
___
Python tracker
<http://bugs.python.org/issue5308>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Changing array.array would be a new feature, so it cannot go into 2.7.
The documentation could be improved, see also #14198.
--
assignee: -> docs@python
components: +Documentation -None
nosy: +docs@python, sk
Stefan Krah added the comment:
The FreeBSD 6.4 bot is failing, too. Note that the other functions
in test_returnfuncptrs.py do this in order to get strchr():
dll = CDLL(_ctypes_test.__file__)
get_strchr = dll.get_strchr
get_strchr.restype = CFUNCTYPE(c_char_p, c_char_p, c_char
Changes by Stefan Krah :
--
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> uses of locale-dependent ctype functions
___
Python tracker
<http://bugs.pytho
Stefan Krah added the comment:
I'm not sure if I'll use pyctype.h in libmpdec: It's still going to be an
external project that should be completely identical to the version in the
Python tree.
libmpdec/io.c is specified to be ASCII only (while handling the Turkish 'I'
Stefan Krah added the comment:
Not technically the topic of this issue, but should we just lock
down _Py_Uid_Converter() to ints?
This is still accepted:
os.setuid(Decimal("1000.2"))
--
nosy: +skrah
___
Python tracker
<http://bu
Stefan Krah added the comment:
Serhiy Storchaka wrote:
> > Not technically the topic of this issue, but should we just lock
> > down _Py_Uid_Converter() to ints?
>
> I just copied this code from PyArg_ParseTuple*() for 'l' format.
> > os.setuid(Decimal(&qu
Stefan Krah added the comment:
I agree that this cast should work. Perhaps disallowing zero strides
is enough -- I have to look at this more closely though.
--
___
Python tracker
<http://bugs.python.org/issue19
Stefan Krah added the comment:
The regular build (with threads) on that machine has the same problem.
Closing the issue is fine, but there does not seem to be an easy way
to upgrade Fedora from 16 to 19. Perhaps we can skip the test so that
the buildbot continues to be useful
Stefan Krah added the comment:
Nick Coghlan wrote:
> My F19 system (which works) shows gdb-7.6-34, while the new debugging output
> Antoine added shows 7.3.50.20110722-16.fc16 on F16
>
> Maybe the new gdb version check needs to be looking for 7.4+ rather than 7.3+?
Yes, pro
Stefan Krah added the comment:
Yes, len() should return the number of items. +1 for making reversed()
work.
NumPy does this:
>>> x = numpy.array([1,2,3,4,5,6,7,8])
>>> list(reversed(x))
[8, 7, 6, 5, 4, 3, 2, 1]
>>>
>>> x = numpy.array([[1,2,3], [4,5,6]])
&
Stefan Krah added the comment:
Hmm, I meant: Number of items in the first dimension, thus 4 in
Claudiu's example.
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
> Stefan, what do you think about Claudiu's patch? Should a test be added to
> test_buffer as well?
I think the patch is good. We can add more tests when (if?) multi-dimensional
support is added to memoryview.
In that case we should probably do the sa
Stefan Krah added the comment:
Well, I got tired of the OS gdb with an almost transcendental version
number and installed gdb from gnu.org.
The problem seems to have disappeared.
--
___
Python tracker
<http://bugs.python.org/issue19
New submission from Stefan Krah:
On the Fedora 16 buildbot:
==
ERROR: test_qualname_source (test.test_inspect.TestMain)
--
Traceback (most recent call last
Stefan Krah added the comment:
Ok, I think the main reason for disallowing zeros in view->shape here
was that casts are undefined if also the "shape" argument is given:
x = memoryview(b'')
x.cast('d', shape=[1])
Now, this case *is* already caught at a late
New submission from Stefan Krah:
As discussed on python-dev, importing _decimal at the bottom of
decimal.py is about 9x slower than importing _decimal directly.
--
assignee: skrah
components: Extension Modules
messages: 199553
nosy: skrah
priority: normal
severity: normal
stage: needs
Changes by Stefan Krah :
--
keywords: +patch
Added file: http://bugs.python.org/file32060/issue19232.diff
___
Python tracker
<http://bugs.python.org/issue19
Stefan Krah added the comment:
Right, let's start collecting objections. :)
Mark, Raymond: Would you support the change (__name__ hack and all)?
Maciej: Is this approach a problem for PyPy?
--
nosy: +fijall, mark.dickinson, rhettinger
___
P
Changes by Stefan Krah :
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue19232>
___
___
Python-bugs-list mailing list
Un
Stefan Krah added the comment:
Using the microbenchmark I get (standard version):
./python -m timeit "import sys; modname='operator'" "__import__(modname); del
sys.modules[modname]"
1000 loops, best of 3: 460 usec per loop
Victor's version:
./python -m ti
2101 - 2200 of 3396 matches
Mail list logo
