Change by Stefan Zabka :
--
keywords: +patch
pull_requests: +29872
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31760
___
Python tracker
<https://bugs.python.org/issu
New submission from Stefan Zabka :
The asyncio documentation claims that there is a class
[asyncio.Server](https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.Server).
However when looking in the sources I can only find
[asyncio.base_events.Server](https://github.com/python
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/cpyt
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
Change by Stefan Tatschner :
--
keywords: +patch
pull_requests: +29675
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31554
___
Python tracker
<https://bugs.python.org/issu
Stefan Tatschner added the comment:
Sorry, I mean memmem(3). :)
--
___
Python tracker
<https://bugs.python.org/issue46848>
___
___
Python-bugs-list mailin
New submission from Stefan Tatschner :
The mmap.find() in function uses a naive loop to search string matches. This
can be optimized “for free” by using libc's memmap(3) function instead.
The relevant file is Modules/mmapmodule.c, the relevant function is
mmap_gfind().
--
mes
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 to that.
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
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/is
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
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
New submission from Stefan Pochmann :
The signatures for the versions without "_right" suffix are missing the key
parameter:
bisect.bisect_right(a, x, lo=0, hi=len(a), *, key=None)
bisect.bisect(a, x, lo=0, hi=len(a))¶
bisect.insort_right(a, x, lo=0, hi=len(a), *, key=None)
bisect.i
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".
Change by Stefan Ecklebe :
--
type: crash -> behavior
___
Python tracker
<https://bugs.python.org/issue46535>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Stefan Ecklebe :
Consider a script called snippet.py, containing the lines
--
import numpy as np
import pandas as pd
np.finfo(float)
idx = pd.MultiIndex.from_tuples([(1, 2)])
np.finfo(float)
print("
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/l
Stefan Pochmann added the comment:
The error occurs when you do code.strip()[0] when code is " ", not "u2".
--
nosy: +Stefan Pochmann
___
Python tracker
<https://bug
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, in
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/e18d81569fa0564f3bc7bcfd2fce26
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 Pochmann added the comment:
Ok, thanks, had somewhat expected that, as the multimode proposal was rather
clearly better but the mode proposal not so much.
--
___
Python tracker
<https://bugs.python.org/issue45
New submission from Stefan Pochmann :
This test:
def test_counter_data(self):
# Test that a Counter is treated like any other iterable.
data = collections.Counter([1, 1, 1, 2])
# Since the keys of the counter are treated as data points, not the
# counts
Stefan Pochmann added the comment:
(somehow the benchmark script didn't get attached, trying again)
--
Added file: https://bugs.python.org/file50453/multimode_mode.py
___
Python tracker
<https://bugs.python.org/is
New submission from Stefan Pochmann :
The current implementation is:
def multimode(data):
counts = Counter(iter(data)).most_common()
maxcount, mode_items = next(groupby(counts, key=itemgetter(1)), (0, []))
return list(map(itemgetter(0), mode_items))
The most_common() does a
Stefan Pochmann added the comment:
Turns out for n=100_000, k=50_000, about 87% of my factors are 1, so they don't
even need to be turned into Python ints for multiplication, improving the
multiplication part to 3.05 ms. And a C++ version to produce the factors took
0.85 ms. Up
Stefan Pochmann added the comment:
And for Raymond's case 4), about running very long and not responding to
SIGINT, with n=1_000_000 and k=500_000:
150.91 seconds math.comb(n, k)
39.11 seconds factorial(n) // (factorial(k) * factorial(n-k))
0.40 seconds mycomb(n, k)
0.14 se
Stefan Pochmann added the comment:
I wrote a Python solution ("mycomb") that computes comb(100_000, 50_000)
faster, maybe of interest:
1510.4 ms math.comb(n, k)
460.8 ms factorial(n) // (factorial(k) * factorial(n-k))
27.5 ms mycomb(n, k)
6.7 ms *estimation* for mycomb
Stefan Pochmann added the comment:
Just saw that it's in copy.py's docstring as well:
"This version does not copy types like module, class, function, method,
nor stack trace, stack frame, nor file, socket, window, nor array, nor
any similar types."
https://github.com/pyth
New submission from Stefan Pochmann :
The doc https://docs.python.org/3/library/copy.html says:
"This module does not copy types like module, method, stack trace, stack frame,
file, socket, window, array, or any similar types."
But it does copy arrays just fine:
import cop
Stefan Pochmann added the comment:
> This is already faster in pure Python than list.sort() for cases like:
Seems to depend on the system, it's slower on my laptop but faster on GCE:
Python 3.10.0 on my laptop:
7.42 s lexisort
6.83 s sort
5.07 s groupsort
Python 3.9.2 o
Stefan Pochmann added the comment:
Yes, I'm more familiar with the issue in the context of strings or lists. Your
example of strings like "'x' * 10_000 + str(i)" looks like something I almost
certainly used before as counterexample to someone's time complexi
Stefan Pochmann added the comment:
> It's not surprising the 2nd positions are rarely equal _given_ that the
> universe has been reduced to the 100 tuples with the same first element.
Yes, exactly.
> In any case, I don't see the point to this exercise ;-)
Just to illust
Stefan Pochmann added the comment:
I see you mentioned that PyObject_RichCompareBool(..., Py_EQ) might be faster
for example because it checks identity. Why not do an identity check before the
ms->tuple_elem_compare calls? Too expensive and rarely successful?
> Extending the i
Stefan Pochmann added the comment:
Hmm. What do you think about using "<" inside the loop for the remaining tuple
elements as well? It's even less likely that both the first and the second
elements are equal.
When the second elements differ, this saves 0.5 PyObject_RichCom
Stefan Pochmann added the comment:
Ok, I agree, the change only possibly "breaks" expectations that were already
broken (including my naive sorted-vs-minmax).
Yes, I know sort itself only asks `<` (I've actually read most of its code and
all its documentation). That
Stefan Pochmann added the comment:
I misinterpreted you then, sorry. I guess also because Elliot shortly after
retrated from the approach, saying he "rewrote unsafe_tuple_compare to move the
less-than after the equality testing, to make sure it's 100% consistent".
I'd s
Stefan Pochmann added the comment:
> What justifies "shouldn't"?
I based that on your old comments. Looked like tuple comparison results in
sorting shouldn't differ from tuple comparison results elsewhere. I had
actually proposed this exact method in a comment u
Stefan Pochmann added the comment:
That's how Elliot did it in the original proposal:
https://bugs.python.org/issue28685
Back then you pointed out that "Else we can assume u[0] == v[0]" isn't true for
float('nan') values:
https://github.com/python/cpython/p
Stefan added the comment:
sorry it's resolved. it was a timezone issue:
In [2]: d0 = datet.datetime(2016,3,27,tzinfo=datet.timezone.utc)
In [3]: d1 = datet.datetime(2016,3,28,tzinfo=datet.timezone.utc)
In [4]: (d1-d0).total_seconds()/3600
Out[4]: 24.0
In [5]: (d1.timestamp()-d0.time
New submission from Stefan :
I noticed that there is a difference between intervals when computed from
timedeltas vs timestamps. Is this a bug? Thanks!
In [2]: import datetime as datet
In [3]: d0 = datet.datetime(2016,3,27)
In [4]: d1 = datet.datetime(2016,3,28)
In [5]: (d1-d0).total_seconds
Change by Stefan Pochmann :
--
type: -> enhancement
___
Python tracker
<https://bugs.python.org/issue45346>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Stefan Pochmann :
Python consistently says true/false, not truthy/falsy. But a few "truthy" have
crept in now:
https://github.com/python/cpython/search?q=truthy
- Two in Doc/reference/compound_stmts.rst
- One in Doc/library/ast.rst
- One in Lib/test/test_
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, be
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/is
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: 1
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: 1
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/debd80403721b00423680328d6adf1
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 int, f
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 this
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: +P
Change by Stefan Hölzl :
--
keywords: +patch
pull_requests: +25784
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/27236
___
Python tracker
<https://bugs.python.org/issu
New submission from Stefan Hölzl :
compile_files tries to escape non-printable characters in error messages by
using sys.stdout.encoding
https://github.com/python/cpython/blob/main/Lib/compileall.py#L256
when using contextlib.redirect_stdout to redirect stdout to io.StringIO as
explained in
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 da
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.pyt
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 1.0 p
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 for
the
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.
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
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
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
>>&
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/cpyt
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/cpyt
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 &quo
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 "opt
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 it was
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 som
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 way I
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_enu
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:
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
___
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: -&g
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 a
Stefan Mosoi added the comment:
I understand.
I was using to reload some classes that might have changed/added (updates and
stuff) without having to reload the hole project. There might be some other
ways (i found this, and didn't keep researching after).
The documentation didn
Stefan Mosoi added the comment:
Also
> without having a reference to module itself
reload() just gets the name of the module
try:
name = module.__spec__.name
except AttributeError:
name = module.__name__
and then
if sys.modules.get(name) is not module
So it mi
Stefan Mosoi added the comment:
The motivation behind my request is as follow:
I have a dynamic set class (i don't "know" it) and calling
__module__ for that class return a string, reload requires Module(and i don't
think __module__ will be changed to module). The oth
New submission from Stefan Mosoi :
Weird behaviour (maybe it's my opinion) in reload from importlib
if i do:
import importlib
import sys
import datetime
importlib.reload(datetime.timedelta.__module__)
I get
Typeerror: reload() argument must be a module
but if i do
import importlib
i
New submission from Stefan Tatschner :
Linux >= 5.10 gained a new SocketCAN module called ISOTP. This is an
implementation of ISO 15765-2 which is mainly used in vehicle CAN networks.
Expose the constants from linux/can/isotp.h in the socket module.
These constants are not entirely
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/97e8b1eaeaf3aa325c84ff2e13417c
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
1 - 100 of 4955 matches
Mail list logo
