Stefan Krah added the comment:
New changeset ca72589bfabe2fd0e12eebfeb770b6c7a499b3e6 by Stefan Krah in branch
'master':
bpo-31443: Formulate the type slot initialization rules in terms of C99. (#3688)
https://github.com/python/cpython/commit/ca72589bfabe2fd0e12eebfeb770b6
Changes by Stefan Krah :
--
pull_requests: +3681
___
Python tracker
<https://bugs.python.org/issue31443>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
New changeset b1558a0368949714f5765702a8d83a2d163eaacf by Stefan Krah in branch
'master':
bpo-31443: Update included code. (#3697)
https://github.com/python/cpython/commit/b1558a0368949714f5765702a8d83a
Changes by Stefan Krah :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7
___
Python tracker
<https://bugs.python.or
Stefan Krah added the comment:
The suppressions are mainly for "invalid access" due to a gc trick.
The primary goal is to be definitely-lost-clean.
I would say it works as expected.
--
nosy: +skrah
___
Python tracker
<https://bu
Stefan Krah added the comment:
Also, I don't think --with-pydebug works well with valgrind.
It's either:
1) --with-pydebug
2) CFLAGS="-O0 -g" --with-valgrind
3) CFLAGS="-O0 -g" --without-pymalloc
Combining 2) and 3) probably does not hurt, but is not nec
Stefan Behnel added the comment:
What exactly is the problem here? encoding='unicode' will never appear in the
XML declaration, and thus will never be "presented to XML processors". It is up
to the user to deal with encodings in this case, which I think is fine. It'
Stefan Behnel added the comment:
If this is really just about debugging, then I would suggest to not break
existing code at all.
--
nosy: +scoder
___
Python tracker
<https://bugs.python.org/issue35
Stefan Krah added the comment:
I'm using &PyTuple_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:
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
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
New submission from Stefan Seefeld :
On multiple occasions I have wanted to add documentation not only to Python
classes and functions, but also instance variables. This seems to involve (at
least) two orthogonal questions:
1) what is the proper syntax to associate documentation (docstrings
Stefan Seefeld added the comment:
Exactly ! I'm fully aware of the ubiquity of objects in Python, and it is for
that reason that I had naively expected `pydoc` to simply DoTheRightThing when
encountering an object containing a `__doc__` attribute. rather than only
working for type
Stefan Seefeld added the comment:
On 2018-12-09 18:35, Steven D'Aprano wrote:
> Steven D'Aprano added the comment:
>
>> Is there any discussion concerning what syntax might be used for
>> docstrings associated with objects ?
> I don't know about PyDoc in
Stefan Seefeld added the comment:
On 2018-12-09 19:48, Karthikeyan Singaravelan wrote:
> There was a related proposal in
> https://www.python.org/dev/peps/pep-0258/#attribute-docstrings
Right, but that was rejected (for unrelated reasons). The idea itself
was rejected by Guido
Stefan Seefeld added the comment:
ad 3) sorry, I picked a bad example - I didn't mean to suggest that immutable
objects should in fact become mutable by modifying their `__doc__` attribute.
ad 1) good, glad to hear that.
ad 2) fine. In fact, I'm not even proposing that pe
Stefan Behnel added the comment:
One regex related code pattern that I generally like is to assign bound methods
to good names and use those. In this case, I would write
_has_non_base16_digits = re.compile(b'[^0-9A-F]').search
...
if _has_non_base16_digits(s):
raise ...
-
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:
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 fea
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: -&g
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
>>&
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
New submission from Stefan Volz :
Hello, I'm currently writing my finals project using Python and needed a
feature that threading.Timer could nearly but not quite fulfill:
Execute a function after given time *with arguments provided and have the timer
resettable*.
So I did it mysel
New submission from Stefan Behnel :
Spelling out the numerator/denominator calculation in the __mod__ special
method, and actually implementing __divmod__, speeds up both operations by
2-3x. This is due to avoiding repeated Fraction instantiation and
normalisation, as well as less arithmetic
Change by Stefan Behnel :
--
keywords: +patch, patch
pull_requests: +10582, 10583
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Stefan Behnel :
--
keywords: +patch
pull_requests: +10582
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35588>
___
___
Py
Change by Stefan Behnel :
--
keywords: +patch, patch, patch
pull_requests: +10582, 10583, 10584
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Stefan Behnel :
--
nosy: +mark.dickinson, serhiy.storchaka
___
Python tracker
<https://bugs.python.org/issue35588>
___
___
Python-bugs-list mailin
Stefan Behnel added the comment:
Similarly, I think "//" (__floordiv__) should be implemented using integer
operations rather than math.floor():
(a.numerator * b.denominator) // (b.numerator * a.denominator)
Thoughts?
--
___
Pyth
Stefan Behnel added the comment:
Motivation for the latter:
$ ./python -m timeit -s 'from fractions import Fraction as F; a = F(-7, 3); b =
F(3, 2)' 'a // b'
10 loops, best of 5: 3.7 usec per loop
$ ./python -m timeit -s 'from fractions import Fraction as F;
Stefan Behnel added the comment:
Sure, I can add tests, but I wonder what kind of regression you expect. The
algorithm is still the same as before, it's just implemented more efficiently.
It does trade a bit of memory for the speed, though, since there is no longer
an interme
Stefan Behnel added the comment:
Thanks for your review and ideas, Serhiy. I added a couple of test cases, but
failed to find any case where the new implementation is not much faster.
I also tried "divmod(n_div, d_div)" for implementing __divmod__(), and the
results are
Stefan Behnel added the comment:
I agree with Antoine. After all, we are optimising a safety check here that
runs in linear time. If people want speed, they should consider methods that do
not do this check in the first place.
--
___
Python
Stefan Behnel added the comment:
I have no doubts that the code is right. However, your expectations might not
be.
Try to print the values inside of the loop, for each iteration, as well as
their type. You'll likely be surprised what that gives.
(In any case, this is not a bug. If you
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
Change by Stefan Seefeld :
--
nosy: +stefan
___
Python tracker
<https://bugs.python.org/issue35621>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Stefan Seefeld :
This is an addendum to issue35621:
To be able to call `asyncio.create_subprocess_exec()` from another thread, A
separate event loop needs to be created. To make the child watcher aware of
this new loop, I have to call `asyncio.get_child_watcher
Stefan Behnel added the comment:
Unlikely to get changed in Py3.4/5 anymore, since this is not even a bug fix. I
wouldn't even fight for backporting, although 3.7 seems ok for it.
I agree that this code duplication is worth removing. I don't consider hashing
the empty string
Stefan Behnel added the comment:
> why bytes and str generates the same hash value for ASCII sequence
Probably mostly for historical Py2 reasons. These days, both are somewhat
unlikely to appear in the same dict. But still, I'd advise against changing the
hash function without a v
Stefan Behnel added the comment:
> maybe this can be changed in Python 4.0
Well, if you find a *very* good reason for changing it, as I said. Py4 won't be
special in that regard, I suppose.
--
___
Python tracker
<https://bugs
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
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 Seefeld added the comment:
That's quite an unfortunate limitation ! I'm working on a GUI frontend to a
Python tool I wrote using asyncio, and the GUI (Qt-based) itself insists to run
its own event loop in the main thread.
I'm not sure how to work around this limita
Stefan Seefeld added the comment:
OK, so while I have been able to work around the issues (by using `quamash` to
bridge between `asyncio` and `Qt`), I'd still like to understand the rationale
behind the limitation that any subprocess-managing event-loop has to run in the
main threa
Stefan Seefeld added the comment:
> The limitation is a consequence of how Linux works.
> Unix has no cross-platform API for non-blocking waiting for child process
> finish except handling SIGCHILD signal.
Why does the `wait()` have to be non-blocking ? We can call it once in
re
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 -> Buf
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:
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
is
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:
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 track
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
(&qu
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 #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
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.pyt
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:
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
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'
Change by Stefan Behnel :
--
nosy: +scoder -scode
___
Python tracker
<https://bugs.python.org/issue35582>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
It might be worth inlining a fast path of "_PyArg_CheckPositional()" that only
tests "nargs < min || nargs > max" (even via a macro), and then branches to the
full error checking and reporting code only if that fails. Determining
Stefan Behnel added the comment:
Nice! Well done, Serhiy!
--
___
Python tracker
<https://bugs.python.org/issue35582>
___
___
Python-bugs-list mailing list
Unsub
Stefan Behnel added the comment:
This is not a bug, it's normal, documented behaviour. The children are not
guaranteed to be available during the "start" event. Only the tag itself is
guaranteed to be there. The guarantee that the subtree is complete is only
given for the &q
Change by Stefan Behnel :
--
title: XML.etree bug -> iterparse does not return the full subtree on "start"
events
type: performance -> behavior
___
Python tracker
<https://bugs.py
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:
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:
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:
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_AsDou
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:
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:
> 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) wr
Change by Stefan Krah :
--
assignee: -> skrah
___
Python tracker
<https://bugs.python.org/issue35752>
___
___
Python-bugs-list mailing list
Unsubscrib
Stefan Behnel added the comment:
It seems right that a heap allocate object owns a reference to its (non-static)
type. But the mere fact that you had to adapt stdlib code makes it obvious that
this will also break existing user code out there. And such breakage is very
likely to remain
New submission from Stefan Seefeld :
I'm working on a project that I'd like to split into multiple separately
installable components. The main component is a command-line tool without any
external dependencies. Another component is a GUI frontend that adds some
third-party de
Stefan Seefeld added the comment:
Yes. Depending on the answer to my question(s), the request either becomes:
"please add support for this use-case", or "this use-case isn't documented
properly", i.e. a feature request or
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
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://bug
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
t
Stefan Behnel added the comment:
I think the REPL could, when it formats a stack trace for printing, check every
referenced source file if it's newer than its compiled .pyc (bytecode) file,
and insert a warning into the stack trace if that is the case.
I don't see any use in doin
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
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
pull_requests: +11620
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
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 restri
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 be
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/00e9c55d27aff3e445ab4c8629cf4d
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/cpyt
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 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/
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
Change by Stefan Krah :
--
assignee: -> skrah
___
Python tracker
<https://bugs.python.org/issue34778>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<https://bugs.python.org/issue35813>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
The overhead of calling PyErr_Occurred() is definitely negligible in something
as involved as PyDict_GetItemStringWithError(), where a mere key lookup first
has to fire up the string decoder on a C character buffer to create a new
string object and then
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.o
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 Behnel added the comment:
Victor asked me for a review, so, well, what should I say? The intention seems
right, and the patch also looks good to me.
>From the top of my head, I wouldn't know any problems this would produce with
>Cython specifically, although it's wort
Stefan Behnel added the comment:
Adding Christian Tismer to the nosy list since he might be able to elaborate on
the impact on PySide (which IIRC uses the stable ABI, and thus, heap types).
--
components: +Extension Modules, Interpreter Core -Library (Lib)
nosy: +Christian.Tismer
Stefan Ring added the comment:
I was having the same problem, and I just found out what it was: Because of
-Wl,-rpath=..., this path gets baked into the binary, and LD_LIBRARY_PATH is
ignored. So if you have a previous build lying around there, it will mess up
the build.
--
nosy
Stefan Behnel added the comment:
>From Cython's point of view, the important fields in PyThreadState are the
>tracing/profiling and exception related ones. We're not using anything else.
>Users can explicitly opt out of the access to the exception fields by defining
Stefan Behnel added the comment:
Oh, and I forgot the new trashcan support. Cython will also start to use that
in its next release, so that adds the trashcan related attributes to the list.
https://github.com/cython/cython/pull/2842/files
Change by Stefan Behnel :
--
pull_requests: +11931
___
Python tracker
<https://bugs.python.org/issue35884>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Stefan Behnel :
--
keywords: +patch
pull_requests: +11932
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36012>
___
___
Py
Stefan Behnel added the comment:
It turns out that "update_slot()" is always called, even when we are not
updating a slot name (which is always a special dunder-name). The linear search
for names in "update_slots()" is a huge waste of time here, and
short-circuiting out
1701 - 1800 of 4951 matches
Mail list logo
