[issue25047] xml.etree.ElementTree encoding declaration should be capital ('UTF-8') rather than lowercase ('utf-8')

Stefan Behnel added the comment: LGTM -- nosy: +scoder ___ Python tracker <http://bugs.python.org/issue25047> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue25154] Drop the pyvenv script

Stefan Behnel added the comment: May I ask how difficult it is for any of the core developers to fix a known typo in a Python source file? -- nosy: +scoder ___ Python tracker <http://bugs.python.org/issue25

[issue22995] Restrict default pickleability

Stefan Behnel added the comment: Thanks for calling me in. I can confirm that the stack trace in https://paste.debian.net/361351/ points at a bug in Cython's own implementation (not the code it generates). It's deep-copying objects that don't support it (which doesn't nor

[issue22995] Restrict default pickleability

Stefan Behnel added the comment: For reference, the bug in Cython is fixed here: https://github.com/cython/cython/commit/ececb3e9473f6aaa65f29467921594c316ec2f06 -- ___ Python tracker <http://bugs.python.org/issue22

[issue22995] Restrict default pickleability

Stefan Behnel added the comment: In fact, I did consider it and I'd love to, but it's not something to do lightly because the semantics would be a bit fuzzy and unsafe. Basically, extension types that have only Python object compatible attributes could automatically pickle, but as s

[issue24165] Free list for single-digits ints

Stefan Behnel added the comment: I like Serhiy's patch, too, but it feels like the single-digit case should be enough. I found this comment by Yury a good argument: """ I can see improvements in micro benchmarks, but even more importantly, Serhiy's patch reduces memor

[issue26331] Tokenizer: allow underscores for grouping in numeric literals

Stefan Behnel added the comment: Nice one. While reimplementing it for Cython, I noticed that the grammar described in the PEP isn't exactly as it's implemented, though. The grammar says digit (["_"] digit)* whereas the latest patch (v4) says `digit` (`digi

[issue26331] Tokenizer: allow underscores for grouping in numeric literals

Stefan Behnel added the comment: Ah, thanks. Here's my implementation then: https://github.com/cython/cython/pull/499/files It seems that tests for valid complex literals are missing. I've added these to the end of the list: '1_00_00.5j', '1_

[issue26519] Cython doesn't work anymore on Python 3.6

Stefan Behnel added the comment: Our CI build server says it's all fine. The fix will eventually be released, certainly before Py3.6 comes out. -- ___ Python tracker <http://bugs.python.org/is

[issue23507] Tuple creation is too slow

Changes by Stefan Behnel : -- nosy: +scoder ___ Python tracker <http://bugs.python.org/issue23507> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23712] Experiment: Assume that exact unicode hashes are perfect discriminators

Stefan Behnel added the comment: The problem is, even if the chance is excessively small, it's not zero. Meaning, someone's data set somewhere will break somehow. And with hash randomisation, it'll mean that the problem spotted in some life system will be entirely unrepro

[issue23642] Interaction of ModuleSpec and C Extension Modules

Changes by Stefan Behnel : -- nosy: +scoder ___ Python tracker <http://bugs.python.org/issue23642> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23602] Implement __format__ for Fraction

Stefan Behnel added the comment: Absolutely. Fractions are all about exact calculations, much more so than Decimals. So the formatting output should be as accurate as requested or possible (well, excluding infinity). -- nosy: +scoder ___ Python

[issue23602] Implement __format__ for Fraction

Stefan Behnel added the comment: But these parameters could also be partly delegated to normal string (not number) formatting, right? One of the advantages of not depending on Decimal is, well, to not depend on Decimal, which is a rather uncommon dependency when using Fractions in an

[issue23602] Implement __format__ for Fraction

Stefan Behnel added the comment: Meaning, something like this should work: x = (nom * 10**(prec+1)) // den if x % 10 < 5: x = x // 10 else: x = x // 10 + 1 print('%s.%s' % (x[:-prec], x[-prec:])) -- ___ P

[issue23602] Implement __format__ for Fraction

Stefan Behnel added the comment: Or, speaking of "division with remainder": n, r = divmod(nom * 10**prec, den) if r * 5 >= den: n += 1 x = str(n) print('%s.%s' % (x[:-prec], x[-prec:])) ... minus the usual off-by-one that the t

[issue16991] Add OrderedDict written in C

Stefan Behnel added the comment: > do not add a C-API what speaks against it? -- nosy: +scoder ___ Python tracker <http://bugs.python.org/issue16991> ___ _

[issue23847] Add xml pretty print option to ElementTree

Stefan Behnel added the comment: duplicate of issue 14465 -- nosy: +rhettinger ___ Python tracker <http://bugs.python.org/issue23847> ___ ___ Python-bugs-list m

[issue23913] error in some byte sizes of docs in array module

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

[issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions

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

[issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions

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

[issue24004] avoid explicit generator type check in asyncio

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

[issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions

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

[issue24004] avoid explicit generator type check in asyncio

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

[issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions

Changes by Stefan Behnel : -- nosy: +ncoghlan ___ Python tracker <http://bugs.python.org/issue23996> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions

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

[issue24018] add a Generator ABC

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

[issue24004] avoid explicit generator type check in asyncio

Stefan Behnel added the comment: I created issue 24018 for adding a Generator ABC to collections.abc. -- ___ Python tracker <http://bugs.python.org/issue24

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

Changes by Stefan Behnel : -- nosy: +scoder type: -> enhancement ___ Python tracker <http://bugs.python.org/issue24017> ___ ___ Python-bugs-list mai

[issue24018] add a Generator ABC

Changes by Stefan Behnel : Removed file: http://bugs.python.org/file39146/generator_abc.patch ___ Python tracker <http://bugs.python.org/issue24018> ___ ___ Python-bug

[issue24018] add a Generator ABC

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

[issue24018] add a Generator ABC

Changes by Stefan Behnel : Removed file: http://bugs.python.org/file39150/generator_abc.patch ___ Python tracker <http://bugs.python.org/issue24018> ___ ___ Python-bug

[issue24018] add a Generator ABC

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

[issue24018] add a Generator ABC

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

[issue24018] add a Generator ABC

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

[issue24018] add a Generator ABC

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

[issue24018] add a Generator ABC

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

[issue24018] add a Generator ABC

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

[issue24018] add a Generator ABC

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

[issue24018] add a Generator ABC

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

[issue24018] add a Generator ABC

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

[issue24018] add a Generator ABC

Changes by Stefan Behnel : Added file: http://bugs.python.org/file39180/inspect_docs.patch ___ Python tracker <http://bugs.python.org/issue24018> ___ ___ Python-bug

[issue24018] add a Generator ABC

Changes by Stefan Behnel : Removed file: http://bugs.python.org/file39179/inspect_docs.patch ___ Python tracker <http://bugs.python.org/issue24018> ___ ___ Python-bug

[issue24018] add a Generator ABC

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

[issue24018] add a Generator ABC

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 &

[issue22486] Add math.gcd()

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

[issue20485] Enable non-ASCII extension module names

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

[issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions

Changes by Stefan Behnel : -- nosy: +pitrou ___ Python tracker <http://bugs.python.org/issue23996> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22881] show median in benchmark results

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

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

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

[issue24018] add a Generator ABC

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

[issue22881] show median in benchmark results

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

[issue24018] add a Generator ABC

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

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

Stefan Behnel added the comment: why not spell them "sys.exit.FAILURE" and "sys.exit.SUCCESS" ? -- nosy: +scoder ___ Python tracker <http://bug

[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys

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

[issue24076] sum() several times slower on Python 3

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

[issue24079] xml.etree.ElementTree.Element.text does not conform to the documentation

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

[issue24076] sum() several times slower on Python 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 l

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

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

[issue24076] sum() several times slower on Python 3

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,

[issue22881] show median in benchmark results

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

[issue22881] show median in benchmark results

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

[issue22881] show median in benchmark results

Stefan Behnel added the comment: Well, we can apply a kludge, or apply statistics. -- ___ Python tracker <http://bugs.python.org/issue22881> ___ ___ Python-bug

[issue24138] Speed up range() by caching and modifying long objects

Stefan Behnel added the comment: See issue 24076. -- nosy: +scoder ___ Python tracker <http://bugs.python.org/issue24138> ___ ___ Python-bugs-list mailin

[issue2292] Missing *-unpacking generalizations

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): ...

[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax

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 <

[issue24018] add a Generator ABC

Stefan Behnel added the comment: This is blocking issue 24017 (async/await syntax). -- ___ Python tracker <http://bugs.python.org/issue24018> ___ ___ Python-bug

[issue24018] add a Generator ABC

Stefan Behnel added the comment: Thanks! Minor grouch: it should say "collections.*abc*.Generator" in the NEWS entry. -- ___ Python tracker <http://bugs.python.o

[issue24165] Free list for single-digits ints

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

[issue24165] Free list for single-digits ints

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

[issue24076] sum() several times slower on Python 3

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

[issue24221] Clean-up and optimization for heapq siftup() and siftdown()

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

[issue24221] Clean-up and optimization for heapq siftup() and siftdown()

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

[issue17239] XML vulnerabilities in Python

Changes by Stefan Behnel : -- nosy: +scoder ___ Python tracker <http://bugs.python.org/issue17239> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24270] PEP 485 (math.isclose) implementation

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

[issue24270] PEP 485 (math.isclose) implementation

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

[issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions

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

[issue22458] Add fractions benchmark

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

[issue22881] show median in benchmark results

Changes by Stefan Behnel : -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue22881> ___ ___ Python-bugs-list

[issue25750] tp_descr_get(self, obj, type) is called without owning a reference to "self"

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:

[issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions

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

[issue22458] Add fractions benchmark

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

[issue27940] xml.etree: Avoid XML declaration for the "ascii" encoding

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

[issue19108] Benchmark runner tries to execute external Python command and fails on error reporting

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.

[issue27899] Apostrophe is not replace with ' ElementTree.tostring (also in Element.write)

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

[issue17582] xml.etree.ElementTree does not preserve whitespaces in attributes

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

[issue27961] remove support for platforms without "long long"

Stefan Behnel added the comment: Removing HAVE_LONG_LONG entirely causes breakage of third party code that uses this macro to enable PY_LONG_LONG support. Could you please always define it instead of removing it? -- nosy: +scoder ___ Python tracker

<    8   9   10   11   12   13