Stefan Krah added the comment:
The motivation for this PR is "it would be convenient to have this function".
This is probably true, but generally I would not change 47 files at once.
Most of the locations are probably not performance sensitive.
--
no
Change by Stefan Krah :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Krah added the comment:
New changeset 3d03a35ba0f162a350898100efc95fdf392070a2 by Stefan Krah (Miss
Islington (bot)) in branch '3.8':
[3.8] bpo-37188: Fix a divide-by-zero in arrays of size-0 objects (#13911)
https://github.com/python/cpython/commit
Stefan Krah added the comment:
New changeset 48f190f79cd89f7ad4409b3c782e462368583309 by Stefan Krah (Eric
Wieser) in branch '2.7':
[2.7] bpo-37188: Fix a divide-by-zero in arrays of size-0 objects (#13906)
https://github.com/python/cpython/commit/48f190f79cd89f7ad4409b3c782e462368583309
Change by Stefan Krah :
--
stage: patch review -> backport needed
___
Python tracker
<https://bugs.python.org/issue37188>
___
___
Python-bugs-list mai
Stefan Krah added the comment:
Thanks for the fix!
3.7/3.8 are done, 2.7 still needs a manual backport.
--
versions: -Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue37
Stefan Krah added the comment:
New changeset 8f0bbbdcae73f275faff90cc4559f616f001 by Stefan Krah (Miss
Islington (bot)) in branch '3.7':
bpo-37188: Fix a divide-by-zero in arrays of size-0 objects (GH-13881) (#13882)
https://github.com/python/cpython/commit
Stefan Krah added the comment:
New changeset 0690c79c419b8d2bdfe7c5b6dca57b018f5a5a54 by Stefan Krah (Eric
Wieser) in branch 'master':
bpo-37188: Fix a divide-by-zero in arrays of size-0 objects (#13881)
https://github.com/python/cpython/commit/0690c79c419b8d2bdfe7c5b6dca57b018f5a5a54
Stefan Krah added the comment:
Yes, I'd try Debian first, then potential libc issues can also be eliminated in
a single experiment.
--
___
Python tracker
<https://bugs.python.org/issue37
Stefan Krah added the comment:
There are lots of ideas still. :)
As I said, on a Linux other than RedHat or Debian or such I'd first try
to blame the shipped Python, then the libc (I had a glibc memmove issue
once with similar inexplicable results).
Alpine Linux apparently uses musl
Stefan Krah added the comment:
Thank you for the detailed report. So, in an attempt to summarize,
this is the crucial passage:
>>> ideal_exp = -1
>>> exp = -29
>>> coeff = 15
>>> division_counter = 0
>>> while exp &
Change by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<https://bugs.python.org/issue36839>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
There's no point discussing unless people develop reading skills.
--
___
Python tracker
<https://bugs.python.org/issue36
Stefan Krah added the comment:
720MB <= "3-4 dozen" * 20 MB <= 960MB. Per server.
It has all been said. :-)
I don't understand the objections about alignment. malloc() and obmalloc()
are at least 8-byte aligned, mmap() with NULL as the first parameter
Stefan Krah added the comment:
On Sun, Jun 02, 2019 at 02:38:21AM +, Inada Naoki wrote:
> What instance means? code object? co_code?
> Anyway, Dino didn't propose such thing. He only proposed accepting buffer
> object for code constructor.
> He didn't describe how to use b
Stefan Krah added the comment:
The managed buffer can be shared:
>>> b = b'12345'
>>> m1 = memoryview(b)
>>> m2 = memoryview(m1)
>>> gc.get_referents(m1)[0]
>>> gc.get_referents(m2)[0]
And I understood that Dino proposed to share one co
Stefan Krah added the comment:
Also, thank you for lecturing a core dev again.
--
nosy: +skrah
___
Python tracker
<https://bugs.python.org/issue36970>
___
___
Stefan Krah added the comment:
Only people with very much time on their hands have the luxury to discuss
changes like this on python-dev.
--
___
Python tracker
<https://bugs.python.org/issue36
Change by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<https://bugs.python.org/issue36970>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<https://bugs.python.org/issue36970>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
It is one thing to name something __vectorcall, and quite another to mix camel
and normal case.
When I'm scanning the code very quickly, I initially parse
_PyObject_VectorcallDict as PyObject_VectorallDict or_PyObject_Vector_callDict.
>From the perspect
Stefan Krah added the comment:
> You think that "_PyObject_FastCallDict" is easier to read than
> "_PyObject_VectorcallDict"? I don't think that there is much difference.
Marvellous. How much do you work with the C-API?
--
Stefan Krah added the comment:
Sorry for the bikeshedding here, but I'll read those function names a
lot. Is it possible to rename Vectorcall, which looks good on its own
but not inside _PyObject_VectorcallDict()?
_PyObject_FastCallDict is much easier to read.
Has the PEP been accepted
Stefan Krah added the comment:
+16% for float seems pretty high though.
--
___
Python tracker
<https://bugs.python.org/issue27987>
___
___
Python-bugs-list m
Stefan Krah added the comment:
Since Terry added me: Yes, this is clearly a bug, but it is a ctypes issue and
not a memoryview issue.
ctypes issues unfortunately tend to take some time until someone reviews.
--
___
Python tracker
<ht
Change by Stefan Krah :
--
nosy: +Eric.Wieser
___
Python tracker
<https://bugs.python.org/issue26746>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
I agree that it is a ctypes issue, itemsize should be equal to
struct.calcsize(fmt), which is never 0 for normal PEP-3118 types like the one
in the example.
[Pedantically, I think that the grammar would allow for an empty record "T{}"
that
Stefan Krah added the comment:
Yes, I'd think the decisions are deliberate.
Floats follow printf(), this is from the manual for 'e':
"The exponent always contains at least two digits; if the value is zero, the
exponent is 00."
And decimal follows the specificatio
Stefan Krah added the comment:
gcc warns with -pedantic:
ptr.c: In function ‘main’:
ptr.c:5:13: warning: format ‘%p’ expects argument of type ‘void *’, but
argument 2 has type ‘int *’ [-Wformat=]
printf ("%p", );
It is pedantic indeed, I wonder if machines with different poi
Stefan Krah added the comment:
It looks like 3.6 is in security-fix only mode, so it cannot be backported
there.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7 -Python 3.6
___
Pytho
Stefan Krah added the comment:
New changeset cdd8d4d6dd57f4c9429566706009d4613277d391 by Stefan Krah (Miss
Islington (bot)) in branch '3.7':
bpo-36370: Check for PyErr_Occurred() after PyImport_GetModule() (GH-12504)
https://github.com/python/cpython/commit
Stefan Krah added the comment:
New changeset 027b09c5a13aac9e14a3b43bb385298d549c3833 by Stefan Krah in branch
'master':
bpo-36370: Check for PyErr_Occurred() after PyImport_GetModule() (GH-12504)
https://github.com/python/cpython/commit/027b09c5a13aac9e14a3b43bb385298d549c3833
Change by Stefan Krah :
--
keywords: +patch
pull_requests: +12454
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
The funny thing is that array() already knows this:
>>> import array
>>> a = array.array("u", "123")
>>> memoryview(a).format
'w'
--
___
Pyth
Stefan Krah added the comment:
array() uses struct module characters except for 'u'. PEP-3118 was
supposed to be implemented in the struct module.
If array() continues to use 'u', the only sensible thing would be
to remove (or rename) 'a', 'u' and 'w' from PEP-3118
Stefan Krah added the comment:
Just to demonstrate what the format would look like, this is working
for an array of fixed bytes:
>>> x = xnd([b"123", b"23456"], dtype="fixed_bytes(size=10)")
>>> memoryview(x).format
'10s'
So the formats
Stefan Krah added the comment:
I think the problem is still whether to use 'u' == UCS2 and 'w' == UCS4 like in
PEP-3118.
For the project I'm currently working on I'd need these for buffer exports:
>>> from xnd import *
>>> x = xnd(["abc", "xyz"], dt
Change by Stefan Krah :
--
stage: -> needs patch
___
Python tracker
<https://bugs.python.org/issue36379>
___
___
Python-bugs-list mailing list
Unsubscrib
Stefan Krah added the comment:
Ok, got it. I think __ipow__ should be a ternaryfunc, like so:
diff --git a/Objects/typeobject.c b/Objects/typeobject.c
index 403f3caaee..914d076b5c 100644
--- a/Objects/typeobject.c
+++ b/Objects/typeobject.c
@@ -7032,7 +7032,7 @@ static slotdef slotdefs
Stefan Krah added the comment:
Like Josh I don't quite understand the problem description. This
for example works:
>>> class C(int):
... def __ipow__(self, other, mod=None):
... return pow(self, other, mod)
...
>>>
>>> x = C(10)
>>> x
10
>
Stefan Krah added the comment:
Actually I just see that this behavior of PyImport_GetModule() is documented:
"Return the already imported module with the given name. If the module has not
been imported yet then returns NULL but does not set an error. Returns NULL and
sets an
Change by Stefan Krah :
--
stage: -> needs patch
___
Python tracker
<https://bugs.python.org/issue36370>
___
___
Python-bugs-list mailing list
Unsubscrib
Stefan Krah added the comment:
The issue is that PyImport_GetModule() can legitimately NULL (not found)
but also NULL after an error occurred in PyDict_GetItemWithError().
So one (quick and dirty) approach that fixes this abort() is:
diff --git a/Python/import.c b/Python/import.c
index
Stefan Krah added the comment:
Whoops, I tested the wrong branch, getting a proper abort() now. :)
--
___
Python tracker
<https://bugs.python.org/issue36
Stefan Krah added the comment:
The tests pass here on Linux with 3.8 (cc60cdd9c4) and a very low
sys.setrecursionlimit(150).
The fail properly with RecursionError at sys.setrecursionlimit(125).
So I guess we'd need a gdb stack trace from OS X in case there's a CPython
issue that is OS X
Stefan Krah added the comment:
It can still be an issue in CPython, like in #14537.
--
___
Python tracker
<https://bugs.python.org/issue36370>
___
___
Python-bug
Stefan Krah added the comment:
This occurs when handling a recursion error uses more than 50 extra nested
function calls:
if (tstate->overflowed) {
if (tstate->recursion_depth > recursion_limit + 50) {
/* Overflowing while handling an overflow
Stefan Krah added the comment:
Thanks, but it is still not going to happen. Look at the increased code size
in e.g. blake2s_impl.c.h.
I want to know what is going on in the code. Also, the performance
improvements are in argument parsing, but not when you have numerical
code like a * b
Stefan Krah added the comment:
On the other hand, the docs say "insignificant trailing zeros are removed from
the significand", so technically it *is* correct, because trailing zeros are
significant in decimal.
--
___
Python track
Stefan Krah added the comment:
I just noticed that there are other differences, for example the "removal of
trailing zeros" passage does not apply to Decimal:
>>> format(Decimal("1.00e-6"), "g")
'0.0100'
Perhaps it would be easier to h
Stefan Krah added the comment:
Yes, these days PRs are the only way to get anything done. Before
GitHub it would have been possible to just commit the small diff
directly to master.
--
___
Python tracker
<https://bugs.python.org/issue23
Stefan Krah added the comment:
The patch LGTM, but I'm not sure if we need to document __format__().
Personally I probably wouldn't.
--
___
Python tracker
<https://bugs.python.org/issue23
Change by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<https://bugs.python.org/issue35813>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Stefan Krah :
--
assignee: -> skrah
___
Python tracker
<https://bugs.python.org/issue34778>
___
___
Python-bugs-list mailing list
Unsubscrib
Stefan Krah added the comment:
Eryk Sun:
Yes, the behavior is technically not guaranteed. I'm not sure about
memoryview(x, start, stop, step) but I'll keep it in mind.
Thomas Waldmann:
> do you think this is as good as it gets for this kind of code?
I guess so, there's a lot go
Stefan Krah added the comment:
New changeset d08ea70464cb8a1f86134dcb4a5c2eac1a02bf1a by Stefan Krah in branch
'master':
bpo-35845: Add order={'C', 'F', 'A'} parameter to memoryview.tobytes(). (#11730)
https://github.com/python/cpython/commit/d08ea70464cb8a1f86134dcb4a5c2eac1a02bf1a
Change by Stefan Krah :
--
assignee: docs@python -> skrah
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python
Stefan Krah added the comment:
New changeset a2f4c4023314f69333d2e8cee68e316619f3d68e by Stefan Krah (Miss
Islington (bot)) in branch '3.7':
bpo-26256: Document algorithm speed for the Decimal module. (GH-4808) (#11736)
https://github.com/python/cpython/commit
Stefan Krah added the comment:
New changeset 00e9c55d27aff3e445ab4c8629cf4d59f46ff945 by Stefan Krah (Cheryl
Sabella) in branch 'master':
bpo-26256: Document algorithm speed for the Decimal module. (#4808)
https://github.com/python/cpython/commit/00e9c55d27aff3e445ab4c8629cf4d59f46ff945
Stefan Krah added the comment:
It seems reasonable to support f-contiguous for cast() and tobytes().
For tobytes() it's implemented in the issue that Antoine linked to.
General support for strides in cast(), i.e. a zero-copy view for
non-contiguous arrays does not seem possible because
Stefan Krah added the comment:
Yes, following NumPy looks like the sanest option for tobytes(), so I
went ahead and implemented that signature.
memory.raw() is of course complicated by the fact that things like
m[::-1] move buf.ptr to the end of the buffer.
So we'd need to restrict
Change by Stefan Krah :
--
keywords: +patch
pull_requests: +11620
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Stefan Krah :
--
keywords: +patch, patch
pull_requests: +11620, 11621
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Stefan Krah :
--
keywords: +patch, patch, patch
pull_requests: +11620, 11621, 11622
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
CC Antoine and Nick.
I think we can do it, but we'd need cast(shape=[2,3], order='F')
to allow casting back.
The only practical objections are feature creep. To preserve
symmetry with tobytes(), we'd need to add tobytes('F') (and
tobytes('A')).
--
nosy
Stefan Krah added the comment:
raw_bytes() is also possible of course. I assume it would do nothing and just
dump the memory.
Or tobytes('F') AND tobytes('raw').
--
___
Python tracker
<https://bugs.python.org/issue35
Stefan Krah added the comment:
Yes, it's modeled after NumPy's tobytes():
>>> x = np.array(list(range(6)), dtype="int8").reshape(2,3)
>>> x.tobytes()
b'\x00\x01\x02\x03\x04\x05'
>>> x.T.tobytes()
b'\x00\x03\x01\x04\x02\x05'
>>>
>>>
Change by Stefan Krah :
--
assignee: -> skrah
___
Python tracker
<https://bugs.python.org/issue35752>
___
___
Python-bugs-list mailing list
Unsubscrib
Stefan Krah added the comment:
> For me, the main risk is to forget to remove the workaround once a new GCC
> version will be released (in N months).
This is why I suggested using the reproducer in configure.ac, setting something
like HAVE_GCC_MEMCPY_ROUNDING_BUG and then either a
Stefan Krah added the comment:
Or to put it differently, should we put a specific fix for a single
gcc version into memoryview.c? For all we know, a fix will be pushed
to Fedora 28 in the next 4 months.
--
___
Python tracker
<ht
Stefan Krah added the comment:
Our mails apparently crossed. :-)
--
___
Python tracker
<https://bugs.python.org/issue35752>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
Okay, so it's not a severe bug. That leaves us with the question
what to do about it. As I said above, other call sites could be
affected, too:
_struct.c:
static int
np_float(char *p, PyObject *v, const formatdef *f)
{
float x = (float)PyFloat_AsDouble(v
Stefan Krah added the comment:
If gcc-8.0.1-0.14.fc28.ppc64le miscompiles memcpy(), perhaps the upstream
priority in https://bugzilla.redhat.com/show_bug.cgi?id=1540995 should be
"release blocker".
CC David Edelsohn, whose PPC64 buildbot (presumably big endian) works.
-
Stefan Krah added the comment:
Does it also work with -fno-inline, just for ppc64? There are other
places in the sources where an inlined memcpy() could be miscompiled.
--
___
Python tracker
<https://bugs.python.org/issue35
Stefan Krah added the comment:
This is a performance sensitive function, so I prefer not to add
volatile. MSVC also had a bug with that function, but only in PGO
mode. Microsoft has fixed the issue long ago.
Do newer gcc versions have this issue?
I'm fine with wrapping the entire macro
Stefan Krah added the comment:
I mean issue reports like #33954 or #35195. These are just
two examples, and I'm NOT claiming that they are related.
But if functions like _PyUnicode_InsertThousandsGrouping()
*were* used in _decimal, I'd feel compelled to investigate.
Now I don't have to. I'd
Stefan Krah added the comment:
Also Marc-Andre does not consider this a bug in #31900. The
presentation of this issue is increasingly bizarre.
--
___
Python tracker
<https://bugs.python.org/issue35
Change by Stefan Krah :
--
title: decimal: formatter error if LC_NUMERIC uses a different encoding than
LC_CTYPE -> _decimal: Implement the previously rejected changes from #7442.
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
Don't you find it strange to close #7442 in mutual agreement and now
mention the word "bug" 50 times?
--
___
Python tracker
<https://bugs.python.o
Stefan Krah added the comment:
Since #7442 (again, *I* discovered this and it is *mentioned* in the
_decimal sources), there have been zero bug reports about decimal.
--
___
Python tracker
<https://bugs.python.org/issue35
Change by Stefan Krah :
--
assignee: -> skrah
nosy: +skrah
___
Python tracker
<https://bugs.python.org/issue35697>
___
___
Python-bugs-list mailing list
Un
Stefan Krah added the comment:
> Since it seems like we are still at the "idea" stage, would it make sense to
> add a function which accept options to choose how to format a number?
Maybe, but I think for format() Eric's latest proposal on python-ideas is great
("*f
Stefan Krah added the comment:
Or, obviously:
with open(fn, 'rb') as fd:
with mmap.mmap(fd.fileno(), 0, access=mmap.ACCESS_READ) as mm:
with memoryview(mm)[:2] as data:
print(data)
--
___
Python tracker
<ht
Stefan Krah added the comment:
s/on export/one export/
--
___
Python tracker
<https://bugs.python.org/issue35686>
___
___
Python-bugs-list mailing list
Unsub
Stefan Krah added the comment:
Well, the problem in b) is that data[:2] creates a new memoryview,
so the underlying ManagedBufferObject now has two exports:
- One from the context manager.
- The second from the slice.
So memoryview.__exit__() decrements on export, but the second one
Stefan Krah added the comment:
The behavior seems to be correct to me: If there are exports, the memoryview
cannot be released.
The application needs to ensure that release() is not called when
there are exports left.
--
___
Python tracker
Stefan Krah added the comment:
We use "crash" for segmentation fault, but this appears to be a regular
traceback that includes BufferError.
The BufferError message appears to be from mmapmodule.c.
--
title: memoryview contextmanager causing strange crash ->
Stefan Krah added the comment:
For reference, the (one of the?) other GitHub issue(s) is here:
https://github.com/python/cpython/pull/8612
It actually proposes to use LC_MONETARY.
--
___
Python tracker
<https://bugs.python.org/issue35
Stefan Krah added the comment:
I think there's another open GitHub issue for this, and yes, probably
it should be discussed on python-ideas, too.
My main concern with 'm' for libmpdec is that I'd like to reserve it
for LC_MONETARY. There was one OS X issue that would have been solved
Stefan Krah added the comment:
memoryview.cast() was originally meant to be a faster version of tobytes(),
which always converts to C-contiguous.
The 'shape' keyword was added because it is odd if you can cast from ND-C to
1D-Bytes but not back.
I'm not sure if we should introduce
Stefan Krah added the comment:
"--with-valgrind --with-pydebug" looks suspicious, it essentially
mixes two different memory checkers.
1) CFLAGS="-O0 -g" --without-pymalloc
2) CFLAGS="-O0 -g" --with-valgrind
should both work.
Can you try if this fixes the e
Stefan Krah added the comment:
The reason is that unfortunately readonly != immutable, as the
following example shows:
>>> import numpy as np
>>> x = np.array([1,2,3], dtype='B')
>>> y = x[:]
>>> y.flags['WRITEABLE'] = False
>>> m = memoryview(y
Stefan Krah added the comment:
I'll leave the issue up for a couple of days in case someone supports it, but I
think this one of the rare cases where all core devs would reject the feature
unanimously.
--
resolution: -> not a bug
status: open -> pending
type: -> en
Stefan Krah added the comment:
Sorry I meant the above example to use a dict, which currently
does not work:
>>> d = {m: "1"}
Traceback (most recent call last):
File "", line 1, in
TypeError: unhashable type: 'numpy.ndarray'
Then the feature would
Stefan Krah added the comment:
The feature would violate fundamental Python invariants. If you modify the
example above:
>>> t = (m,)
>>> b"\001\002\003" in t
True
>>> x[0] = 100
>>> b"\001\002\003" in t
False
This is simply never sup
Stefan Krah added the comment:
If the feature is for the Python test suite itself, one solution would be to
add -DPY_BOUNDS_CHECKS and use that on the buildbots.
I still think making all of the test suite Valgrind-ready (most of it is,
except test_multiprocessing and a few others) would
Stefan Krah added the comment:
Since this feature mainly helps when running a test suite using a debug build:
The same can be achieved by running the test suite under Valgrind, which
catches invalid accesses and a lot more.
So I'd prefer to keep the macro in its current form
Stefan Krah added the comment:
I'm using _GET_ITEM(args, 0), so Serhiy's concern is not theoretical.
I think if people want the safe version they should use PyTuple_GetItem().
--
nosy: +skrah
___
Python tracker
<https://bugs.python.org/issue35
Stefan Krah added the comment:
I just want to add one more voice for allowing the status quo:
C, OCaml, SML, Haskell allow the assignment, Ruby disallows it.
The ML family must allow it, since "let (x) = 10" is pattern matching
under the hood, and (10) = 10.
In C (gcc, clang a
Stefan Krah added the comment:
>>> mview.format
'B'
>>> mview[:] = array.array('B', b'hello')
Bytes have format 'B', so this works as expected.
--
assignee: -> skrah
nosy: +skrah
resolution: -> not a bug
stage: -> reso
301 - 400 of 3373 matches
Mail list logo
