Change by Stefan Behnel :
--
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue46798>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Stefan Behnel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Behnel added the comment:
New changeset 345572a1a0263076081020524016eae867677cac by Jannis Vajen in
branch 'main':
bpo-46786: Make ElementTree write the HTML tags embed, source, track, wbr as
empty tags (GH-31406)
https://github.com/python/cpython/commit
Stefan Behnel added the comment:
Possibly also related, so I though I'd mention it here (sorry if this is
hijacking the ticket, seems difficult to tell). We're also seeing None values
in f_lineno in Cython's test suite with 3.11a5:
File "", line 1, in
run_trace(py
Stefan Behnel added the comment:
I haven't looked fully into this yet, but I *think* that Cython can get rid of
most of the direct usages of PyFrameObject by switching to the new
InterpreterFrame struct instead. It looks like the important fields have now
been moved over
Stefan Behnel added the comment:
> IMHO if the developer doesn't manage the XML itself it is VERY unreasonable
> to use the document value and not the developer one.
I disagree. If the document says "this is the default if no explicit value if
given", then I consider t
Stefan Behnel added the comment:
Makes sense. That list hasn't been updated in 10 years.
--
versions: -Python 3.10, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue46
Stefan Behnel added the comment:
The question here is simply, which is considered more important: the default
provided by the document, or the default provided by Python. I don't think it's
a clear choice, but the way it is now does not seem unreasonable. Changing it
would mean deliberate
Stefan Behnel added the comment:
> Any reasons the PR still not merged?
There was dissent about whether these constants should be added or not. It
doesn't help to merge a PR that is not expected to provide a benefit.
--
___
Python tracker
<
Stefan Behnel added the comment:
This is a backwards incompatible change, but unlikely to have a wide impact.
I was thinking for a second if it's making the change in the right direction
because it's not unreasonable to pass "None" for saying "I want no target". But
it's
Stefan Behnel added the comment:
Cython should be happy with whatever CPython uses (as long as CPython's header
files agree with CPython's build ;-) ).
I saw the RasPi benchmarks on the ML. That would have been my suggested trial
platform as well.
https://mail.python.org/archives/list/python
Stefan Behnel added the comment:
I'd like to ask for clarification regarding issue 45321, which adds the missing
error constants to the `expat` module. I consider those new features – it seems
inappropriate to add new module constants in the middle of a release series.
However
Change by Stefan Behnel :
--
components: +XML
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> enhancement
versions: -Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tra
Stefan Behnel added the comment:
New changeset e18d81569fa0564f3bc7bcfd2fce26ec91ba0a6e by Sebastian Pipping in
branch 'main':
bpo-45321: Add missing error codes to module `xml.parsers.expat.errors`
(GH-30188)
https://github.com/python/cpython/commit/e18d81569fa0564f3bc7bcfd2fce26ec91ba0a6e
Stefan Behnel added the comment:
FYI, we track the Cython side of this in
https://github.com/cython/cython/issues/4500
--
___
Python tracker
<https://bugs.python.org/issue45
Change by Stefan Behnel :
--
nosy: +scoder
___
Python tracker
<https://bugs.python.org/issue45711>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
Given that PEP-489 has landed in Py3.5, which is already retired and has been
for more than a year, I think we can just close this issue as outdated.
--
resolution: -> out of date
stage: needs patch -> resolved
status: open -&g
Stefan Behnel added the comment:
Sorry for that, Pablo. I knew exactly where the problem was, the second I read
your notification. Thank you for resolving it so quickly.
--
___
Python tracker
<https://bugs.python.org/issue24
Change by Stefan Behnel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Behnel added the comment:
Old, with PGO:
$ ./python -m timeit -s 'd = list(range(2**61, 2**61 + 1))' 'sum(d)'
1000 loops, best of 5: 340 usec per loop
$ ./python -m timeit -s 'd = list(range(2**30, 2**30 + 1))' 'sum(d)'
2000 loops, best of 5: 114 usec per loop
$ ./python -m
Stefan Behnel added the comment:
Hmm, thanks for insisting, Serhiy. I was accidentally using a debug build this
time. I'll make a PGO build and rerun the microbenchmarks.
--
___
Python tracker
<https://bugs.python.org/issue24
Stefan Behnel added the comment:
Original:
$ ./python -m timeit -s 'd = list(range(2**61, 2**61 + 1))' 'sum(d)'
500 loops, best of 5: 712 usec per loop
$ ./python -m timeit -s 'd = list(range(2**30, 2**30 + 1))' 'sum(d)'
2000 loops, best of 5: 149 usec per loop
$ ./python -m timeit -s
Change by Stefan Behnel :
--
Removed message: https://bugs.python.org/msg402301
___
Python tracker
<https://bugs.python.org/issue24076>
___
___
Python-bugs-list m
Stefan Behnel added the comment:
Original:
$ ./python -m timeit -s 'd = list(range(2**61, 2**61 + 1))' 'sum(d)'
500 loops, best of 5: 712 usec per loop
$ ./python -m timeit -s 'd = list(range(2**30, 2**30 + 1))' 'sum(d)'
2000 loops, best of 5: 149 usec per loop
$ ./python -m timeit -s
Stefan Behnel added the comment:
New changeset debd80403721b00423680328d6adf160a28fbff4 by scoder in branch
'main':
bpo-24076: Inline single digit unpacking in the integer fastpath of sum()
(GH-28469)
https://github.com/python/cpython/commit/debd80403721b00423680328d6adf160a28fbff4
Stefan Behnel added the comment:
> The patch looks fine, but it looks a bit like benchmark chasing. Is the speed
> of builtin sum() of a sequence of integers important enough to do this bit of
> inlining?
Given that we already accepted essentially separate loops for the i
Stefan Behnel added the comment:
> The code in the examples given above are using `tstate->use_tracing` assuming
> that its meaning is to determine whether tracing is turned on or not.
No, actually not. It is using the field in the same way as CPython, simply
because most of
Stefan Behnel added the comment:
I created a PR from my last patch, inlining the unpacking of single digit
integers. Since most integers should fit into a single digit these days, this
is as fast a path as it gets.
https://github.com/python/cpython/pull/28469
--
versions: +Python
Change by Stefan Behnel :
--
pull_requests: +26868
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/28469
___
Python tracker
<https://bugs.python.org/issu
Stefan Behnel added the comment:
The obvious work-around is to not use a default namespace. The result is just a
visual difference, not a semantic one.
If someone wants to continue with the existing PR, I'll try to free some time
to review any improvements.
--
versions: +Python
Stefan Behnel added the comment:
I only just noticed that the original request is from 2015. My guess is that
this is a resolved problem, given the available options. I'll close this ticket
as outdated. Please comment if this is still an issue.
--
resolution: -> out of date
st
Change by Stefan Behnel :
--
components: +C API -Interpreter Core
type: -> enhancement
versions: +Python 3.11 -Python 3.5
___
Python tracker
<https://bugs.python.org/issu
Stefan Behnel added the comment:
Could you explain a bit why you want to subclass "PyModuleObject" in C? Why
isn't a Python subclass or an independent (non-module) C extension type enough?
--
___
Python tracker
<https://bugs.python.o
Stefan Behnel added the comment:
After reading up a bit, version "X" should probably be rejected, whereas
"1.[0-9]+" is meant to be allowed also by a 1.0 parser, according to the spec:
https://www.w3.org/TR/REC-xml/#sec-prolog-dtd
"""
When an XML
Stefan Behnel added the comment:
Just FYI, I applied the same changes to the quicktions [1] module, a Cython
compiled (and optimised) version of fractions.Fraction.
[1] https://github.com/scoder/quicktions/
The loss in performance for small values is much higher there, almost 2x
Change by Stefan Behnel :
--
Removed message: https://bugs.python.org/msg393667
___
Python tracker
<https://bugs.python.org/issue43760>
___
___
Python-bugs-list m
Stefan Behnel added the comment:
Should we allow empty CFrame entries (with a NULL Frame pointer) that only use
their "use_tracing" flag? That would make it easy for code to append and remove
such an entry in order to temporarily disab
Stefan Behnel added the comment:
I just noticed that new C-API functions are probably useless for Cython since I
think it will have to maintain the CFrame stack, so not to enable "use_tracing"
for the (Python) caller but the current (Cython) function. This then means that
we own T
Stefan Behnel added the comment:
Just a comment regarding the change to "PyCode_NewWithPosOnlyArgs()". As Pablo
mentioned, this has happened before. And that's OK! Exactly because this has
happened before, it's clearly not a part of the API that is meant to be stable.
I can ea
Stefan Behnel added the comment:
For the same reason that motivated this ticket, I think the functions should be
inline functions. They should also take the current thread-state as argument,
because that's probably known on the caller side already.
I guess a macro would be fine, too
Stefan Behnel added the comment:
> I really don't know why you would desire a different result.
I found it surprising that a comparison uses a different method of conversion
than the (obvious) user-side conversion, with a different outcome. This seems
to be implementation details leak
Change by Stefan Behnel :
--
nosy: +tim.peters
___
Python tracker
<https://bugs.python.org/issue44054>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Stefan Behnel :
I'm not sure if I should consider this a bug, but I'd at least frown at the
behaviour, so I thought I'd bring this up here.
Python 3.8.5 (default, Jan 27 2021, 15:41:15)
[GCC 9.3.0] on linux
>>> 2**53 == float(2**53)
True
>>> float(2**53
Change by Stefan Behnel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Stefan Behnel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Behnel added the comment:
New changeset ff7266efd0ef6b42dad30c9c0d210f843cc44f39 by Miss Islington (bot)
in branch '3.8':
bpo-43959: clarify the documentation of the PyContextVar C-API (GH-25671)
(GH-25690)
https://github.com/python/cpython/commit
Stefan Behnel added the comment:
New changeset fdb11897d7c8f9e6bdf96fcef802f784ef90f726 by Miss Islington (bot)
in branch '3.9':
bpo-43959: clarify the documentation of the PyContextVar C-API (GH-25671)
(GH-25689)
https://github.com/python/cpython/commit
Stefan Behnel added the comment:
I just remembered that it's usually helpful to return the previous state, so
that callers know whether they need to re-enable or disable the GC when they're
done. I'll add that.
Also, returning an "int" may allow us to add a "-1" erro
Change by Stefan Behnel :
--
nosy: +scoder
nosy_count: 3.0 -> 4.0
pull_requests: +24377
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/25687
___
Python tracker
<https://bugs.python.org/i
Change by Stefan Behnel :
--
keywords: +patch
pull_requests: +24362
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25671
___
Python tracker
<https://bugs.python.org/issu
New submission from Stefan Behnel :
The documentation of the PyContextVar C-API is unclear in a couple of places.
- It's not clear whether PyContextVar_Get() always returns an owned reference
also for default values or only if a value was found.
- It's not explicit that "optional"
Stefan Behnel added the comment:
Coming back to this after a while. I would like to get rid of the work-around
(read: huge hack) that we have in Cython for this check and thus would ask for
the check to be removed in Py3.10.
According to the discussion, no-one seemed to remember why
Stefan Behnel added the comment:
I support that there should be a simple way to do this from C. The way via
importing the "gc" module and then looking up an attribute (possibly building a
Unicode string) and calling a function in it involves several operations that
can take
Stefan Behnel added the comment:
The macros were moved to "Includes/cpython/", not to "Includes/internal/". That
suggests to me that they should use "extern C", so that C++ code that wants to
make use of CPython internals can use them.
Basically, the wa
Stefan Behnel added the comment:
> why /shouldn't/ we make the change?
It breaks doctests, and probably some other unit tests, too, e.g. for output
formatting.
What should we suggest users to do? Replace
>>> get_flag(…)
by
>>> get_flag(…) == app_enums.Tr
Stefan Behnel added the comment:
These macros are a sort-of documented part of the C-API. At least, they were
mentioned in a What's New document:
https://docs.python.org/3/whatsnew/2.7.html?highlight=py_isspace#build-and-c-api-changes
They were added here, for the Py2.7 release:
https
Stefan Behnel added the comment:
Yes, this is neither a bug in CPython (or its stdlib) nor in lxml. It's how
things work. Don't use these two together.
--
resolution: -> third party
stage: -> resolved
status: open -> closed
___
Pytho
Stefan Behnel added the comment:
Almost certainly not a bug in CPython's stdlib.
Possibly something worth investigating in lxml, although, as stated in issue
43618, random.shuffle() simply does not work on lxml.etree Elements.
--
resolution: -> third party
stage: -> re
Stefan Behnel added the comment:
Thanks for the report and the PR. I would argue that this can still be fixed in
Py3.8, given the low impact (but not earlier). The behaviour is clearly wrong
(in a subtle way) and most users won't notice it because they won't switch off
the C accelerator
Change by Stefan Behnel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Behnel added the comment:
New changeset 97e8b1eaeaf3aa325c84ff2e13417c30414d0269 by Ammar Askar in branch
'master':
bpo-40624: Add support for the XPath != operator in xml.etree (GH-22147)
https://github.com/python/cpython/commit/97e8b1eaeaf3aa325c84ff2e13417c30414d0269
Stefan Behnel added the comment:
In general, since the C accelerator is enabled by default, and few people would
consider disabling it explicitly, I generally consider the behaviour of the C
implementation to be "right", if both implementations differ.
As a single data point, the
Stefan Behnel added the comment:
The patch looks right. I'm not sure if this can still be changed in Py3.8,
though, since that has been around for quite a while now.
Admittedly, few people will disable the C accelerator module and thus whitness
this issue, but for them, this is a breaking
Stefan Behnel added the comment:
> Don't forget to remove PyGen_Send()
That's the function that allows sending data into a generator. It's also used
internally by "PyIter_Send()". Are you really suggesting to remove it, or to
make it underscore-private again? (As
Stefan Behnel added the comment:
Closing since this works as designed.
Users are responsible for avoiding concurrent tree modifications during
iteration.
--
resolution: -> not a bug
stage: patch review -> resolved
status: open -&g
Change by Stefan Behnel :
--
pull_requests: +21547
pull_request: https://github.com/python/cpython/pull/22546
___
Python tracker
<https://bugs.python.org/issue41
Change by Stefan Behnel :
--
nosy: -scoder
___
Python tracker
<https://bugs.python.org/issue33802>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Stefan Behnel :
--
nosy: -scoder
___
Python tracker
<https://bugs.python.org/issue6721>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Stefan Behnel :
--
pull_requests: -21521
___
Python tracker
<https://bugs.python.org/issue33802>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Stefan Behnel :
--
nosy: -scoder
___
Python tracker
<https://bugs.python.org/issue36533>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Stefan Behnel :
--
pull_requests: -21519
___
Python tracker
<https://bugs.python.org/issue6721>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Stefan Behnel :
--
pull_requests: -21520
___
Python tracker
<https://bugs.python.org/issue36533>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Stefan Behnel :
--
nosy: +scoder
nosy_count: 9.0 -> 10.0
pull_requests: +21521
pull_request: https://github.com/python/cpython/pull/22474
___
Python tracker
<https://bugs.python.org/issu
Change by Stefan Behnel :
--
nosy: +scoder
nosy_count: 9.0 -> 10.0
pull_requests: +21520
pull_request: https://github.com/python/cpython/pull/22474
___
Python tracker
<https://bugs.python.org/issu
Change by Stefan Behnel :
--
nosy: +scoder
nosy_count: 29.0 -> 30.0
pull_requests: +21519
pull_request: https://github.com/python/cpython/pull/22474
___
Python tracker
<https://bugs.python.org/iss
Change by Stefan Behnel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Behnel added the comment:
New changeset a0f2b664335eb689abdecc677e09a193f503af59 by Miss Skeleton (bot)
in branch '3.9':
bpo-41900: C14N 2.0 serialisation failed for unprefixed attributes when a
default namespace was defined. (GH-22474) (GH-22507)
https://github.com/python/cpython
Stefan Behnel added the comment:
New changeset cfed5343331350c5737b464970a31f7588319e8b by Miss Skeleton (bot)
in branch '3.8':
bpo-41900: C14N 2.0 serialisation failed for unprefixed attributes when a
default namespace was defined. (GH-22474) (GH-22508)
https://github.com/python/cpython
Stefan Behnel added the comment:
New changeset 6a412c94b6b68e7e3632562dc7358a12ffd1447f by scoder in branch
'master':
bpo-41900: C14N 2.0 serialisation failed for unprefixed attributes when a
default namespace was defined. (GH-22474)
https://github.com/python/cpython/commit
Change by Stefan Behnel :
--
versions: +Python 3.10, Python 3.9
___
Python tracker
<https://bugs.python.org/issue41892>
___
___
Python-bugs-list mailin
Change by Stefan Behnel :
--
keywords: +patch
pull_requests: +21493
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/22474
___
Python tracker
<https://bugs.python.org/issu
New submission from Stefan Behnel :
import xml.etree.ElementTree as ET
xml="""
http://soap.sforce.com/2006/04/metadata;>
"""
print(ET.canonicalize(xml))
Fails with:
ValueError: Namespace "" is not declared in scope
when trying to build the QN
Stefan Behnel added the comment:
Yes, it fixed already. Thanks!
--
nosy: +scoder
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Behnel added the comment:
Closing as duplicate of issue 41891. Let's keep the discussion there.
--
nosy: +scoder
resolution: -> duplicate
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Stefan Behnel :
--
Removed message: https://bugs.python.org/msg377740
___
Python tracker
<https://bugs.python.org/issue41899>
___
___
Python-bugs-list m
Stefan Behnel added the comment:
Closing as duplicate of issue 41892. Let's keep the discussion there.
--
___
Python tracker
<https://bugs.python.org/issue41
Stefan Behnel added the comment:
@WoodyWoo, you can (and should) do something like this:
for ELEMchild in list(etroot):
Modifying a container while iterating over it is usually not a good idea. The
same applies to Python lists and dicts, for example.
--
stage: patch review
Change by Stefan Behnel :
--
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue41892>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Stefan Behnel :
--
keywords: +patch
pull_requests: +21489
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22464
___
Python tracker
<https://bugs.python.org/issu
Stefan Behnel added the comment:
> That example is especially problematic.
No, it's not. It uses .findall(), which returns a list. It's like when you make
a copy of a list to iterate over, when you want to modify the original list in
the loop.
That could be made explicit in the t
Change by Stefan Behnel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Behnel added the comment:
FYI, https://github.com/cython/cython/pull/3427 has been merged into Cython. In
Cython 3.0, compiled coroutines will disguise as non-compiled coroutines, from
the PoV of asyncio.
Restricting this ticket to Py3.10 since we're rather discussing a new feature
Stefan Behnel added the comment:
Closing again since GH-21528 has been merged in issue 41295.
--
status: open -> closed
___
Python tracker
<https://bugs.python.org/issu
Stefan Behnel added the comment:
BTW, just to give this a house number, I remember having measured a performance
improvement of up to 70% at some point when switching from "generators always
raise a StopIteration at the end" to "generators just return NULL" in Cython
Stefan Behnel added the comment:
I would also have preferred a more type specific function, but yeah, as long as
the types for which the function would normally be used are special cased early
enough in the implementation, it makes no big difference.
Fine with me, too
Stefan Behnel added the comment:
I'm happy to see this moving forward.
Not convinved of the "PyIter_Send()" name, though. I don't consider this part
of the iterator protocol. It's specific to generators and coroutines. Cython
would probably guard its usage by "P
Stefan Behnel added the comment:
Copying some of the design discussion from the PR here
(https://github.com/python/cpython/pull/22196/files#r486730457), because it
belongs into the ticket.
Yury Selivanov proposed to add a new C-API function for this (naming changes by
me):
typedef
Stefan Behnel added the comment:
Big +1 from me, too, for the same reasons Yury gave.
--
nosy: +scoder
___
Python tracker
<https://bugs.python.org/issue41
Change by Stefan Behnel :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue20198>
___
___
Stefan Behnel added the comment:
Changing subject to make it clear what this ticket is really about.
--
title: Pure-Python ElementTree classes no longer available since 3.3 -> Allow
more low-level parser configuration in ElementTree
versions: +Python 3.10 -Python 3.3, Python
1 - 100 of 1270 matches
Mail list logo
