New submission from Stefan Krah :
The arraymodule depends on "structmember.h". Patch attached.
--
components: Build
files: arraymodule_deps.diff
keywords: patch
messages: 154556
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title: a
Stefan Krah added the comment:
There is a comment in setup.py that suggests that *all* Python headers
should be added to the dependencies (?):
# Python header files
headers = [sysconfig.get_config_h_filename()]
headers += glob(os.path.join(sysconfig.get_path('platinclude
Stefan Krah added the comment:
In Python2.6 all headers from Include/ were added:
# Python header files
headers = glob("Include/*.h") + ["pyconfig.h"]
--
___
Python tracker
<http://bug
Stefan Krah added the comment:
Dependency support added: 1be93dd179df
Last good version (all Include/*.h): 9705ef3fdb22
Current behavior (only pyconfig.h): fa69e891edf4
To answer your question: Neither of the last two revisions builds
in an out-of-source directory.
Raising the priority to
Stefan Krah added the comment:
Here's a patch.
--
keywords: +patch
Added file: http://bugs.python.org/file24676/issue14152.diff
___
Python tracker
<http://bugs.python.org/is
Changes by Stefan Krah :
Removed file: http://bugs.python.org/file24673/arraymodule_deps.diff
___
Python tracker
<http://bugs.python.org/issue14152>
___
___
Python-bug
Changes by Stefan Krah :
--
stage: -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issue14152>
___
_
Stefan Krah added the comment:
I'm busy adding the C-API changes to the docs. Regarding the stable ABI:
The general mood was to *keep* the removal of the buffer interface
for some time, did I get that right?
In that case this removal (especially of the Py_buffer struct) should
be docum
Stefan Krah added the comment:
??ric Araujo wrote:
> > To answer your question: Neither of the last two revisions builds
> > in an out-of-source directory.
> My question was more whether the last known good revision did :)
That's what I meant. "last two revisions"
Stefan Krah added the comment:
> From the PEP: "The buffer interface (type Py_buffer, type slots bf_getbuffer
> and bf_releasebuffer, etc) has been omitted from the ABI, since the stability
> of the Py_buffer structure is not clear at this time. Inclusion in the ABI
> can
Stefan Krah added the comment:
I'm trying to understand what you want to be able to write. Do you
perhaps have a short example? Also, to get the bigger picture: Is
this related to your strview proposal?
http://mail.python.org/pipermail/python-ideas/2011-December/012993
Stefan Krah added the comment:
Since this issue targeted 2.7 and 3.2:
In a brief discussion on python-dev it was decided that the 3.3 fixes
from #10181 won't be backported for a number of reasons, see:
http://mail.python.org/pipermail/python-dev/2012-February/116872
Stefan Krah added the comment:
Since this issue targeted 2.7 and 3.2:
In a brief discussion on python-dev it was decided that the 3.3 fixes
from #10181 won't be backported for a number of reasons, see:
http://mail.python.org/pipermail/python-dev/2012-February/116872
New submission from Stefan Behnel :
Line 428 in Python/marshal.c calls pb->bf_releasebuffer() without dec-refing
the view.obj field afterwards. I don't think this is really so truly
performance critical that it can't accept the couple of nanoseconds that it
takes
Stefan Behnel added the comment:
Thanks Eli.
What about the "Lightweight DOM implementation", though? Following Martin's
comment that performance characteristics (like "fast", "memory friendly" or
"lightweight") should normally not be documente
Stefan Behnel added the comment:
Yes, I think that's better.
--
___
Python tracker
<http://bugs.python.org/issue11379>
___
___
Python-bugs-list mailing list
New submission from Stefan Behnel :
These are tests from lxml's ET compatibility test suite that now fail in
ElementTree:
def test_delslice_step(self):
Element = self.etree.Element
SubElement = self.etree.SubElement
a = Element('a')
b = S
New submission from Stefan Krah :
Supporting chained objects that redirect getbuffer requests to a single
exporter rather than re-exporting the buffer is a matter of removing an
assert, but it needs tests and documentation updates.
--
assignee: skrah
messages: 154826
nosy: ncoghlan
Stefan Krah added the comment:
> # generated on buildbot.rubenkerkhof.com, which had, according to Ruben
> # Fedora's package "openssl-1.0.1-0.1.beta2.fc17.x86_64"
I think openssl needs to be compiled with -DPURIFY to avoid this.
--
Stefan Behnel added the comment:
FWIW, Cython lets user code implement the buffer interface for extension types
using the special methods "__getbuffer__()" and "__releasebuffer__()", so
providing the same methods (although with a different signature) also for
normal Pyt
Stefan Krah added the comment:
I didn't ask for review since in the production code only the assert()
line is removed. There are a couple of new tests and I have a private
version of test_buffer that runs most tests with an ndarray chain
using either redirection or re-exporting. As exp
New submission from Stefan Krah :
Nick's comment from #10181:
"It occurs to me that one thing that *could* be backported to early versions
are some of the documentation improvements on how to correctly handle the
lifecycle of fields in Py_buffer. That gets messy though because
Changes by Stefan Behnel :
Added file: http://bugs.python.org/file24734/pyerr_getexcinfo.patch
___
Python tracker
<http://bugs.python.org/issue14098>
___
___
Python-bug
Stefan Krah added the comment:
I'm abusing the issue to settle all concerns that came up on python-dev:
The tests added in the latest commit show that it's indeed no
problem if an atypical static exporter sets view.obj to NULL.
--
Stefan Behnel added the comment:
Then I'm abusing this ticket to say: thanks for verifying this.
--
___
Python tracker
<http://bugs.python.org/is
New submission from Stefan Krah :
bytearray_getbuffer() checks for view==NULL. But this has never been
allowed:
PEP: "The second argument is the address to a bufferinfo structure.
Both arguments must never be NULL."
DOCS (3.2): "view must point to an existing Py_b
Stefan Krah added the comment:
array_buffer_getbuf does a similar thing:
if (view==NULL) goto finish;
finish:
self->ob_exports++; // ???
return 0
Where does this view==NULL thing come from?
--
___
Python tracker
&l
Changes by Stefan Krah :
--
dependencies: +bytearray_getbuffer: unnecessary code
___
Python tracker
<http://bugs.python.org/issue13860>
___
___
Python-bugs-list m
Stefan Krah added the comment:
I seems to be a feature to get a "lock" on an exporter
without the exporter filling in a buffer. It was there
from the beginning:
http://svn.python.org/view/python/branches/release30-maint/Objects/bytearrayobject.c?r1=56849&r2=57181
Last use tha
Stefan Krah added the comment:
> Then I'm abusing this ticket to say: thanks for verifying this.
I would still like to sweep this fact under the rug. :)
Could you have a look at the documentation patch and see if it's clearer?
--
keywords: +patch
Added file: http://bu
Stefan Behnel added the comment:
Yes, I think this is much clearer.
--
___
Python tracker
<http://bugs.python.org/issue14181>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
OK, for me the view->obj issues are done. The new tests indicate
that we can silently keep backwards compatibility for view->obj==NULL,
but I suppressed that fact in the documentation because it's already
complicated enough.
Perhaps we might want to de
Changes by Stefan Krah :
--
dependencies: -bytearray_getbuffer: unnecessary code
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> adapt sphinx-quickstart for windows
___
Python tr
Changes by Stefan Krah :
--
superseder: adapt sphinx-quickstart for windows -> bytearray_getbuffer:
unnecessary code
___
Python tracker
<http://bugs.python.org/issu
Stefan Krah added the comment:
Jim, thanks for taking a look at this.
Jim Jewett wrote:
> (1) I think this module would benefit greatly from a map explaining
> what each file does, and perhaps from some reorganization.
Just MAP.txt in the top level directory? Amaury suggested
Stefan Krah added the comment:
STINNER Victor wrote:
> How can I help to integrate this module into CPython?
It would be fantastic if you could take a look at _decimal.c, for example
to find some incompatibilities between _decimal.c and decimal.py.
mpdecimal.c could also always profit f
Stefan Krah added the comment:
Jim Jewett wrote:
> Whether you need *additional* subdirectories within _cdecimal to
> subcategorize the .c and .h files, I'm not sure -- because I didn't
> get in deep enough to know what they should be. If the categorization
> let pe
New submission from Stefan Behnel :
Based on the existing "test_attempted_yield_from_loop" in
Lib/test/test_pep380.py, I wrote this test and I wonder why it does not work:
"""
def test_attempted_reentry():
"""
>>> for line in test_
Stefan Krah added the comment:
Benjamin Peterson wrote:
> The scripts for generating code would preferably go in a Tools/decimal
> directory.
Hmm, do you mean the gen*.py scripts? The output is generated by decimal.py
and used for testing libmpdec. While the syntax resembles that
Stefan Behnel added the comment:
Oh, right, I missed that part. I also think that a visible note is better. And
+1 for "W3C DOM interface".
--
___
Python tracker
<http://bugs.python.o
Stefan Krah added the comment:
Benjamin Peterson wrote:
> Speaking of inline, the "inline" keyword will have to go because it's not C89.
Do you happen to know a free compiler that builds Python but does not
understand "inline"? I'm asking because without tes
Stefan Krah added the comment:
Case Van Horsen wrote:
> cdecimal 2.3 does not support the __ceil__ and __floor__
Thanks. I'll look into that.
> cdecimal.Decimal instances do not emulate the various single-underscore
> methods of a decimal.Decimal instance. In gmpy2, I use _in
Stefan Krah added the comment:
Antoine Pitrou wrote:
> You could use Py_LOCAL_INLINE, but most compilers should inline small
> functions automatically, AFAIK.
At the time I wrote it I benchmarked everything. I'm pretty sure
that gcc did not inline larger functions like mpd_qresize
Stefan Krah added the comment:
Jim Jewett wrote:
> implementation details. Are there are clear distinctions (type
> info/python bindings/basic arithmetic/advanced
> algorithms/internal-use-only/???)
I failed to mention that libmpdec also has complete documentation. Perhaps
that c
Stefan Krah added the comment:
Marc-Andre Lemburg wrote:
> Does the C version have a C API importable as capsule ?
Not yet. I'll try to make a list with proposed function names and post it here.
> If not, could you add one and a decimal.h to go with it ?
Stefan Krah added the comment:
This issue was raised by Jim on Rietveld:
Currently, the order of arguments in Context.__init__() differs
from repr(Context):
>>> Context()
Context(prec=28, rounding=ROUND_HALF_EVEN, Emin=-9, Emax=9,
capitals=1, flags=[], traps=[Divis
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue14212>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
Here is an analysis of this (less verbose) code:
def g1():
yield "y1"
yield from g2()
yield "y4"
def g2():
yield "y2"
try:
yield from gi
except ValueError:
Stefan Krah added the comment:
Jim Jewett wrote:
> > OK, as a basis for discussion I've added:
> > http://hg.python.org/features/cdecimal/file/8b75c2825508/Modules/_decimal/FILEMAP.txt
>
> Starting from that URL, I don't actually find setup.py.
It's the s
Stefan Behnel added the comment:
Ah, yes, that should work in both implementations. I'll give it a try. Thanks!
--
resolution: fixed ->
status: closed -> open
___
Python tracker
<http://bugs.python.
Changes by Stefan Krah :
Added file: http://bugs.python.org/file24776/9b3b1f5c4072.diff
___
Python tracker
<http://bugs.python.org/issue7652>
___
___
Python-bugs-list m
Stefan Krah added the comment:
Here's a new patch that addresses several remarks:
o _decimal now has __floor__ and __ceil__methods.
o libmpdec is now in a separate directory.
o I removed the big libmpdec test suite. This is why:
- It reduces the number of files that has
Stefan Krah added the comment:
Here's a new patch that addresses several remarks:
o _decimal now has __floor__ and __ceil__methods.
o libmpdec is now in a separate directory.
o I removed the big libmpdec test suite. This is why:
- It reduces the number of files that has
New submission from Stefan Krah :
There are a couple of aliasing warnings in non-debug mode. For example:
http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/1741
Objects/object.c:293: warning: ignoring return value of 'fwrite', declared with
Stefan Krah added the comment:
Benjamin Peterson wrote:
> Speaking of inline, the "inline" keyword will have to go because it's not C89.
Actually the trickier instances of "inline" in the .c files are already
suppressed when LEGACY_COMPILER (i.e. C89) is defined.
Stefan Krah added the comment:
Benjamin Peterson wrote:
> gcc 4.5 doesn't warn for me. Is this a compiler bug in 4.4 or 4.5?
> That is, are these actual aliasing violations?
I see this with 4.4 but also with 4.6 when using -Wstrict-aliasing=2.
However, nothing bad happens when I c
New submission from Stefan Krah :
The Windows build seems to be broken:
Python-ast.c
..\Python\Python-ast.c(459) : error C2059: syntax error
Stefan Behnel added the comment:
FWIW, lxml also has support for parsing Unicode strings. It doesn't encode the
input, however, but parses straight from the underlying buffer (after detecting
the buffer layout etc. at module init time - and yes, I still haven't fixed
this up
Stefan Krah added the comment:
Looks fixed in 6bee4eea1efa.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Stefan Krah :
Linking fails on Windows 64-bit. Perhaps Py_LIMITED_API ifdefs
are missing.
Creating library C:\Users\stefan\hg\cpython\PCbuild\\amd64\\xxlimited.lib
and object C:\Users\stefan\hg\c
python\PCbuild\\amd64\\xxlimited.exp
Stefan Krah added the comment:
I've looked at the latest patch: It seems that new_387controlword is
not set if old_387controlword already has the desired precision and
rounding mode.
Attached is a revised patch that uses the same logic as the Linux
version. A couple of remarks:
- It
Stefan Krah added the comment:
Mark Dickinson wrote:
> http://msdn.microsoft.com/en-us/library/e9b52ceh(v=vs.100).aspx
> Question 1: when doing __control87_2(new, mask, &old, NULL), does the
> resulting value in old reflect the *new* FPU state or the old one?
The new one, but
Stefan Krah added the comment:
Stefan Krah wrote:
>
> Stefan Krah added the comment:
>
> Mark Dickinson wrote:
> > http://msdn.microsoft.com/en-us/library/e9b52ceh(v=vs.100).aspx
> > Question 1: when doing __control87_2(new, mask, &old, NULL), does the
> &
Stefan Krah added the comment:
Mark Dickinson wrote:
> > FWIW, I think we would be better off if this patch were merged in soon.
>
> +1
OK, I'm counting three +1 for merging soon. Thanks everyone for the
encouragement!
I'll then proceed with the merge this weekend or s
Stefan Krah added the comment:
Arfrever Frehtes Taifersar Arahesis wrote:
> Please add --with-system-libmpdec (or --with-system-mpdecimal) option in
> `configure`, similarly to --with-system-expat and --with-system-ffi options.
I've added that to the list of issues. However, if t
Stefan Krah added the comment:
Antoine Pitrou wrote:
> Well, if it doesn't crash, it's probably ok ;)
> Perhaps check modstate->atexit_callbacks for non-NULL?
> Or do we trust free() to do the right thing?
I was initially surprised by this, but the docs state
New submission from Stefan Krah :
Hi -- I'm getting a segfault running the attached crasher.py script.
Valgrind traces it down to an Invalid free() / delete / delete[] in
_PyUnicode_Ready().
Reproduce:
==
Rev: 870c0ef7e8a2
Build: ./configure --without-pymalloc CFLAGS="-O0 -
Stefan Krah added the comment:
3.2 also crashes. 2.7 runs fine. So it's certainly not related
to the new Unicode API.
--
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
I've traced it down to this line:
>>> getattr(type, '__getattribute__')(type, type)
Segmentation fault
Setting to 'normal', since there are apparently more of these.
--
priority: high -> normal
title: Invali
Stefan Krah added the comment:
I'm getting a leak since this revision:
./configure --without-pymalloc CFLAGS="-O0 -g" && make
valgrind --db-attach=yes --suppressions=./Misc/valgrind-python.supp
--leak-check=full ./python leak.py
==32303== 16 bytes in 1 blocks are
Stefan Krah added the comment:
Here's leak.py.
--
Added file: http://bugs.python.org/file24890/leak.py
___
Python tracker
<http://bugs.python.org/is
New submission from Stefan Krah :
I don't see immediately why, but since 3877bf2e323 test_builtin and
a couple of other tests leak in refcounting mode:
hg up 8a5742b7a14d
make distclean && ./configure --with-pydebug && make
./python -m test -uall -R :: test_built
Stefan Krah added the comment:
Ah, thanks for the pointer. 9e7f6ddc0d76 is clean, but default still
leaks. Next attempt:
OK: d2460ff173ff
Leak: 3b2856d8614b
test_dict leaked [12, 12] references, sum=24
test_builtin leaked [24, 24] references, sum=48
test_unittest leaked [970, 970
Stefan Krah added the comment:
Nice. 0554183066b5 is completely clean except for a leak in
test_curses. I think that one may be due to the fact that I'm
running the tests in an ssh terminal.
--
resolution: -> fixed
stage: -> committed/rejected
status: ope
Stefan Krah added the comment:
This is a duplicate of #14296. See also #14359.
--
nosy: +skrah
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> Compilation error on CentOS 5.8
type: ->
Stefan Krah added the comment:
I can reproduce this with Python 3.2 on Linux-2.4.32/i686 with 512M of
RAM. The machine does not crash, it freezes completely in the same
manner as with a fork bomb. A hard reboot is required.
--
nosy: +skrah
type: performance -> resource us
Stefan Krah added the comment:
Kristj??n Valur J??nsson wrote:
> Stefan, I just want to point out this issue, if you are touching 2.7:
> http://bugs.python.org/issue10538
> Do you think it merits being fixed?
I think so. A patch would be appreciated, since the issue touches the
o
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue10538>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
It isn't fixed. Also, there's now an additional invalid read in
sys_update_path():
$ valgrind --db-attach=yes --suppressions=Misc/valgrind-python.supp ./python
==20258== Memcheck, a memory error detector
==20258== Copyright (C) 2002-2010, and GNU
Stefan Krah added the comment:
We need to decide what to do with the different limits of the 64-bit and
32-bit versions:
MAX_EMAX
default context 10**9-1
64-bit 10**18-1
32-bit42500
I think it would be annoying to have the
Stefan Behnel added the comment:
Ok, just for the record: a single __buffer__() special method with
delegation-only semantics would also work for Cython. Taking this path would
provide a cleaner separation of the (then delegation-only) Python level
protocol and the (all purpose) C level
Stefan Krah added the comment:
> The best thing might be to use Emax=10**8-1 and Emin=-(10**8-1) throughout.
> I don't think many applications depend on having Emax=10**9-1. If they do,
> they'll have to use the 64-bit version.
10**6-1 would be another option. The adv
Stefan Krah added the comment:
Hmm, I still get the error in 13cefcbcc7da:
c:\Users\stefan\pydev\cpython\Include\accu.h(21) : error C2059: syntax error :
'type'
c:\Users\stefan\pydev\cpython\Include\accu.h(22) : error C2059: syntax error :
'}'
Stefan Krah added the comment:
Jeff's #undef suggestion works here (see patch). But I have a question:
Where is Windows.h pulled in anyway? A grep only shows signalmodule.c:
$ find . -name "\.hg" -prune -o -type f -print0 | xargs -0 grep -n 'Windows\.h'
./Modules/
Stefan Krah added the comment:
Jeff Robbins wrote:
> I am sorry if I've caused any confusion. I am building a Python extension
> (APSW), and it includes the sqlite "amalgamation" and also includes Python.h.
The Python build itself failed here, too, specifically in unicod
Stefan Krah added the comment:
To prevent further confusion. :)
db154e62ac03 -> OK
5fe7d19ec49a -> failure
5fe7d19ec49a with #undef patch -> OK
So I don't know if it is better to revert to db154e62ac03 or
to use the #undef patch.
Jeff, you originally said:
'An exten
Stefan Krah added the comment:
> But there's no link on the benchmark code.
I don't know if external links are appropriate in whatsnew, but this
is it:
http://www.bytereef.org/mpdecimal/quickstart.html
--
nosy: +skrah
___
Python t
Stefan Krah added the comment:
It's the line argv0 = argv[0] in sys_update_path(). The copies of
argv made in python.c aren't NULL terminated. Kristján's patch
worked around that (and fixes the problem), but I'd prefer to
make a full copy of argv in python.c.
Could one of y
Stefan Krah added the comment:
> 3) line 1812 assumes n to be equal to the length of arg0, but depending >
> on conditional compilation, it may not get set at all, and in any>
> case in line line 1805 it gets set only if p is not NULL.
n is initialized to 0 when
Stefan Krah added the comment:
I only have the C99 standard. It says [5.1.2.2.1]:
- argv[argc] shall be a NULL pointer.
Is this different in C89?
Also, my patch terminates the *copies* of argv, not argv itself.
--
___
Python tracker
<h
Stefan Krah added the comment:
K&R page 115 also says: The standard requires that argv[argc] be a NULL pointer.
So it must be in C89 as well.
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
Actually _iomodule.c already has a freefunc with the same signature.
atexit_free() is properly called in:
static void
module_dealloc(PyModuleObject *m)
{
PyObject_GC_UnTrack(m);
if (m->md_def && m->md_def->m_free)
m->md_def-&
Stefan Krah added the comment:
I wonder about the name: There is already a collections.abc.MappingView.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue14
Changes by Stefan Krah :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: -Python 3.2
___
Python tracker
<http://bugs.python.or
Stefan Krah added the comment:
I have a couple of questions about the proposed capsule C API. In order to
be useful, it should be possible to set temporary contexts and pass them
to functions. For example, PyDec_Add could look like:
PyDec_Add(PyObject *a, PyObject *b, PyObject *context
Stefan Krah added the comment:
By adding a slow __eq__() method to Nick's script I can trigger the
RuntimeError reliably.
--
nosy: +skrah
Added file: http://bugs.python.org/file25086/hammer_dict_eq.py
___
Python tracker
<http://bugs.py
Stefan Krah added the comment:
Leaving this open since a "New in version 3.3" speed improvement note
in the docs would be useful.
--
title: missing links on performance claims of cdecimal -> Add speed improvement
note to the
Stefan Krah added the comment:
> Should I contact the extension's author(s)/maintainer(s) and tell them about
> this ordering requirement?
FWIW, it is the recommended way in the docs.
The Python build itself has been fixed. Does the http://code.google.com/p/apsw/
modul
Stefan Krah added the comment:
OK, here's a version with a low switch interval. Of course it's also
contrived, but it works.
Generally I'd appreciate the RuntimeError, since it's a hint that
something needs to be rewritten in an application.
It might be a problem if t
Stefan Behnel added the comment:
This is now implemented in PyPy:
https://bitbucket.org/pypy/pypy/changeset/623bcea85df3
Are there any objections to applying the equivalent patch to CPython?
--
___
Python tracker
<http://bugs.python.
1401 - 1500 of 4949 matches
Mail list logo