Stefan Krah added the comment:
New changeset d73a960c575207539c3f9765cff26d4fff400b45 by Stefan Krah in branch
'master':
bpo-30923: Disable warning that has been part of -Wextra since gcc-7.0. (#3142)
https://github.com/python/cpython/commit/d73a960c575207539c3f9765cff26d4fff400b45
Changes by Stefan Krah <ste...@bytereef.org>:
--
pull_requests: +3177
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30923>
___
_
Stefan Krah added the comment:
So I installed gcc-7.2.0 from source. Hilariously compiling gcc *itself*
emits fallthrough warnings!
Then I tried to be a good open source drone and add 20 /* fall through */
comments to libmpdec.
gcc is too stupid to recognize the /* fall through
Changes by Stefan Krah <ste...@bytereef.org>:
--
pull_requests: +3166
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30923>
___
_
Stefan Krah added the comment:
Thanks. I tried to revert it, but got:
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/master.
remote: error: 2 of 2 required status checks are expected.
To https
Stefan Krah added the comment:
Yes, please add libmpdec to the ignored files.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Thank you for your expertise.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Stefan Krah added the comment:
Look at Include/longobject.h and
https://docs.python.org/3/library/stdtypes.html?highlight=bit_length#int.bit_length
.
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
I think the fall-through blog notes are slightly overstated. :-)
"The switch fallthrough has been widely considered a design defect in C."
It's an important feature.
--
___
Python tracker <rep...@bu
Stefan Krah added the comment:
We can check for the version, but all versions of gcc that I tested
accept and ignore -Wno-implicit-fallthrough, even though they don't
actually have -Wimplicit-fallthrough.
Of course they choke on -Wimplicit-fallthrough=0
Stefan Krah added the comment:
Well, it's not a bug, but perhaps it is annoying for users of this gcc version
if they compile 3.6 often.
Actually, I think gcc should not include this warning in -Wextra. It's
something that could be run manually before a release.
I'd vote for making -Wno
Stefan Krah added the comment:
Stéphane, if you want the libmpdec change cherry picked and are willing to do
the (significant) work of backporting, I'll merge it.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Hmm, that took about 20 min to commit a 3 line diff. Now I'm watching the
buildbots...
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
New changeset 72b543308ee3087e3fa247981f5cb4be1138c515 by Stefan Krah in branch
'master':
bpo-30923: Suppress fall-through warnings in libmpdec. (#2698)
https://github.com/python/cpython/commit/72b543308ee3087e3fa247981f5cb4be1138c515
Changes by Stefan Krah <ste...@bytereef.org>:
--
pull_requests: +2764
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30923>
___
_
Stefan Krah added the comment:
It's a useful warning, but I find it annoying to add 20 "fall through"
comments. I may add a pragma at some point.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
Changes by Stefan Krah <ste...@bytereef.org>:
--
nosy: +lemburg
priority: normal -> low
type: -> enhancement
versions: +Python 3.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Stefan Krah added the comment:
I think I'll wait until #29464 is committed and the API is considered frozen
(see msg295176?).
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
icc on Linux has always worked exactly as gcc, except that -fp-model=strict
needs to be specified.
I can't test on Windows -- I don't seem to get MSVC licences any more.
--
___
Python tracker <rep...@bugs.python.
Stefan Krah added the comment:
Okay thanks, it's good to hear what others think about the docs.
> So I have no clue why "y#" is refusing such an object.
"y#" is refusing memoryview(bytes) because "y#" only allows objects without a
releasebufferproc and memo
Stefan Krah added the comment:
Out of curiosity:
Is the 3.2 documentation clearer?
https://docs.python.org/3.2/c-api/arg.html#strings-and-buffers
Lately we have a lot of churn in the docs, not necessarily written by subject
experts
Stefan Krah added the comment:
To expand on what Mark said: If the proposed format code implicitly
gives these results ...
>>> format(12 % 2**8, '08b')
'1100'
>>> format(-12 % 2**8, '08b')
'0100'
..., would students not expect that these two operations ha
Stefan Krah added the comment:
For third party projects who want to use FASTCALL the functions are not
generated by AC. I didn't understand the reasoning why the consistency
argument is weak.
--
___
Python tracker <rep...@bugs.python.org>
Stefan Krah added the comment:
> I'd like to use METH_FASTCALL in Cython in a future-proof way.
Also +1. Can we consider the API frozen after this issue or do we have to wait
for #29465 (or others)?
--
___
Python tracker <rep...@bugs.pyth
Stefan Krah added the comment:
Sorry, actually I wasn't totally clear: The exporting object just needs a
getbufferproc() that can respond to buffer requests and keeps track of how many
views are exported.
"View in the object" is misleading and not necessary; it can be used for some
Stefan Krah added the comment:
"Py_buffer view" needs to go into the exporting object. That object needs a
getbufferproc(). That getbufferproc() can use PyBuffer_FillInfo() to fill in
the view that is now kept alive because it's in the object.
The object then supports the buffe
Stefan Krah added the comment:
"Py_buffer view" is stack allocated. One can use memoryviews based on such
buffers *inside* a function, but not return them.
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<htt
Stefan Krah added the comment:
I guess since it's documented, it would be ok to change for 3.7. BTW, we also
allow "static inline" now in headers, so perhaps we could make it a function.
--
nosy: +skrah
___
Python tracker <rep...@bu
Changes by Stefan Krah <ste...@bytereef.org>:
--
nosy: -skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30221>
___
__
Stefan Krah added the comment:
> Do these books have any use cases for assertNotAlmostEqual() or just
> enumerate the list of TestCase methods?
I think this should be researched by the proponent of the change.
--
___
Python tracke
Stefan Krah added the comment:
There are 100 results in Google books alone. Are the books wrong (honest
question, I did not check)?
They will be wrong if we remove it. ;)
I agree with Michael that assertNotAlmostEqual() doesn't hurt.
--
nosy: +skrah
Stefan Krah added the comment:
I'm with Nathaniel here: The fixed-bug is probably too obscure to warrant ABI
breakage.
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Stefan Krah <ste...@bytereef.org>:
--
nosy: -skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28769>
___
__
Stefan Krah added the comment:
I thought splitting off abc was done for performance reasons (reduce the number
of imports at Python startup), not for more idiomatic code.
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
Stefan Krah added the comment:
Ok great, maybe I'll take a look.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30055>
___
___
Stefan Krah added the comment:
Thanks, looks good. (I hope GitHub runs the doctests at Travis CI, locally
most of them failed so I didn't bother to run the tests for this one.)
--
assignee: docs@python -> skrah
resolution: -> fixed
stage: -> resolved
status: open
Stefan Krah added the comment:
New changeset 2c0b5c664ba7d36dc09788d3778d5b33e3fa1bd0 by Stefan Krah (Marco
Buttu) in branch 'master':
bpo-30055: add testcleanup to leave a fresh context (#1094)
https://github.com/python/cpython/commit/2c0b5c664ba7d36dc09788d3778d5b33e3fa1bd0
Stefan Krah added the comment:
Merged, thank you.
--
assignee: -> skrah
nosy: +skrah
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Stefan Krah added the comment:
Does anyone know how to disable the spurious pull requests that keep coming in?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Stefan Krah <ste...@bytereef.org>:
--
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24622>
___
_
Stefan Krah added the comment:
Thanks for the PR! -- Merged.
--
assignee: -> skrah
components: +Library (Lib)
resolution: -> fixed
stage: patch review -> resolved
versions: +Python 3.7
___
Python tracker <rep...@bugs.pytho
Stefan Krah added the comment:
Not right now, but if anyone makes a PR I can click the merge button. :)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
For '%b', it looks like the PEP supports it. I didn't follow the PEP
discussions, I think Ethan will know more.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
It's okay to reopen if some conditions have changed (which is the case here).
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
On Mon, Feb 13, 2017 at 03:04:09PM +, Chi Hsuan Yen wrote:
>
> Chi Hsuan Yen added the comment:
>
> I have used my old patch several days on Android, and it seems quite fine.
> Anyway that's not important anymore.
I find that very surprisin
Changes by Stefan Krah <ste...@bytereef.org>:
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Stefan Krah added the comment:
It's not a matter of *necessary*, you simply cannot use argparse in setup.py.
Try to build with your patch and you'll see.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
I get the the same output, perhaps I misunderstand something here:
>>> from _decimal import *
>>> class X(Decimal):
... def __init__(self, a):
... print('__init__:', a)
...
>>> X.from_float(42.5)
__init__: 42.5
Decim
Changes by Stefan Krah <ste...@bytereef.org>:
--
nosy: +mark.dickinson, rhettinger, skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Stefan Krah added the comment:
Adding Stefan Behnel, perhaps Cython doesn't need backwards compatibility.
--
nosy: +scoder, skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
If the API can still change (msg287083), I think I'll wait with this until
shortly before 3.7 beta.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Perhaps test_decimal should fail for CPython if _decimal can't be imported.
All compilers that I tested seem to link fine without -lm in this case.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Stefan Krah added the comment:
I didn't look at this one, but some "hacks" are necessary in setup.py (example:
usage of os.system() in some places).
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
Changes by Stefan Krah <ste...@bytereef.org>:
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
versions: +Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bu
Stefan Krah added the comment:
Thanks. Strange that on other systems the compilers don't complain (usually
they do).
--
assignee: -> skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
Stefan Krah added the comment:
I agree it's too late to change 2.7, and 3.x cannot (and should not) be changed
at this stage.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
PyBUF_SIMPLE implies C-contiguous for a conforming buffer provider.
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
> STINNER Victor added the comment:
> > AC will not happen: It makes the module too large and unreadable.
>
> Ah you dislike the additional [clinic input] sections?
Yes, they tear apart the code. I stopped reading many C files because
of this.
Stefan Krah added the comment:
I'll take a look when I have the opportunity.
AC will not happen: It makes the module too large and unreadable.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
For _decimal I'm happy with just the cast from the first patch -- you have a
one line diff and it's easy to see the focus of the issue.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
On Mon, Jan 09, 2017 at 08:21:17AM +, Serhiy Storchaka wrote:
> In the particular case of getround() in _decimal.c, seems the worst case is
> raising TypeError instead of MemoryError in pretty rare circumstances. This
> is not critically bad, there
Stefan Krah added the comment:
For the record: This is all that happened in decimal if a) you
pass a legacy string and b) force _PyUnicode_Ready() to throw
a MemoryError:
>>> from decimal import *
>>> import _testcapi
>>> context = Context()
>>> traps = _t
Stefan Krah added the comment:
I'm generally a little concerned about the way "bugs" are presented here
recently:
In #28701 you write:
'Correctness. Since no caller checks the error of
PyUnicode_CompareWithASCIIString(), it is incorrectly interpreted as "less
then".'
T
Stefan Krah added the comment:
To expand a little, you use the terminology "possible bugs". All I can
see is a double exception if PyUnicode_Compare() returns -1.
I think I did it on purpose because this function is speed sensitive and
no user will change a valid rounding mode
Stefan Krah added the comment:
Also, if anyone changes the rounding-mode constants it is really their problem.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Quite honestly I prefer to do nothing. What is the worst that can happen?
A SystemError?
Not-ready unicode strings are an application bug.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Changes by Stefan Krah <ste...@bytereef.org>:
--
assignee: -> skrah
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http:/
Stefan Krah added the comment:
The patch seems to fix it. $module was a thing at some point, I don't know
whether the semantics changed or if it was wrong in the first place.
--
keywords: +patch
Added file: http://bugs.python.org/file46089/issue29111.diff
Stefan Krah added the comment:
Signature and docstring can be done manually with very little effort.
Currently METH_FASTCALL is AC only, but I hope that will change.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Julien, the syntax converters look pretty clever. Do we need AC
everywhere though? I wonder (once again) if this is really more
readable than the existing code.
--
nosy: +skrah
___
Python tracker <
Stefan Krah added the comment:
I guess the FreeBSD people are happy with the solution.
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Stefan Krah added the comment:
There are a couple of problems with using Argument Clinic for third
party projects.
First, it makes no stability promises:
"Currently Argument Clinic is considered internal-only for CPython. ..."
Then, for large projects that already use some gene
New submission from Stefan Krah:
It looks like METH_FASTCALL gives nice speedups (#28754).
Is this an internal interface or can it be documented like
METH_KEYWORDS etc.?
--
assignee: docs@python
components: Documentation
messages: 281766
nosy: docs@python, haypo, serhiy.storchaka
Changes by Stefan Krah <ste...@bytereef.org>:
--
keywords: -easy, patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27779>
___
Changes by Stefan Krah <ste...@bytereef.org>:
--
keywords: +patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27779>
___
__
Stefan Krah added the comment:
Okay great. I think it's probably best to produce an initial patch with the
verbatim Python docstrings (you can of course address the comments that I
already made), then we mark the passages that are clearly not valid for
_decimal or outdated for _pydecimal
Stefan Krah added the comment:
Lisa, thanks for the patch. I've left some comments -- some docstrings in the
Python version are outdated, some not quite correct, some are not very clear
(to me).
I don't know how to proceed. Initially I thought it would be as easy as just
taking over all
Stefan Krah added the comment:
Raymond: "code area" meant literally that -- all code under Modules/_decimal/*
is by myself.
It is well understood that you and many people (e.g. Mark Dickinson)
have a stake in Decimal. This however does not warrant reassigning
an issue in which I h
Stefan Krah added the comment:
On 64-bit Linux there's no difference:
$ ./usr/bin/gcc -O3 -o issue28397-2 issue28397-2.c
$ time ./issue28397-2 0
real0m2.486s
user0m2.424s
sys 0m0.014s
$ time ./issue28397-2 1
real0m2.433s
user0m2.422s
sys 0m0.008s
Also, most
Stefan Krah added the comment:
That matches my results as well:
-O2 gives about the same speed, with -O3 doit() has a huge advantage.
I'm not sure this is an optimization at all.
--
___
Python tracker <rep...@bugs.python.org>
Stefan Krah added the comment:
Which version is faster in your tests?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28397>
___
__
Stefan Krah added the comment:
The difference in favor of doit() is even more pronounced with this
loop (also sorry for the uninitialized variable, but that does not
make a difference for benchmarking):
=
for (i = 0; i < 1; i++) {
for (j = 0
Stefan Krah added the comment:
In the following program, with gcc-5.3 doit() is significantly faster than
doit2() in 64-bit Linux:
#include
int
doit(int64_t index, int64_t nitems)
{
return index < 0 || index >=
Stefan Krah added the comment:
The same applies to memoryview.c and _testbuffer.c -- I doubt that there's any
measurable speed benefit and the clarity is reduced (I also don't want macros
there).
--
___
Python tracker <rep...@bugs.python.org>
Stefan Krah added the comment:
Serhiy, could you please take out _decimal.c?
I thought we had been through that before. :) :) :)
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
I see. No, most NumPy arrays are C-contiguous. Multi-dimmensional arrays
are contiguous, too.
Non C-contiguous arrays arise mostly during slicing or if they're
Fortran-order to begin with.
But NumPy aside, it's weird to have slice of a huge regular bytes view
Stefan Krah added the comment:
I don't understand this. Could you explain?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
s/unaligned/not 8-byte-aligned/
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28055>
___
___
Pyth
Stefan Krah added the comment:
Numpy itself internally doesn't. Consumers of numpy arrays use
memoryviews. Numpy is often used as a library these days, even
for simple things like storing a 2-d table, which can easily be
several TB.
It is also easy to generate unaligned data by just taking
Stefan Krah added the comment:
Ah, yes. But compilers optimize memcpy and this is a guaranteed slowdown for
the unaligned memoryview case.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
For memoryview this is not possible: It is explicitly unaligned and the feature
is used in e.g. NumPy.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
FWIW, MSVC optimizes memcpy:
http://bugs.python.org/issue15993
The pgo issue has been fixed according to Steve Dower.
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Thanks, Christian!
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28120>
___
___
Python-bugs-list
Stefan Krah added the comment:
It fails in pytest and has a segfault. The pytest issue should probably
be separate issue (it could also be a blaze issue).
This is a minimal reproducer for the segfault:
=
from blaze.expr import symbol
Changes by Stefan Krah <ste...@bytereef.org>:
--
nosy: -skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28120>
___
__
Stefan Krah added the comment:
Victor, I'm beginning to resent your tone.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Sorry Victor, I have been reporting memory related issues for a long
time here. ;)
I'm already using Valgrind, why would I set PYTHONMALLOC=debug?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Stefan Krah added the comment:
I don't understand how the original issue is fixed if 1e7b636b6009
exhibits the SystemError and the very next revision 4a5b61b0d090
(the fix) segfaults. And the test suite works with the previous
dict.
Sure, it can be a third party issue, but this constellation
Stefan Krah added the comment:
It could still be a stack overflow, but on the surface it does
not look like one. It's definitely related to the aforementioned
revision:
==3442== Invalid read of size 8
==3442==at 0x49DBD8: _PyDict_Pop (dictobject.c:1743)
==3442==by 0x4A0BE2: dict_pop
Stefan Krah added the comment:
If Victor can't reply now (it's getting late in Europe), I'd just release.
Pretend that I set it to deferred blocker. :)
--
priority: release blocker -> deferred blocker
___
Python tracker <rep...@bugs.pyth
601 - 700 of 3373 matches
Mail list logo
