Stefan Behnel added the comment:
I originally planned to make the next Cython release patch the Generator
and Coroutine ABCs into collections.abc, but I now think it would be worth
uploading an abc_backports package to PyPI instead that does that and on
which asyncio, tornado and other
Stefan Behnel added the comment:
I added three more comments to the review. The rest looks good to me, too.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24400
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 xrange(1000
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 only that the returned value
Changes by Stefan Behnel sco...@users.sourceforge.net:
--
nosy: +scoder
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24450
___
___
Python-bugs
Changes by Stefan Behnel sco...@users.sourceforge.net:
--
nosy: +pitrou, serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24469
Stefan Behnel added the comment:
1) The intended solution is to require that int subclasses override tp_free.
In the way I showed? By calling either PyObject_GC_Del() or PyObject_Del()
directly? I'll happily do that (Py2.7 and Py2 int being dead ends makes
that pretty future proof), but it's
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 rep...@bugs.python.org
http://bugs.python.org/issue24400
Sebastian M Cheung via Python-list schrieb am 12.06.2015 um 13:36:
Are these available? Any good ones to recommend?
I recommend not doing that. You'd end up with ugly and unidiomatic Python
code that's impossible to maintain, whereas you now (hopefully) have
somewhat idiomatic Java code that
Changes by Stefan Behnel sco...@users.sourceforge.net:
Added file: http://bugs.python.org/file39692/fix_stopiteration_value.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23996
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 rep
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 between collections.abc
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 rep...@bugs.python.org
http://bugs.python.org/issue24017
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 casing
doc.mefi...@gmail.com schrieb am 07.06.2015 um 10:56:
And I can't use Cython, because I have C++ module, and I have to use it.
That's not a valid reason. Cython supports C++ code just fine.
http://docs.cython.org/src/userguide/wrapping_CPlusPlus.html
Stefan
--
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 that is being
Stefan Behnel added the comment:
Looks good to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24079
___
___
Python-bugs-list mailing list
Steven D'Aprano schrieb am 05.06.2015 um 16:07:
Sorting in reverse does not give the same result as sorting then reversing.
It's easiest to see with a key function:
py a = ['fox', 'dog', 'DOG', 'cat', 'ape']
py b = a[:]
py a.sort(key=str.lower, reverse=True)
py b.sort(key=str.lower)
py
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 much as Cython's
Laura Creighton schrieb am 30.05.2015 um 13:24:
As a point of fact, We've _already got_ Topaz, a Ruby interpreter,
Hippy, a PHP interpreter, a Prolog interpreter, a Smalltalk
interpeter, and a javascript interpreter. Recently we got Pyket a
Racket compiler. There also exist plenty of
garyr schrieb am 30.05.2015 um 18:22:
I'm trying to create an extension module using SWIG. I've
succeeded in generating a pyd file but when I import the module I get the
error message: SystemError: dynamic module not initialized properly. I
added an initfoo() function but that didn't solve the
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
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 idea
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: pending - open
garyr schrieb am 30.05.2015 um 22:48:
*snip*
Compile it (cythonize -b foo.pyx) and you'll get an extension module
that
executes faster than what SWIG would give you and keeps everything in one
file to improve readability.
[1] http://cython.org/
Thanks for your reply. My interest is not
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:
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 current Python
Chris Angelico schrieb am 28.05.2015 um 20:51:
On Fri, May 29, 2015 at 4:41 AM, Stefan Behnel wrote:
davidf...@gmail.com schrieb am 26.05.2015 um 04:24:
Has anyone on this list attempted to sandbox Python programs in a
serious fashion? I'd be interested to hear your approach.
Not quite
Chris Angelico schrieb am 29.05.2015 um 09:41:
On Fri, May 29, 2015 at 4:18 PM, Stefan Behnel wrote:
Lua's a much weaker language than Python is, though. Can it handle
arbitrary-precision integers? Unicode? Dare I even ask,
arbitrary-precision rationals (fractions.Fraction)?
All of those
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 long
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 rep...@bugs.python.org
http://bugs.python.org/issue24268
Stefan Behnel added the comment:
Tried it, works for me. Thanks!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
___
Python-bugs-list
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/test_coroutines_pep492.pyx, line 245
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 didn't copy
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 constructor function
Stefan Behnel added the comment:
IMHO less clear and less correct than the previous suggestions.
--
___
Python tracker rep...@bugs.python.org
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 to read the docs in the first
place
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 also
Stefan Behnel added the comment:
Your latest patch works for me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24316
___
___
Python-bugs-list
davidf...@gmail.com schrieb am 26.05.2015 um 04:24:
Has anyone on this list attempted to sandbox Python programs in a
serious fashion? I'd be interested to hear your approach.
Not quite sandboxing Python, but I've seen people use my Lupa [1] library
for this. They're writing all their code in
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 Iterable
but a Coroutine? Should yield
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, and Iterators cannot
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's an incomplete
Stefan Behnel added the comment:
Thanks Yury, I'll give it a try ASAP.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
___
Python-bugs
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? Maybe even by inheriting from Awaitable?
Just
Changes by Stefan Behnel sco...@users.sourceforge.net:
--
nosy: +scoder
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23275
___
___
Python-bugs
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 have
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 calling __await__() etc
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
adding stuff
Stefan Behnel added the comment:
I noticed that my patch isn't entirely correct. If the exception value is a
tuple, both PyErr_SetObject() and PyErr_NormalizeException() use it directly as
*argument tuple* for the exception instantiation call, i.e. they essentially
unpack it into separate
Changes by Stefan Behnel sco...@users.sourceforge.net:
--
nosy: +scoder
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17239
___
___
Python-bugs
Stefan Behnel added the comment:
Eventually, I think a corresponding function should be added to cmath.
math.isclose() shouldn't deal with complex values by itself (other than
rejecting them as non-floatish input).
--
___
Python tracker rep
Stefan Behnel added the comment:
The cast is correct and required (the actual signature is determined by the
METH_* flags).
Patch LGTM, FWIW.
--
components: +Library (Lib)
nosy: +scoder
type: - enhancement
___
Python tracker rep...@bugs.python.org
Stefan Behnel added the comment:
There are calls to PyObject_RichCompareBool() in the loops, which means that
user code might get executed. What if that's evil code that modifies the heap
list? Couldn't that lead to list resizing and thus invalidation of the list
item pointer
Skip Montanaro schrieb am 22.05.2015 um 19:15:
2015-05-22 12:05 GMT-05:00 Lele Gaifax:
Maybe http://docs.cython.org/src/userguide/wrapping_CPlusPlus.html?
Thanks for the reference, Lele. I was thinking in terms of cffi, but
this might work as well. (Shouldn't cffi interfaces be the
Stefan Behnel added the comment:
Ah, sorry, yes. I somehow misread the arguments being passed *into* richcompare
as subsequent array access. LGTM too. Sorry for the noise.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Steven D'Aprano schrieb am 10.05.2015 um 11:58:
Why is calling a function faster than bypassing the function object and
evaluating the code object itself? And not by a little, but by a lot?
Here I have a file, eval_test.py:
# === cut ===
from timeit import Timer
def func():
a = 2
Stefan Behnel added the comment:
Well, as I've shown in issue 24076 (I'm copying the numbers here), even simple
arithmetic expressions can benefit from a free-list. Basically anything that
uses temporary integer results.
Original:
$ ./python -m timeit 'sum(range(1, 10))'
1000 loops, best
Stefan Behnel added the comment:
Issue 24165 was created to pursue the path of a free-list for PyLong objects.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24076
Stefan Behnel added the comment:
I got similar results on 64bits for my original patch (very similar to what
Serhiy used now). The numbers are not really conclusive.
Report on Linux leppy 3.13.0-46-generic #77-Ubuntu SMP Mon Mar 2 18:23:39 UTC
2015 x86_64 x86_64
Total CPU cores: 4
### 2to3
Stefan Behnel added the comment:
We also need a Coroutine ABC. Both the GeneratorType and CO_COROUTINE
checks are too restrictive. Also see issue 24018, which this one should in fact
depend on.
--
___
Python tracker rep...@bugs.python.org
http
Stefan Behnel added the comment:
This is blocking issue 24017 (async/await syntax).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
Stefan Behnel added the comment:
Thanks! Minor grouch: it should say collections.*abc*.Generator in the NEWS
entry.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
Stefan Behnel added the comment:
I get a test failure in Cython's compatibility tests which seems to be
attributable to this change:
def sideeffect(x):
... L.append(x)
... return x
def unhashable(x):
... L.append(x)
... return [x]
L
Stefan Behnel added the comment:
See issue 24076.
--
nosy: +scoder
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24138
___
___
Python-bugs-list
Stefan Behnel added the comment:
I'm actually not sure how it relates to the minimum. The more runs you have,
the higher the chance of hitting the actual minimum at least once. And if none
of the runs hits the real minimum, you're simply out of luck.
However, it should tend to give a much
Stefan Behnel added the comment:
Well, we can apply a kludge, or apply statistics.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22881
Stefan Behnel added the comment:
for the even number case, I think you shouldn't do // 2, but / 2.
Right. I updated the patch.
--
Added file: http://bugs.python.org/file39279/show_median.patch
___
Python tracker rep...@bugs.python.org
http
Stefan Behnel added the comment:
I tried implementing a freelist. Patch attached, mostly adapted from the one in
dictobject.c, but certainly needs a bit of cleanup.
The results are not bad, about 10-20% faster:
Original:
$ ./python -m timeit 'sum(range(1, 10))'
1000 loops, best of 3
Stefan Behnel added the comment:
I don't think it's irrelevant. Throw-away integers are really not uncommon.
For-loops use them quite often, non-trivial arithmetic expressions can create a
lot of intermediate temporaries. Speeding up the create-delete cycle of PyLong
sounds like a very
Stefan Behnel added the comment:
I don't think it's necessary to have slots for __aiter__, __anext__,
__aenter__ and __aexit__. Async iteration will never be as fast as regular
iteration, and there is plenty overhead in it.
You seem to be assuming that the outer loop is the asyncio I/O
Stefan Behnel added the comment:
I agree that the wording in the documentation isn't great:
text
The text attribute can be used to hold additional data associated with the
element. As the name implies this attribute is usually a string but may be any
application-specific object
Stefan Behnel added the comment:
there are three ingredients here - sum, (x)range and the integer addition
that sum will be performing at each iteration.
... not to forget the interpreter startup time on his machine. :)
I did a tiny bit of profiling and about 90% of the time seems
Stefan Behnel added the comment:
Please either
1) drop the throw() method entirely or
2) make throw an abstractmethod()
Ok, as I already said, I think it's important to provide the complete protocol
as code will usually expect that. Also, close() has a helpful implementation
Stefan Behnel added the comment:
why not spell them sys.exit.FAILURE and sys.exit.SUCCESS ?
--
nosy: +scoder
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24053
Stefan Behnel added the comment:
Actually, my guess is also that these constants will not be used. Not because
they are not helpful, but because they'd only be available in Python 3.5+.
Meaning that if you use them, your code won't work with long time supported
CPython versions like 3.4
Stefan Behnel added the comment:
Any more comments on this? The deadlines for new features in Py3.5 are getting
closer. It seems we're just discussing details here, but pretty much everyone
wants this feature.
So, what are the things that still need to be done? Serhiy submitted working
Stefan Behnel added the comment:
PEP 489 (Redesigning extension module loading) includes the proposal to fix
this by using punycode.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20485
Stefan Behnel added the comment:
Any more comments on the patch, or can it be applied?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22881
Changes by Stefan Behnel sco...@users.sourceforge.net:
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23996
___
___
Python-bugs
Stefan Behnel added the comment:
Could we have type slots for the new special methods? Otherwise, implementing
the protocol in C would be fairly inefficient, especially for async iteration.
I'm asking because Cython's generator type is not Python's generator type, but
implementing the rest
Stefan Behnel added the comment:
PEP 342 isn't really conclusive here as it intended to define the protocol
based on the de-facto design of a yield-based generator function. Trying to
abstract from that poses the question how a class based generator
implementation should look like
Stefan Behnel added the comment:
In general, wouldn't it be good to let the statistics module do all the stats
calculations?
It's not available in older Python versions, e.g. 2.6.
--
___
Python tracker rep...@bugs.python.org
http
Stefan Behnel added the comment:
FYI, here's the patch implementation for Cython:
https://github.com/cython/cython/blob/cf63ff71c06b16c3a30facdc7859743f4cd495f6/Cython/Utility/Generator.c#L849
The only difference is that it takes care of changing __next__ to next in
Py2.x
Stefan Behnel added the comment:
Searching for Python code that seems to implement the Generator protocol
doesn't return much:
https://code.openhub.net/search?s=%22def%20throw%28%22%20%22def%20send%28%22%20%22def%20close%28%22pp=0fl=Pythonmp=1ml=1me=1md=1ff=1filterChecked=true
But at least
Stefan Behnel added the comment:
Adding a patch for the inspect docs that refers to the Right Way To Do It.
--
Added file: http://bugs.python.org/file39179/inspect_docs.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
Changes by Stefan Behnel sco...@users.sourceforge.net:
Removed file: http://bugs.python.org/file39179/inspect_docs.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
Changes by Stefan Behnel sco...@users.sourceforge.net:
Added file: http://bugs.python.org/file39180/inspect_docs.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
Stefan Behnel added the comment:
Good catch with the RuntimeError. Patch updated.
--
Added file: http://bugs.python.org/file39157/generator_abc.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
Stefan Behnel added the comment:
should inspect.isgenerator() be changed?
Replying to myself, one thing that speaks against this approach is that
inspect also has the functions getgeneratorlocals() and
getgeneratorstate(), which depend on gen.gi_frame. Cython could emulate
that, but normal
Stefan Behnel added the comment:
Yes, and there are certainly other compilers and tools. However, it's going to
be a short list, so if Py3.5 takes the lead, they can all just agree on the one
way to do it and let the first patcher win
Stefan Behnel added the comment:
Yes, code usually doesn't fall from the sky with a new CPython release. If
something wants to make use of this ABC, it still has to find ways to also work
with older CPythons. What would be a good fallback? A backport on PyPI?
I wouldn't even mind shipping
Stefan Behnel added the comment:
Here's a new patch that addresses the review comments. I kept throw() and
close() non-abstract and added an example to the tests instead that implements
a minimal generator by inheriting these methods from the Generator base class,
using it as a mixin. It only
Stefan Behnel added the comment:
Next question: should inspect.isgenerator() be changed? Or should its usages be
replaced by isinstance(obj, Generator) ?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
Stefan Behnel added the comment:
Is it a problem that the check can't be done in a fast way from C code?
C code can still quickly special case the generator type in the positive case,
and it will usually be interested in an exact type match anyway. Determining
that an object
Stefan Behnel added the comment:
I was (silently) hoping that this patching would eventually not be necessary
anymore because the one place (currently inspect.isgenerator()) would be
adapted to check for the generator protocol rather than the generator type. But
that was going to go
Stefan Behnel added the comment:
I created issue 24018 for adding a Generator ABC to collections.abc.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24004
Changes by Stefan Behnel sco...@users.sourceforge.net:
--
nosy: +scoder
type: - enhancement
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
Stefan Behnel added the comment:
Ok, sure. Here's a new patch that adds tests and docs.
--
Added file: http://bugs.python.org/file39150/generator_abc.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
Changes by Stefan Behnel sco...@users.sourceforge.net:
Removed file: http://bugs.python.org/file39146/generator_abc.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
701 - 800 of 3085 matches
Mail list logo
