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
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 often get unexpected results when a called function results in a change in a
variable because the function gets a pass by reference. For example, consider
this snippet of code that manipulates the first column of a 3x3 matrix that it
gets
stefan added the comment:
Thank you for your reply and the lucid explanation.
On Monday, May 20, 2019, 9:17:34 PM EDT, Josh Rosenberg
wrote:
Josh Rosenberg added the comment:
1. This is a bug tracker for bugs in the Python language spec and the CPython
interpreter, not a general
stefan added the comment:
Thank you for your reply and the lucid explanation.
On Monday, May 20, 2019, 9:15:42 PM EDT, Steven D'Aprano
wrote:
Steven D'Aprano added the comment:
Hi Stefan, and welcome.
This is not a help desk, you really should ask elsewhere for expla
Stefan added the comment:
I have exactly the same problem. Is there a thread-safe alternative to execute
subprocesses in threads?
--
nosy: +santoni
___
Python tracker
<http://bugs.python.org/issue1731
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
Change by Stefan Behnel :
--
nosy: +scoder
___
Python tracker
<https://bugs.python.org/issue45711>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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:
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
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:
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
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("
Change by Stefan Ecklebe :
--
type: crash -> behavior
___
Python tracker
<https://bugs.python.org/issue46535>
___
___
Python-bugs-list mailing list
Unsubscrib
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".
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:
> 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:
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:
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:
> 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:
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.
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 Tatschner added the comment:
Sorry, I mean memmem(3). :)
--
___
Python tracker
<https://bugs.python.org/issue46848>
___
___
Python-bugs-list mailin
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 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
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
Change by Stefan Behnel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Stefan Behnel :
--
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue46798>
___
___
Python-bugs-list mailing list
Unsubscrib
Stefan Krah added the comment:
I completely removed faulthandler from e91ad9669c08 and the problem
still occurs (with the same broken backtrace).
$ getconf GNU_LIBPTHREAD_VERSION
NPTL 2.7
It is a bit unsatisfying that the segfault isn't reproducible with
the earlier revision, but ther
Stefan Krah added the comment:
STINNER Victor wrote:
> > Traceback with faulthandler disabled: ...
>
> How did you disabled faulthandler?
That was a run with all faulthandler references removed from regrtest.py.
But as I said in my previous mail, I also did a run using e91a
New submission from Stefan Krah :
In one of the error branches PyLong_AsSize_t() returns (unsigned long)-1
instead of (size_t)-1.
--
components: Interpreter Core
files: pylong_as_size_t.diff
keywords: patch
messages: 143896
nosy: mark.dickinson, skrah
priority: normal
severity: normal
New submission from Stefan Krah :
I think the integer objects documentation could be clearer on a
couple of points:
- Despite being listed under "Concrete Objects Layer", some
functions implicitly accept anything with an __int__()
method. Currently only the PyL
Changes by Stefan Krah :
--
assignee: docs@python -> mark.dickinson
___
Python tracker
<http://bugs.python.org/issue12965>
___
___
Python-bugs-list mai
Stefan Krah added the comment:
> Yep, clearly a bug. Please fix!
Done, thanks for reviewing.
Victor, I don't think we need a unit test for this. I plan to go
over some modules with gcov in the future, and I'll include
longobject.c.
--
resolution: -> fixed
status
Stefan Krah added the comment:
I made the observation on Rietveld that the following code is never
executed by the test suite. The same applies to similar existing
passages in arraymodule.c:
http://bugs.python.org/review/1172711/diff/3310/10310#newcode394
Meador correctly pointed out that
Stefan Krah added the comment:
The failure was introduced by issue #12655. I attach a minimal script
to reproduce the segfault.
--
nosy: +benjamin.peterson
Added file: http://bugs.python.org/file23138/crash.py
___
Python tracker
<h
Stefan Krah added the comment:
And here's a full backtrace of crash.py:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x400225f0 (LWP 633)]
0x40011d20 in __tls_get_addr () from /lib/ld-linux.so.2
(gdb) bt
#0 0x40011d20 in __tls_get_addr () from /lib/ld-linux
Stefan Krah added the comment:
https://bugzilla.redhat.com/show_bug.cgi?id=726536 claims that the
glibc issue (which is relevant for skipping the test case) is fixed
in glibc-2.14.90-8.
I suspect the only way of running the test case reliably is whitelisting
a couple of known good glibc
Stefan Krah added the comment:
I wonder whether it is http://sources.redhat.com/bugzilla/show_bug.cgi?id=12453.
The demo script from there crashes both on debian-arm and Ubuntu Lucid,
but this specific segfault only occurs on debian arm.
Attached is a minimal C test case that only crashes on
Stefan Krah added the comment:
I think I got it: pthread_setaffinity_np() does not crash.
`man sched_setaffinity` is slightly ambiguous, but there is this remark:
(If you are using the POSIX threads API, then use pthread_setaffinity_np(3)
instead of sched_setaffinity().)
I&#
Stefan Krah added the comment:
Charles-François Natali wrote:
> Out of curiosity, I just looked at the source code, and it just does
> sched_setaffinity(thread->tid), so you can do the same with
> sched_setaffinity(syscall(SYS_gettid)) for the current thread.
sched_setaffi
Stefan Krah added the comment:
I think this is related to issue #11149. Can you try compiling with
-fwrapv?
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue12
Stefan Krah added the comment:
I can reproduce your results with a recent clang. gcc has similar
optimization behavior, but for gcc ./configure automatically adds
-fwrapv, which prevents the incorrect results.
I'm closing this as a duplicate of #11149.
--
resolution: -> d
Changes by Stefan Krah :
--
nosy: +a...@netbsd.org, skrah
___
Python tracker
<http://bugs.python.org/issue11149>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Recent clang and Python2.7 (without the patch):
Python 2.7.2+ (2.7:e8d8eb9e05fd, Sep 14 2011, 00:35:51)
[GCC 4.2.1 Compatible Clang 3.0 (trunk 139637)] on freebsd8
Type "help", "copyright", "credits" or "licen
Stefan Behnel added the comment:
I gave two reasons why this function can fail, and one turns out to be
assumed-to-be-dead code. So, no, there are two issues now, one with the
documentation, one with the code.
--
___
Python tracker
<h
Stefan Krah added the comment:
> Does the test suite catch this bug?
I think all of those fail due to the bug in pow():
20 tests failed:
test_array test_builtin test_bytes test_decimal test_float
test_fractions test_getargs2 test_index test_int test_itertools
test_list test_l
Stefan Krah added the comment:
The OS X buildbots fail to compile posixmodule.c:
gcc -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes-I. -I./Include
-DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function ‘try_getxattr’:
./Modules
Stefan Krah added the comment:
I'd prefer to disable the misbehaving functions entirely on arm.
With the patch this combination of tests now works:
./python -m test -uall test_posix test_nntplib
If you think the patch is good, I can run the whole test suite, too.
[I'd rathe
Stefan Krah added the comment:
No, that's me playing around. I tried to use clang as the compiler
for the build slave. I can't figure out yet why the segfaults occur.
When I'm running the test manually, everything seems to work.
--
___
Stefan Krah added the comment:
I'm completely puzzled by this. I ran *all* tests manually on the same
machine with clang with the same parameters as the buildbot
(--with-pydebug, make buildbottest) and they pass.
I reverted the buildbot to gcc, it'll be green again soon.
Closing
Stefan Krah added the comment:
== CPython 2.7.2+ (2.7:a698ad2741da+, Sep 15 2011, 00:17:28) [GCC 4.2.1
Compatible Clang 3.0 (trunk 139637)]
== FreeBSD-8.0-RELEASE-amd64-64bit-ELF little-endian
== /usr/home/stefan/pydev/cpython/build/test_python_71451
With clang 3.0 from trunk, the pow
Stefan Krah added the comment:
The buildbots are fine, though I think that in this instance
Gentoo-Non-Debug-3.x is the only bot that actually exercises
the new code path.
So I tested manually on FreeBSD/clang-3.0 and I don't see
anything surprising.
--
resolution: -> fix
New submission from Stefan Krah :
I'm not sure if this is a good idea: I wonder if it would be an option
to check for overflow behavior at the bottom of ./configure and print a
warning. The patch appears to work for gcc, clang and suncc. It would
have caught the problem in #12973.
The
Changes by Stefan Krah :
--
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue12985>
___
___
Python-bug
Changes by Stefan Krah :
Added file: http://bugs.python.org/file23164/listobject_overflow.diff
___
Python tracker
<http://bugs.python.org/issue12973>
___
___
Python-bug
Changes by Stefan Krah :
Added file: http://bugs.python.org/file23165/itertools_overflow.diff
___
Python tracker
<http://bugs.python.org/issue12973>
___
___
Python-bug
Stefan Krah added the comment:
With issue12975.diff, listobject_overflow.diff and itertools_overflow.diff
I don't get any more failures.
Also, of course issue12975.diff looks correct to me if we assume:
http://mail.python.org/pipermail/python-dev/2009-December/094392.html
http://yarchiv
Stefan Krah added the comment:
My rationale was something like this: If a compiler optimizes away signed
arithmetic overflow, this particular comparison will most likely be in
the set of optimizations, since it seems like low hanging fruit.
Of course it doesn't guarantee wrapping behavi
Stefan Krah added the comment:
Mark Dickinson wrote:
> Well, they're all in the standard, which is publicly available.
I have the real thing. :)
> The correctness of the patch depends on:
> (2) an assumption that the C implementation will never raise an
> 'implemen
Stefan Krah added the comment:
I just discovered that struct packs pointers from objects with an
__index__() method. Is that intentional?
>>> import struct
>>> class IDX(object):
... def __init__(self, value):
... self.value = value
... def __index__(self):
.
Stefan Krah added the comment:
> I am OK with applying the fix for this issue first.
I also think this should be committed first.
--
___
Python tracker
<http://bugs.python.org/issue1
Stefan Krah added the comment:
Mark Dickinson wrote:
> Yes, that's intentional. When use of __int__ was deprecated, a bug
> report popped up from someone who wanted to be able to have their own
> objects treated as integers for the purposes of struct.pack.
> (I don
Stefan Krah added the comment:
I think you may want to ask these questions on the Python mailing list:
http://mail.python.org/mailman/listinfo/python-list
This is the Python bug-tracker, and it's not obvious to me that
any of your points is a bug in Python.
--
nosy: +
Stefan Krah added the comment:
1) I cannot reproduce this.
2) ld is the linker and not the compiler.
3) and 4) Should definitely be asked on python-list.
--
resolution: -> works for me
stage: -> committed/rejected
status: open -&g
Stefan Krah added the comment:
Meador Inge wrote:
> The behavior around '__int__' in previous versions seems somewhat accidental.
I think struct followed the functions in longobject.c, which is not
really consistent with respect to duck typing. See also #12965 or
http://bu
Stefan Krah added the comment:
I cannot reproduce the crash on:
Linux debian-armel 2.6.32-5-versatile #1 Wed Jan 12 23:05:11 UTC 2011 armv5tejl
GNU/Linux
Since the old (arm) port is deprecated, I'm closing this.
--
resolution: -> wont fix
stage: test needed -> committ
Stefan Krah added the comment:
I can reproduce the leak with Python 2.5.4, but not with Python 2.6.5
or Python 3.2.
Python 2.5.4 is an ancient version. Please upgrade to Python 2.7
or Python 3.2. If the leak still exists, just respond to this issue
and it will be opened again automatically
New submission from Stefan Krah :
peephole.c: CONST_STACK_TOP(x) has an unused parameter.
--
components: Interpreter Core
files: peephole_unused_parameter.diff
keywords: patch
messages: 144189
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title
Changes by Stefan Krah :
Added file: http://bugs.python.org/file23185/4492afe05a07.diff
___
Python tracker
<http://bugs.python.org/issue10181>
___
___
Python-bugs-list m
Stefan Krah added the comment:
Revision 4492afe05a07 allows memoryview to handle objects with an
__index__() method. This is for compatibility with the struct module
(See also #8300).
--
___
Python tracker
<http://bugs.python.org/issue10
Stefan Krah added the comment:
The README looks outdated. This isn't surprising, since probably no one
here has access to the HP compiler.
If you want to improve it, please try this:
make distclean
./configure CC=cc CFLAGS="+DD64"
make test
I don't think the linker shou
Stefan Krah added the comment:
This doesn't look right to me: If (rdn != NULL) && (PyList_Size(rdn) > 0),
rdn is already decremented.
There is a leak though if (rdn != NULL) && (PyList_Size(rdn) == 0).
--
nosy: +skrah
_
Changes by Stefan Krah :
--
title: Resource is not released before returning from the functiion -> _ssl.c:
resource is not released before returning from the function
___
Python tracker
<http://bugs.python.org/issu
Changes by Stefan Ring :
--
nosy: +Ringding
___
Python tracker
<http://bugs.python.org/issue8271>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
> I think, it is a good idea to improve the Readme for this issue.
+1.
Wah Meng: Building everything is not enough, does 'make test'
complete successfully?
For gcc, Python2.7 relies on two critical options, -fno-strict-aliasing
and -fwrapv. Th
Changes by Stefan Krah :
--
title: Resource is not released before returning from the functiion ->
structseq.c: refleak
___
Python tracker
<http://bugs.python.org/issu
Changes by Stefan Krah :
--
title: Resource is not released before returning from the functiion ->
_ctypes.c: refleak
___
Python tracker
<http://bugs.python.org/issu
Changes by Stefan Krah :
--
title: Resource is not released before returning from the functiion ->
pyexpat.c: refleak
___
Python tracker
<http://bugs.python.org/issu
Changes by Stefan Krah :
--
title: Resource is not released before returning from the functiion ->
dictobject.c: refleak
___
Python tracker
<http://bugs.python.org/issu
Changes by Stefan Krah :
--
components: +Extension Modules
stage: -> patch review
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Changes by Stefan Krah :
--
components: +Interpreter Core
stage: -> patch review
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Changes by Stefan Krah :
--
components: +Extension Modules
title: _ssl.c: resource is not released before returning from the function ->
_ssl.c: refleak
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Changes by Stefan Krah :
--
components: +Extension Modules
stage: -> patch review
title: Resource is not released before returning from the functiion ->
selectmodule.c: refleak
versions: +Python 3.3
___
Python tracker
<http://bugs.p
Changes by Stefan Krah :
--
components: +Extension Modules
stage: -> patch review
title: Resource is not released before returning from the functiion ->
_collectionsmodule.c: refleak
versions: +Python 3.3
___
Python tracker
<http://bugs.p
Changes by Stefan Krah :
--
title: bytearrayobject.c: Resource is not released before returning from the
functiion -> bytearrayobject.c: refleak
___
Python tracker
<http://bugs.python.org/issu
Stefan Krah added the comment:
Thanks for checking the patch! Closing this now.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Stefan Krah added the comment:
> However, the new binary is still not able to start a new thread from the
> thread module.
Traceback?
mach/cthreads.h is only relevant for Hurd, as far as I can see.
> configure:8572: cc +DD64 -I/home/r32813/local/include -o conftest -g
> -L
Stefan Krah added the comment:
> If the C accelerator for decimal gets decimal performance close to
> floats (which I doubt, because it has to do much more), it could be
> very useful for me. What is its estimated time to completion?
It is finished and awaiting review (See #7652). Th
Stefan Krah added the comment:
> BTW, what is the status of cdecimal?
I just wrote the same in another issue, but not everyone is subscribed
to that:
I think cdecimal is finished and production ready. The version in
http://hg.python.org/features/cdecimal#py3k-cdecimal
is the same as w
Stefan Krah added the comment:
> Possibly related to http://bugs.python.org/issue11149?
Maybe I missed it in the links you gave, but that is easily
settled by compiling with and without -fwrapv.
--
nosy: +skrah
___
Python tracker
&l
Stefan Krah added the comment:
To me this looks like stdio.h should be included as well. Could
you try the patch?
--
keywords: +patch
Added file: http://bugs.python.org/file23262/issue-13057.diff
___
Python tracker
<http://bugs.python.
Stefan Krah added the comment:
It's more a straight duplicate of #12973, but the underlying cause
(signed integer overflow) is the same. For people who are finding
this via a search engine: A lot of bugs have been fixed in #12973,
but even if the test suite passes without -fwrapv it is *
Stefan Krah added the comment:
Wah Meng: I think there are a couple of misconceptions that
need to be cleared up:
1) Georg's complaint was about the links to http://dyno.freescale.net/
in you posts.
2) This is not a support hotline but a *bug tracker*. Since
the bug in configur
Stefan Krah added the comment:
I think this is a duplicate of #12788.
--
nosy: +skrah
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> test_email fails with -R
___
Python tracker
<http://
New submission from Stefan Krah :
Got this failure on Debian lenny amd64:
[1/1] test_signal
test test_signal failed -- Traceback (most recent call last):
File "/home/stefan/cpython/Lib/test/test_signal.py", line 339, in test_pending
""", *signals)
File "
New submission from Stefan Krah :
I think a couple of leaks were introduced by the pep-393
changes (see the patch).
--
components: Interpreter Core
files: pep-393-leaks.diff
keywords: patch
messages: 144719
nosy: haypo, loewis, skrah
priority: normal
severity: normal
stage: patch review
Changes by Stefan Krah :
--
title: : memory leaks -> pep-393: memory leaks
___
Python tracker
<http://bugs.python.org/issue13085>
___
___
Python-bugs-list mai
1 - 100 of 4949 matches
Mail list logo
