Stefan Krah added the comment:
There's a comment in _posixsubprocess:
"NetBSD and OpenBSD have a /proc fs available (though not necessarily
mounted) and do not have fdescfs for /dev/fd."
Is this still valid?
--
nosy: +skrah
___
Changes by Stefan Krah :
--
nosy: +gregory.p.smith
___
Python tracker
<http://bugs.python.org/issue23852>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Unfortunately I don't have an OpenBSD install either. From the
sysconf.c source ...
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib/libc/gen/sysconf.c?rev=1.22&content-type=text/plain
... it seems that sysconf(_SC_OPEN_MAX) also calls
Stefan Behnel added the comment:
As noted below the table, the exact size is platform specific, so the current
documentation is correct in stating a "minimum size in bytes" of "2" for int.
https://en.wikipedia.org/wiki/C_data_types
IMHO, close as "not a bug&q
New submission from Stefan Behnel:
The yield-from implementation calls _PyGen_FetchStopIterationValue() to get the
exception value. If the StopIteration exception is not normalised, e.g. because
it was set by PyErr_SetObject() in a C extension, then
_PyGen_FetchStopIterationValue() will cast
Stefan Behnel added the comment:
Here's a better patch that avoids exception normalisation in all "normal" cases.
--
Added file: http://bugs.python.org/file39116/fix_stopiteration_crash.patch
___
Python tracker
<http://bugs.pyt
New submission from Stefan Behnel:
asyncio/coroutines.py contains this code:
"""
_COROUTINE_TYPES = (types.GeneratorType, CoroWrapper)
def iscoroutine(obj):
"""Return True if obj is a coroutine object."""
return isinstance(obj, _C
Stefan Behnel added the comment:
And another patch update that should avoid any potential performance
regressions due to the additional type check.
--
Added file: http://bugs.python.org/file39119/fix_stopiteration_crash.patch
___
Python tracker
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 into a
Changes by Stefan Behnel :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue23996>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
And in fact, fixing it in ceval.c would not be enough, since gen_throw() also
calls the function. So this is really the right place to fix it.
--
___
Python tracker
<http://bugs.python.org/issue23
New submission from Stefan Behnel:
Currently, CPython tends to assume that generators are always implemented by a
Python function that uses the "yield" keyword. However, it is absolutely
possible to implement generators as a protocol by adding send(), throw() and
close() met
Stefan Behnel added the comment:
I created issue 24018 for adding a Generator ABC to collections.abc.
--
___
Python tracker
<http://bugs.python.org/issue24
Changes by Stefan Behnel :
--
nosy: +scoder
type: -> enhancement
___
Python tracker
<http://bugs.python.org/issue24017>
___
___
Python-bugs-list mai
Changes by Stefan Behnel :
Removed file: http://bugs.python.org/file39146/generator_abc.patch
___
Python tracker
<http://bugs.python.org/issue24018>
___
___
Python-bug
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
<http://bugs.python.org/is
Changes by Stefan Behnel :
Removed file: http://bugs.python.org/file39150/generator_abc.patch
___
Python tracker
<http://bugs.python.org/issue24018>
___
___
Python-bug
Stefan Behnel added the comment:
Sorry, here's another doc fix.
--
Added file: http://bugs.python.org/file39151/generator_abc.patch
___
Python tracker
<http://bugs.python.org/is
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
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:
Next question: should inspect.isgenerator() be changed? Or should its usages be
replaced by isinstance(obj, Generator) ?
--
___
Python tracker
<http://bugs.python.org/issue24
Stefan Behnel added the comment:
Good catch with the RuntimeError. Patch updated.
--
Added file: http://bugs.python.org/file39157/generator_abc.patch
___
Python tracker
<http://bugs.python.org/issue24
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
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 min
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 patche
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
<http://bugs.python.org/issue24
Changes by Stefan Behnel :
Added file: http://bugs.python.org/file39180/inspect_docs.patch
___
Python tracker
<http://bugs.python.org/issue24018>
___
___
Python-bug
Changes by Stefan Behnel :
Removed file: http://bugs.python.org/file39179/inspect_docs.patch
___
Python tracker
<http://bugs.python.org/issue24018>
___
___
Python-bug
Stefan Krah added the comment:
> Sadly, for political reasons, it's best that we not convert collections,
> itertools, or random for now.
Well, there are also technical reasons. For example, when reviewing a huge
patch at the beginning of this year, the sections that touched AC
Stefan Krah added the comment:
At first glance the return values look right to me:
The value of exit returned to the parent should be status & 0377.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/iss
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%22&pp=0&fl=Python&mp=1&ml=1&me=1&md=1&am
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 &
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 wo
Stefan Behnel added the comment:
PEP 489 (Redesigning extension module loading) includes the proposal to fix
this by using punycode.
--
___
Python tracker
<http://bugs.python.org/issue20
Changes by Stefan Behnel :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue23996>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
Any more comments on the patch, or can it be applied?
--
___
Python tracker
<http://bugs.python.org/issue22881>
___
___
Python-bug
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
implement
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
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
<http://bugs.py
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 implement
Stefan Krah added the comment:
I'm +0 on adding these. The only reason is that I've seen academic
code written by well-known researchers that used 1 for a successful
exit. :)
I'm not sure about the os module. These are C99 and
Stefan Behnel added the comment:
why not spell them "sys.exit.FAILURE" and "sys.exit.SUCCESS" ?
--
nosy: +scoder
___
Python tracker
<http://bug
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 li
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:
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
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 l
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
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,
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
<http://bugs.python.org
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 g
Stefan Behnel added the comment:
Well, we can apply a kludge, or apply statistics.
--
___
Python tracker
<http://bugs.python.org/issue22881>
___
___
Python-bug
Stefan Behnel added the comment:
See issue 24076.
--
nosy: +scoder
___
Python tracker
<http://bugs.python.org/issue24138>
___
___
Python-bugs-list mailin
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):
...
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
<
Stefan Behnel added the comment:
This is blocking issue 24017 (async/await syntax).
--
___
Python tracker
<http://bugs.python.org/issue24018>
___
___
Python-bug
Stefan Behnel added the comment:
Thanks! Minor grouch: it should say "collections.*abc*.Generator" in the NEWS
entry.
--
___
Python tracker
<http://bugs.python.o
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:
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))&#x
Stefan Behnel added the comment:
Issue 24165 was created to pursue the path of a free-list for PyLong objects.
--
___
Python tracker
<http://bugs.python.org/issue24
Stefan Krah added the comment:
The problem with this macro is that most of the time it takes the
standard cmp return value {-1,0,1} and converts that into a bool.
For this use case, it might be more appropriate to use a
static inline function Py_cmp_to_bool().
To put it differently, the macro
Stefan Krah added the comment:
I mean it's clearer to have:
result = long_compare(self, other);
return Py_cmp_to_bool(result, op);
than:
result = long_compare(self, other);
Py_RETURN_RICHCOMPARE(result, 0, op);
This is because in other places, like the proposed use
ca
New submission from Stefan Krah:
Since Grammar/Grammar relies on semantic postprocessing in ast.c,
it would be nice to have an update of the (human readable) Grammar
in the language reference docs.
--
messages: 243587
nosy: skrah
priority: normal
severity: normal
status: open
title: PEP
Changes by Stefan Krah :
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
stage: -> needs patch
type: -> enhancement
versions: +Python 3.5
___
Python tracker
<http://bugs.python.or
Stefan Krah added the comment:
It seems that it won't be easy to find an API that pleases everyone.
I don't want to prolong the discussion much, but if the macro goes in,
returning PyErr_BadArgument() in the default case would be better than
NotImplemented.
assert(0) would be fi
Stefan Krah added the comment:
NotImplemented is a non-error return value that's used when the
objects cannot be compared, e.g. when the function receives Py_LT
but the objects are unorderable.
Getting a value outside {Py_EQ, ...} is a hard error that cannot
occur in a correct pr
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
it
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
<http://bugs.python.org/issue24
Stefan Krah added the comment:
I would go further and forbid tabs after spaces entirely. Tabs
used for indentation with spaces following for formatting are
okay (though unusual in Python).
--
nosy: +skrah
___
Python tracker
<http://bugs.python.
Stefan Krah added the comment:
Then pep-008 is wrong, too, since the implementation *does* allow
Evgeny's example.
The current implementation just checks if the same INDENT/DEDENT
tokens are generated for tab widths 1 and 8.
--
___
Python tr
Changes by Stefan Behnel :
--
nosy: +scoder
___
Python tracker
<http://bugs.python.org/issue17239>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
&l
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
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 sep
Stefan Behnel added the comment:
Done:
https://github.com/python/performance/pull/10
Note that I didn't replace the existing telco benchmark as it is more specific
to Decimal. The new benchmark makes it possible to compare the decimal and
fractions modules for similar operations, t
Changes by Stefan Behnel :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue22881>
___
___
Python-bugs-list
Stefan Krah added the comment:
I think string conversion should be part of this benchmark, or it should be
renamed to fraction-arith or something.
The formatting function can be a significant bottleneck, and if you use
Fractions for financial calculations the result will still need to be
Stefan Krah added the comment:
I'm also not opposed to adding it (-0.000) as long as we rename it to
bm_fractions.py and change the docstring to "based on the telco benchmark".
--
___
Python tracker
<http://bugs.pyt
Stefan Behnel added the comment:
I haven't seen any crashes in the wild here, but this is still the case in the
latest code base. The change doesn't seem invasive, so I don't see why it
shouldn't get implemented.
--
nosy: +pitrou, scoder, serhiy.storchaka
versions:
Stefan Behnel added the comment:
Looks like I forgot about this. My final fix still hasn't been applied, so the
code in Py3.4+ is incorrect now.
No, this cannot be tested from the Python level.
--
___
Python tracker
<http://bugs.py
Stefan Krah added the comment:
"hand written signatures" refers to the signatures that Argument Clinic would
generate if it were used (but I don't want that).
So this is an example of a hand written signature:
"is_infinite($self, /)\n--\n\n\"
I still wonder if
Stefan Krah added the comment:
I've left comments on GitHub.
[scoder]
> As I said, where ever exact calculations are needed..
Even if the formatting comment is addressed, the main problem with
this benchmark is that *both* fraction and decimal calculations
are in fact exact here.
Stefan Behnel added the comment:
> So this benchmark cannot be used to show the superiority of exact fractions.
I don't see how a benchmark would be a way to show that. It's certainly not the
goal of this benchmark to show that one is computationally better than the
other. But i
Stefan Behnel added the comment:
> By the way, I'm surprised that the special encoding "unicode" relies on the
> *current* locale encoding when the XML declaration is requested.
That seems a weird choice. Since it serialises to a Unicode string, it
shouldn't have
Stefan Krah added the comment:
The reason is that the benchmark is a softball for fractions. Using the fastest
fraction implementation (gmpy.mpq) and the best printing method for both types,
gmpy.mpq seems to be about 2.5 to 3 times slower than decimal.
It is however easy to generate
Stefan Krah added the comment:
Hardly a bad error message, but see #26208.
--
nosy: +skrah
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> decimal C module's exceptions don't match the Python version
type: b
Stefan Krah added the comment:
Which Stefan? :)
Anyway, the first half of this issue was centered around the
proposition that fractions are a "better decimal", and the
latest pull request still has the "decimal backend" in it. :)
Fast fractions have been around for a
Stefan Behnel added the comment:
Let's close this as outdated. New bugs for the new project should be reported
in github anyway.
--
resolution: -> out of date
status: open -> closed
___
Python tracker
<http://bugs.python.
Stefan Krah added the comment:
Sorry, Raymond, this is my code area. I said I'll review a patch.
--
assignee: lisroach -> skrah
___
Python tracker
<http://bugs.python.org
Changes by Stefan Drees :
--
nosy: +dilettant
___
Python tracker
<http://bugs.python.org/issue27350>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
Definitely not a bug since this isn't required by the XML spec. As said in
issue 2647, you shouldn't rely on exact lexical characteristics of an XML byte
stream, unless you request canonical serialisa
Stefan Behnel added the comment:
Raymond, you might have meant me when assigning the ticket and not Stefan Krah,
but since I'm actually not a core dev, I can't commit the patch myself.
See my last comment, though, I reviewed the patch and it should get
Stefan Krah added the comment:
Probably this one: #23545
--
nosy: +skrah
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue17884>
___
_
Stefan Krah added the comment:
Agreed. SilentGhost, it's probably best to open new issues for the warnings.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Stefan Krah :
--
nosy: +ned.deily
priority: normal -> release blocker
___
Python tracker
<http://bugs.python.org/issue28040>
___
___
Python-bugs-lis
Stefan Krah added the comment:
The Blaze test suite segfaults with 4a5b61b0d090.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue28040>
___
___
Stefan Krah added the comment:
Yes, I'm sure. I even cloned a fresh repo. Also, I tested in
release mode (not --with-pydebug).
https://github.com/blaze/blaze
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
I'm not sure. In the Blaze test suite, 1e7b636b6009 has the SystemError.
4a5b61b0d090 segfaults.
Blaze is pushing Python's dynamic capabilities to absolute limits,
so perhaps this is specific to a few applications only.
For Blaze *itself* there is no
Stefan Krah added the comment:
If Victor can't reply now (it's getting late in Europe), I'd just release.
Pretend that I set it to deferred blocker. :)
--
priority: release blocker -> deferred blocker
___
Python tracker
<h
Stefan Krah added the comment:
It could still be a stack overflow, but on the surface it does
not look like one. It's definitely related to the aforementioned
revision:
==3442== Invalid read of size 8
==3442==at 0x49DBD8: _PyDict_Pop (dictobject.c:1743)
==3442==by 0x4A0BE2: dic
Stefan Krah added the comment:
I don't understand how the original issue is fixed if 1e7b636b6009
exhibits the SystemError and the very next revision 4a5b61b0d090
(the fix) segfaults. And the test suite works with the previous
dict.
Sure, it can be a third party issue, but this constell
4801 - 4900 of 4955 matches
Mail list logo
