Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue23349>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Ok thanks, I understand the issue now. I'm focusing this issue
on the termcap detection. For the other parts of the patch
you'd have to open separate issues.
As an aside, the ncurses maintainer seems to endorse a distro
enforced choice for libreadline
Stefan Krah added the comment:
FWIW, even
http://www.linuxfromscratch.org/lfs/view/stable/chapter06/readline.html
enforces -ncurses linking of readline.
[They should be compiling ncurses with tinfo split out though and
use -tinfo instead
Stefan Krah added the comment:
Looks good, here's a patch with tests.
--
Added file: http://bugs.python.org/file37927/issue23349-2.diff
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
I think all 2.7 bots are broken. :)
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue11578>
___
___
Python-bug
Stefan Krah added the comment:
I think in 2.7 there's a slight problem since e6b9e277fbf4:
[1/1] test_unicode
Debug memory block at address p=0x7f4ebba3fae0: API 'o'
100 bytes originally requested
The 7 pad bytes at p-7 are FORBIDDENBYTE, as expected.
The 8 pa
Stefan Krah added the comment:
I think I still get a problem in 2.7:
[1/1] test_unicode
==23430== Invalid read of size 1
==23430==at 0x484541: PyUnicodeUCS2_FromFormatV (unicodeobject.c:736)
==23430==by 0x485C75: PyUnicodeUCS2_FromFormat (unicodeobject.c:1083)
736 for (f
Stefan Krah added the comment:
issue23055_2.patch looks good.
--
___
Python tracker
<http://bugs.python.org/issue23055>
___
___
Python-bugs-list mailing list
Unsub
Stefan Krah added the comment:
Cython doesn't follow the spec though (use Python 3):
from _testbuffer import *
cpdef foo():
cdef unsigned char[:] v = bytearray(b"testing")
nd = ndarray(v, getbuf=PyBUF_ND)
print(nd.suboffsets)
nd = ndarray(v, getbuf=PyBUF_
Stefan Krah added the comment:
Should be fixed, thanks for the patch.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Stefan Krah added the comment:
To summarize, I think this is different from #22445, which also requests
relaxed contiguity tests. #22445 is motivated by the fact that slicing
can create a certain class of contiguous buffers that aren't recognized
as such.
No such reason exists here
Stefan Krah added the comment:
Sorry, #23349.
--
___
Python tracker
<http://bugs.python.org/issue12834>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Fixed for 2.7 in #22668.
--
___
Python tracker
<http://bugs.python.org/issue12834>
___
___
Python-bugs-list mailing list
Unsub
Stefan Krah added the comment:
Prepare for a partial reversal of opinion. :)
Indexing *can* actually create all-negative suboffsets in a natural way:
>>> from _testbuffer import *
>>> nd = ndarray([1,2,3,4,5,6,7,8,9,10,11,12], shape=[3,4], flags=ND_PIL)
>>> nd.to
Stefan Krah added the comment:
> Richard Hansen added the comment:
> > Cython doesn't follow the spec though (use Python 3):
> >
> > from _testbuffer import *
> > cpdef foo():
> > cdef unsigned char[:] v = bytearray(b"testing&qu
Stefan Krah added the comment:
> How might an application break with this change?
func1:
if (!PyBuffer_IsContiguous(view, 'C'))
error();
func2(view);
func2:
assert(view->suboffsets == NULL);
...
Yes, I *did* insert sanity checks like thi
Stefan Krah added the comment:
But only Cython does not set suboffsets to NULL and you already have a small
patch to fix that.
The Python 3 docs say "suboffsets only if needed" and the PEP says the same,
so the situation is not completely undocumented.
I think your doc patch go
Changes by Stefan Krah :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Stefan Krah:
Same as #23349.
--
messages: 235178
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: PyBuffer_FromContiguous() off-by-one error for non-contiguous buffers
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Changes by Stefan Krah :
--
keywords: +patch
Added file: http://bugs.python.org/file37969/issue23370.diff
___
Python tracker
<http://bugs.python.org/issue23
Changes by Stefan Krah :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue23370>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Stefan Krah :
--
resolution: -> fixed
stage: needs patch -> resolved
___
Python tracker
<http://bugs.python.org/issue23370>
___
___
Python-bugs-
Stefan Krah added the comment:
[Slow internet connection, can't use Rietveld.]
CDataType_from_buffer():
I'm not that familiar with ctypes. What is the high level goal here?
Allocate a chunk of memory, wrap it in a memoryview and have the
memoryview release that memory when its ref
Changes by Stefan Krah :
--
nosy: skrah
priority: normal
severity: normal
status: open
title: getargs.c: redundant C-contiguity check
type: performance
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue23
New submission from Stefan Krah:
The call to PyBuffer_IsContiguous() (see patch) is redundant:
PyBUF_WRITABLE is a flag that can be added to any buffer request.
The real request here is (PyBUF_SIMPLE|PyBUF_WRITABLE), which is
equal to PyBUF_WRITABLE since PyBUF_SIMPLE==0.
PyBUF_SIMPLE implies
Stefan Krah added the comment:
Yes, _testbuffer.ndarray can create any buffer.
--
___
Python tracker
<http://bugs.python.org/issue23376>
___
___
Python-bugs-list m
Stefan Krah added the comment:
A unit test would not be so helpful. The potential problem is that
third party extensions with broken getbufferprocs would suffer.
But at some point we have to streamline PEP-3118 code, or it
will remain inscrutable forever. Extension writers often copy
code
Stefan Krah added the comment:
Thanks. No, I don't think there's an official way to accomplish that,
but let's create one. How about a new function that takes the buffer
request flags:
PyMemoryView_FromObjectEx(exporter, PyBUF_SIMPLE|PyBUF_WRITABLE)
If we can spare a
Changes by Stefan Krah :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue23352>
___
Stefan Krah added the comment:
Nice patch. I've found one issue (see Rietveld). I'm not sure
about 3.4 (the patch contains minor refactorings), but otherwise
I'd say go ahead with it.
--
___
Python tracker
<http://bugs.pyt
Stefan Krah added the comment:
STINNER Victor wrote:
> I don't understand the link between third party extensions and
> test_getargs2. test_getargs2 is a unit test for non-regression of
> CPython. Can you please elaborate?
A test failure needs a broken buffer provider that h
Stefan Krah added the comment:
Well, here's a patch with tests.
Victor, I think you added the contiguity test in 9d49b744078c. Do you
remember why?
--
Added file: http://bugs.python.org/file37987/issue23376-2.diff
___
Python tracker
Stefan Krah added the comment:
Ah yes, it seems to originate from #3139.
--
___
Python tracker
<http://bugs.python.org/issue23376>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
New patch with tests.
--
Added file: http://bugs.python.org/file38003/issue14203-2.diff
___
Python tracker
<http://bugs.python.org/issue14
Stefan Krah added the comment:
bytesiobuf_getbuffer() also still has this obsolete feature, so
BufferError should be raised if view==NULL.
I'm unsure if this plays well with the new SHARED_BUF(b) thing.
Should the exception be raised before or after?
--
nosy: +serhiy.storchaka
Stefan Krah added the comment:
Ok, thanks! issue14203-3.diff should be correct, then.
--
Added file: http://bugs.python.org/file38004/issue14203-3.diff
___
Python tracker
<http://bugs.python.org/issue14
Stefan Krah added the comment:
Argh, the extern _PyBytesIOBuffer_Type hack. I knew it would cause some
trouble.
Any ideas how to test bytesiobuf_getbuffer() with a NULL view in
a more dignified way?
--
___
Python tracker
<http://bugs.python.
Changes by Stefan Krah :
--
nosy: skrah
priority: normal
severity: normal
status: open
title: make profile-opt: test_distutils failure
type: behavior
___
Python tracker
<http://bugs.python.org/issue23
New submission from Stefan Krah:
Currently -fprofile-use etc. appear in the distutils CFLAGS, which
causes test_distutils to fail.
--
keywords: +patch
nosy: +gregory.p.smith
Added file: http://bugs.python.org/file38009/issue23390.diff
___
Python
Stefan Krah added the comment:
I think it's sufficient to test bytesiobuf_getbuffer() on
Linux and FreeBSD. The test just checks that the exception
is raised.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
Stefan Krah added the comment:
In _testbuffer.c: ndim <= 64, so the changes aren't really necessary.
Somehow this fact needs to get widely known, since it does not make
sense to check for overflow anytime ndim is used.
The reason is of course that even an array with only 2 elem
Stefan Krah added the comment:
Yes, but these (degenerate) arrays tend to arise only as a result of slicing.
Last time I looked NumPy had MAX_NDIM=32, so we should be fine.
--
___
Python tracker
<http://bugs.python.org/issue23
Stefan Krah added the comment:
For Decimal the cutoff point is -6 instead of -4 (following the
decimal specification instead of the C standard).
--
assignee: -> docs@python
components: +Documentation -Library (Lib)
nosy: +docs@python, skrah
type: behav
Stefan Behnel added the comment:
Serhiy, I suggest you look at the code that Cython generates for its functions.
It has been extensively profiled and optimised (years ago), so generating the
same code for the argument clinic should yield the same performance.
And while I don't have
Stefan Behnel added the comment:
FTR, lxml's Element class has addnext() and addprevious() methods which are
commonly used for this purpose. But ET can't adopt those due to its different
tree model.
I second Martin's comment that ET.append() is a misleading name. It suggests
Stefan Krah added the comment:
> Prohibiting tabs after spaces is not enough.
No, I really meant that once a new block is started with tabs,
all following nested blocks must use tabs for indentation.
The only place where spaces would be allowed is for aligment
in logical lines that extend o
Stefan Behnel added the comment:
I added a couple of review comments to patch 6, but since no-one has responded
so far, I guess they simply haven't been noticed. So I'll just repeat them here.
1)
getawaitablefunc / aiternextfunc / getaiterfunc
Is there a reason why these need to
Changes by Stefan Behnel :
--
nosy: +scoder
___
Python tracker
<http://bugs.python.org/issue23275>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
Another question: is it ok if Cython implements and uses the "tp_as_async" slot
in all Py3.x versions (3.2+)? It shouldn't hurt, but it would speed up
async/await in Cython at least under Py3.x. Only Py2.6/7 would then have to
resort to cal
Stefan Behnel added the comment:
> It *is* correct, see PEP 492. Awaitable is either a coroutine *or* an object
> with an __await__ method.
"coroutine", yes. But "Coroutine"? Shouldn't the Coroutine ABC then require
"__await__" to be implemented
Stefan Behnel added the comment:
> Can't your Coroutine object return itself from its __await__, and implement
> __next__? Like genobject in CPython simply returns self from its __iter__.
That was my first try, sure, and it mostly worked. It has a drawback,
though: it'
Stefan Behnel added the comment:
BTW, given that "iter(iterator)" works and returns the iterator, should we also
allow "await x.__await__()" to work? I guess that would be tricky to achieve
given that __await__() is only required to return any kind of arbitrary
Iterator,
Stefan Behnel added the comment:
>> Yield-from iterates, and a coroutine is not supposed to be iterable, only
>> awaitable (at least, that's what all error messages tell me when I try it).
>> So why should "yield from" work on them? What if foo() was not an Ite
Stefan Krah added the comment:
I think users may be surprised that any two large Decimals like
"1e40" and "1e999" are "close". In the Decimal world these
aren't infinite.
--
nosy: +skrah
___
Python tracker
Stefan Behnel added the comment:
> Properly handling other types which are convertible to floats, such as
> Decimal and Fraction, is outside the scope of this issue.
... and outside of the scope of the math module in general. It's inherently
floating
Stefan Krah added the comment:
> It's inherently floating point based.
Except for floor() and ceil() though. The wording in the PEP
under "non-float" types made me think that something similar
was intended here.
Personally I'm fine wit
Stefan Krah added the comment:
Also, I must say that returning inf in sqrt() bothers me much less
than the assertion that two numbers with a gigantic relative error
have a relerr of 1e-9.
--
___
Python tracker
<http://bugs.python.org/issue24
Stefan Behnel added the comment:
Thanks Yury, I'll give it a try ASAP.
--
___
Python tracker
<http://bugs.python.org/issue24017>
___
___
Python-bugs-list m
Stefan Krah added the comment:
> While we're on the subject, though, trying to convert a very large int to
> float fails with an OverflowError. Perhaps Decimal should do the same?
I've always viewed float() as a cast. For casting Decimal's behavior
seems to be the right
Stefan Behnel added the comment:
I'm seeing crashes with this assertion in Cython test modules:
python: ./Python/importdl.c:75: get_encoded_name: Assertion
`(((PyObject*)(encoded))->ob_refcnt) == 1' failed.
The problem seems to be that the module name is only one character lon
Stefan Behnel added the comment:
Patch LGTM and it fixes the problem (tried it on my side). Please make sure it
gets applied in time for beta 2.
--
___
Python tracker
<http://bugs.python.org/issue24
Stefan Behnel added the comment:
Tried it, works for me. Thanks!
--
___
Python tracker
<http://bugs.python.org/issue24017>
___
___
Python-bugs-list mailin
Stefan Behnel added the comment:
I just noticed that I hadn't used the real "types.coroutine" in my Py3.5 tests
when reporting back in issue 24017. When I pass a Cython generator through it,
I get
"""
Traceback (most recent call last):
File "tests/run/te
Stefan Behnel added the comment:
One failing test in "test_coroutines": test_func_5. The reason is that the
GeneratorWrapper is not iterable (and there is no reason it shouldn't be, given
that it wraps a Generator). That was my fault, I had already added an __iter__
method but
Stefan Behnel added the comment:
BTW, it's not only for compiled generators but also for normal Python functions
that construct Python generators internally and return them, or that delegate
the generator creation in some way. With this change, it's enough to decorate
the constructo
Stefan Behnel added the comment:
Ok, now the problem with *this* patch is that __iter__ and __await__ are
special methods that are being looked up on the type, not the instance.
Similarly __next__, I think, as it also has its own (type) slot. But I think
you're right that __next__ is
Stefan Behnel added the comment:
Your latest patch works for me.
--
___
Python tracker
<http://bugs.python.org/issue24316>
___
___
Python-bugs-list mailin
Stefan Behnel added the comment:
IMHO less clear and less correct than the previous suggestions.
--
___
Python tracker
<http://bugs.python.org/issue24079>
___
___
Stefan Behnel added the comment:
Seems like a good idea to explain "text" and "tail" in one section, though.
That makes "tail" easier to find for those who are not used to this kind of
split (and that's basically everyone who needs t
Stefan Behnel added the comment:
I would still like to see a patch in Py3.5 that only flips the bit in C when
"_types" is available and otherwise falls back to the existing Python code that
creates a new code object. This part is much cleaner and faster to do in C than
in the curr
Stefan Behnel added the comment:
I found one more place in asyncio.coroutines, around line 190 in the
coroutine() decorator:
if inspect.isgeneratorfunction(func):
coro = func
else:
@functools.wraps(func)
def coro(*args, **kw):
res = func(*args, **kw
Stefan Behnel added the comment:
Cython functions that return a generator aren't special in any way, so it's
actually correct that isgeneratorfunction() always returns False. I mean, I
could set the CO_COROUTINE flag on the code object that we fake, but that
wouldn't help m
Stefan Behnel added the comment:
Hmm, I just noticed that this only started failing when I disabled the asyncio
module patching for 3.5beta1+, assuming that it now all works. A side effect of
that was that also the inspect module is no longer patched into returning True
from isgenerator() for
Stefan Behnel added the comment:
... except that the returned object may not actually be a Cython generator but
a GeneratorWrapper, now that the patch from issue 24316 is in place. :)
Then I guess we're back to the point where duck-typing and calling __await__()
is a good
Stefan Behnel added the comment:
Works for me.
Why is the AwaitableABC type check needed, in addition to looking up the
relevant method? IIUC, the type check will just do a lookup of the same method
if the type hasn't been registered as Awaitable explicitly.
--
status: pe
Stefan Krah added the comment:
Opening again. I have too many questions. :)
--
nosy: +skrah
status: pending -> open
___
Python tracker
<http://bugs.python.org/issu
Changes by Stefan Krah :
Added file: http://bugs.python.org/file39581/crash-1.py
___
Python tracker
<http://bugs.python.org/issue16991>
___
___
Python-bugs-list mailin
Changes by Stefan Krah :
Added file: http://bugs.python.org/file39582/crash-2.py
___
Python tracker
<http://bugs.python.org/issue16991>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
crash-1.py is due to an unchecked return value from _odictnode_VALUE().
We should probably use PyDict_GetItemWithError(), also in other
places.
I normally try to steer clear of stylistic remarks, but the
_odictnode* macros are hiding too many things. As of now
Stefan Krah added the comment:
crash-2.py is due to the fact that _PyDict_Pop() deletes a reference
to 'key' in _odict_popkey().
The INCREF(key) in popitem should take place before calling _odict_popkey().
Again, I don't see the point of INCREF/DECREF *inside* o
New submission from Stefan Krah:
I tried to disprove my own claim of unreachable code in resize()/get_index()
using a convoluted threaded test case.
The code still fails to be reached, but another segfault turned up.
--
components: Extension Modules
files: crash-th.py
messages: 244661
Stefan Krah added the comment:
It's fine to open other issues, but I'm not happy with the resize()/get_index()
situation. Currently I can't come up even with an informal "proof" that it'll
always work (and see #24361).
I think these functions re
Stefan Krah added the comment:
I think this is much nicer, thank you!
And the XXX comment looks right, updating od_size could be moved
down. I suspect that updating it too early was the cause for
#24361, which is also solved by this patch
Stefan Krah added the comment:
This is my experience, too: Floating-point calculations are often
20-30% faster on 2.7.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue24
Stefan Behnel added the comment:
Hmm, but IMHO a) the new syntax isn't just for asyncio and b) awaiting a Future
seems like a *very* reasonable thing to do. I think opening a new ticket for
this is a good idea.
--
___
Python tracker
Stefan Behnel added the comment:
Looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue24079>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
(Copying my review comment here so that it doesn't get lost as it's more of a
general design thing than a specific review comment.)
Having Future know and deal with asyncio seems wrong to me. asyncio should be
able to deal *somehow* with a Future tha
Stefan Behnel added the comment:
I agree that the "extra bit" is a quirk. Ideally, Coroutine and Generator would
share a common base class that has "send", "throw" and "close". Additionally, a
Coroutine would be an Awaitable whereas a Generator is an I
Stefan Behnel added the comment:
Looks good, simplifies the code visibly and makes the implementation quite
similar to the one I wrote for Cython.
I like the fact that it separates generators from coroutines at an isinstance()
level. The fact that "async def" functions currently hav
Stefan Behnel added the comment:
See issue 24400 regarding a split of yield-based generators and async-def
coroutines at a type level.
--
___
Python tracker
<http://bugs.python.org/issue24
Stefan Behnel added the comment:
I added some review comments. The main thing is that the coroutine type should
be awaitable.
For reference, here's my current implementation for Cython. It's a bit more
involved as it needs to support Python 2.6+. I may also add some special c
New submission from Stefan Tatschner:
A list item which describes the changes of #22631 is badly indented. The
attached (trivial) patch fixes that problem.
--
assignee: docs@python
components: Documentation
files: fix-indentation.patch
keywords: patch
messages: 245127
nosy: docs@python
Stefan Behnel added the comment:
> I currently do isinstance(x, types.GeneratorType), which will fail if x
> is actually a GeneratorWrapper. I can change this to use
> collections.abc.Generator when it exists, but then I'd have to have some
> conditional logic to switch betwee
Stefan Behnel added the comment:
Here are two patches that fix this case, one with special casing, one without.
Please choose and apply one.
--
Added file: http://bugs.python.org/file39691/fix_stopiteration_value_slow.patch
___
Python tracker
<h
Changes by Stefan Behnel :
Added file: http://bugs.python.org/file39692/fix_stopiteration_value.patch
___
Python tracker
<http://bugs.python.org/issue23996>
___
___
Pytho
Stefan Behnel added the comment:
I agree that a typedef is a good idea. It doesn't cost anything but gives
us more freedom for future changes.
--
___
Python tracker
<http://bugs.python.org/is
Stefan Behnel added the comment:
No. It's more that it feels wrong to spend actual time on the second most
common case that can occur instead of just handling it in no time at all. The
third case that it's really required to instantiate the StopIteration exception
(if user code di
New submission from Stefan Behnel:
A Cython user noticed a memory leak when C-inheriting from "int".
http://thread.gmane.org/gmane.comp.python.cython.devel/15689
The Cython code to reproduce this is simply this:
cdef class ExtendedInt(int): pass
for j in xrang
Changes by Stefan Behnel :
--
nosy: +scoder
___
Python tracker
<http://bugs.python.org/issue24450>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
No problem for Cython either.
The change in issue 24400 that makes coroutines real Awaitables also removes
surprises for a "cr_await" return value being a coroutine and previously *not*
an Awaitable.
The contract for "gi_yieldfrom" is on
4301 - 4400 of 4955 matches
Mail list logo
