Stefan Krah added the comment:
I guess there's some version mixup here: From Python 3.3 on
the integrated C version of decimal does not store the digits
as a string and does not have the private _int method.
--
nosy: +skrah
___
Python tracker
Changes by Stefan Krah :
--
versions: -Python 3.5
___
Python tracker
<http://bugs.python.org/issue25928>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
On Wed, Dec 23, 2015 at 09:01:22PM +, John Walker wrote:
> Stefan, _int is a slot in Lib/_pydecimal.py. It should be defined on python
> 3.5 and tip, unsure about other versions.
>
> Python 3.5.1 (default, Dec 7 2015, 12:58:09)
> [GCC 5.2.0]
Stefan Krah added the comment:
No, the regular build uses the libmpdec that is shipped with
Python. The external libmpdec.so only comes into play if you
compile --with-system-libmpdec.
--
___
Python tracker
<http://bugs.python.org/issue25
Stefan Krah added the comment:
Let's re-target this issue:
Implementing as_integer_ratio() sounds reasonable, but let's hope
people won't try to convert Decimal('1E+99').
Mark, was there perhaps a reason not to add the method?
--
Stefan Krah added the comment:
The current issue description should have been fixed by #25827.
Is the segfault in test_re still happening?
--
___
Python tracker
<http://bugs.python.org/issue24
Changes by Stefan Krah :
--
title: ICC compiler: ICC treats denormal floating point numbers as 0.0 ->
Segfault in test_re.test_sre_character_class_literals() when Python is compiled
by ICC
___
Python tracker
<http://bugs.python.org/issu
New submission from Stefan Krah:
Zachary in #24999:
"If that's the case, would anyone (in particular, Steve, Tim or Tim) mind if we
just made the default (for MSVC as well as ICC) /fp:strict? It would be much
easier to just change the global default than to try to either make it se
Stefan Krah added the comment:
I see, thanks. I've opened #25934 to keep the issues separate.
--
___
Python tracker
<http://bugs.python.org/issue24999>
___
___
Stefan Krah added the comment:
What is the point of changing the return value of a function in
Objects/memoryobject.c to "const char *" and then casting it back
to "char *" in the one place that the function is used?
Churn like this has a direct cost for me: I have to u
Stefan Krah added the comment:
I was faced with the same dilemma when I wrote the code and I
*deliberately* decided that returning (const char *) + an
additional cast wasn't worth it for a static function
that's used only once.
--
___
Pyth
Stefan Krah added the comment:
Over at the llvm bug tracker this is marked as a release blocker:
https://llvm.org/bugs/show_bug.cgi?id=18164
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue20
Stefan Krah added the comment:
There's no need to revert it. Both versions are okay, but I wanted
to point out that these kinds of changes a) add a cognitive load for
other developers (I have to look what has changed in memoryobject.c)
and b) may override other developers' conscious
Stefan Krah added the comment:
Previously the method was rejected in #8947. But the
speedup is quite dramatic. This is a benchmark for
converting "1.91918261298362195e-100", 100 repetitions:
float.as_integer_ratio: 0.548023
Decimal.as_integer_ratio: normalize=False
Stefan Krah added the comment:
Keeping the API small is a good reason against it.
There aren't many ways to destructure a Decimal though: As far
as I know, the return value of as_tuple() dates back from the time
when the coefficient was actually a tuple. The function is slow
and not r
Stefan Krah added the comment:
Here's a patch. The Python and doc parts are from Mark (#8947).
I did not optimize the normalization yet, in C the code is
less clean and there were some corner cases where the gcd is
actually faster.
--
keywords: +patch
Added file: http://bugs.pytho
Stefan Krah added the comment:
Hopefully I wasn't moving too fast, but I won't have time in the next
days/weeks.
Serhiy and Alexander (#8947) would prefer more homogeneous error
messages and docstrings between float/pydecimal/cdecimal.
I wouldn't mind a patch in another iss
Stefan Krah added the comment:
Steven, could you have a look at the failures in test_statistics?
Some tests fail because they assume non-normalized fractions, I
still have to look at the other assumptions.
--
___
Python tracker
<h
Stefan Krah added the comment:
Ah yes, the test_statistics failures look like #18841 again.
--
___
Python tracker
<http://bugs.python.org/issue25928>
___
___
Pytho
New submission from Stefan Krah:
Not sure what is happening, but all Windows buildbots fail compile/clean.
--
messages: 257161
nosy: skrah, zach.ware
priority: normal
severity: normal
status: open
title: All Windows buildbots fail compile/clean
Stefan Krah added the comment:
Serhiy, could you take a look if it's related to
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/7107
?
This seems to be the first failure.
--
___
Python tracker
Changes by Stefan Krah :
--
nosy: +serhiy.storchaka
___
Python tracker
<http://bugs.python.org/issue25972>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Stefan Krah:
Here's a fix for the fallout from #25928. I've set it to
release blocker to make sure we don't forget.
--
assignee: steven.daprano
components: Library (Lib)
files: statistics_as_integer_ratio.diff
keywords: 3.5regression, patch
messag
Stefan Krah added the comment:
I've opened #25974 for the statistics.py issues.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.pyth
Stefan Krah added the comment:
Setting to blocker because I've disabled the offending tests.
--
nosy: +georg.brandl, larry, skrah
priority: high -> release blocker
___
Python tracker
<http://bugs.python.org
Stefan Krah added the comment:
No, I haven't done any benchmarks. In a quick test type(x) == float
does not seem any faster than isinstance(x, float), so perhaps we
could reduce the try/except complexity.
--
___
Python tracker
Changes by Stefan Krah :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue25975>
___
___
Stefan Krah added the comment:
The clear winner for float and Decimal is hasattr(x, 'as_integer_ratio').
The other types are a bit disadvantaged if the lookup fails, but they
go through additional try/excepts anyway.
--
___
Python trac
Stefan Krah added the comment:
Both versions are fine with me. The lowercase "cannot do ..." is more
pervasive in the source tree:
$ grep -R '"cannot' | wc -l
293
$ grep -R '"Cannot' | wc -l
150
If we change it, let's change all occurrences in _pyd
Stefan Krah added the comment:
>From my non-native speaker's point of view, I'd use lowercase if
the sentence doesn't end with a full stop, uppercase otherwise.
When I started here I was told that error messages in Python
usually don&
Stefan Krah added the comment:
Sorry for the bikeshedding, but I find this interesting:
Poly/ML (Cambridge), ghci (Glasgow) and OCaml (INRIA) appear to
use error messages without a full stop but starting in uppercase.
SML/NJ (Bell Labs) uses lowercase (and no full stop).
Perhaps this is a
Stefan Krah added the comment:
Serhiy: to me, the patch also looks good, we can certainly change
any error messages later.
Back to the bikeshedding:
Poly/ML:
> f;
Error-Value or constructor (f) has not been declared Found near f
Static errors (pass2)
ghci
Prelude> f
Stefan Krah added the comment:
Is this a political nosying?
--
___
Python tracker
<http://bugs.python.org/issue20008>
___
___
Python-bugs-list mailing list
Unsub
Stefan Krah added the comment:
As I said in msg254389, the read/write handling for non-blocking
sockets is far from trivial.
I'm not sure that this is a Python bug:
Looking at dugong/__init__.py, I don't think this implements the
recommendations in the OpenSSL book that I mentioned.
Stefan Krah added the comment:
https://books.google.com/books?id=IIqwAy4qEl0C&redir_esc=y , page 159 ff.
Modules/_ssl.c:_ssl__SSLSocket_write_impl() just raises
PySSLWantReadError etc. if the socket is non-blocking.
IOW, it's a thin wrapper around SSL_write().
So yes, I think yo
New submission from Stefan Seefeld:
I'm trying to use the distutil compiler to preprocess some header (to be used
with the cffi package).
The code is
compiler = distutils.ccompiler.new_compiler()
compiler.add_include_dir(join(sys.prefix, 'include'))
compiler.pr
Stefan Krah added the comment:
Could this be done soon? I ran into this just now:
Traceback (most recent call last):
File "", line 1, in
File
"/home/stefan/usr/lib/python3.6/site-packages/datashape-0.4.7-py3.6.egg/datashape/__init__.py",
line 7, in
from .user imp
Stefan Krah added the comment:
+1 for adding it to 3.5.2.
--
___
Python tracker
<http://bugs.python.org/issue25486>
___
___
Python-bugs-list mailing list
Unsub
Stefan Krah added the comment:
On Mon, Jan 11, 2016 at 08:17:11PM +, Yury Selivanov wrote:
> inspect.getargspec is back to Python 3.6 (it was never removed from <= 3.5,
> fwiw)
Yay! Thank you very much!
--
___
Python track
Stefan Behnel added the comment:
Thanks for calling me in. I can confirm that the stack trace in
https://paste.debian.net/361351/ points at a bug in Cython's own implementation
(not the code it generates). It's deep-copying objects that don't support it
(which doesn't nor
New submission from Stefan Krah:
http://speleotrove.com/decimal/daops.html#refpower
--
nosy: +skrah
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Stefan Behnel added the comment:
For reference, the bug in Cython is fixed here:
https://github.com/cython/cython/commit/ececb3e9473f6aaa65f29467921594c316ec2f06
--
___
Python tracker
<http://bugs.python.org/issue22
Stefan Behnel added the comment:
In fact, I did consider it and I'd love to, but it's not something to do
lightly because the semantics would be a bit fuzzy and unsafe. Basically,
extension types that have only Python object compatible attributes could
automatically pickle, but as s
Stefan Krah added the comment:
Could you explain warning #4232 in the case of libmpdec? I thought
all files are compiled and linked together. Why is the function
imported?
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue25
Stefan Krah added the comment:
Ah, thanks! I guess this Visual Studio behavior is not compatible
with the C-standard, but indeed there are no function pointer
comparisons in libmpdec.
--
___
Python tracker
<http://bugs.python.org/issue25
Stefan Krah added the comment:
I would expect linking to behave "as if" the abstract machine defined
by the standard were executing the code.
We already had one function pointer equality issue due to COMDAT folding,
so I agree that we should leave the
Changes by Stefan Krah :
--
nosy: skrah
priority: normal
severity: normal
status: open
title: Disable /W4 warning (non-standard dllimport behavior)
___
Python tracker
<http://bugs.python.org/issue26
New submission from Stefan Krah:
See: #25878
--
assignee: skrah
components: Extension Modules
messages: 258461
nosy: skrah
priority: normal
severity: normal
status: open
title: libmpdec: disable /W4 warning (non-standard dllimport behavior)
type: compile error
versions: Python 3.6
Changes by Stefan Krah :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
type: -> compile error
___
Python tracker
<http://bugs.python
Changes by Stefan Krah :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue26139>
___
Stefan Krah added the comment:
Pragma added for libmpdec in #26139.
--
___
Python tracker
<http://bugs.python.org/issue25878>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
This is *exactly* what I want. As the sole author of libmpdec I *know*
that the broken dllimport behavior cannot affect anything in memory.c,
since there are no function pointer comparisons.
Please stop educating us
Stefan Krah added the comment:
1) Feedback whether the compiler used on FreeBSD recognizes FENV_ACCESS.
2) If not, an indication why the man page mentions it.
--
___
Python tracker
<http://bugs.python.org/issue24
Stefan Krah added the comment:
Thanks, then the patch looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue24520>
___
___
Python-bugs-list mailin
Stefan Seefeld added the comment:
Hi, I'm investigating more issues related to test loading, and thus I have
discovered issue #16662.
I have found quite a number of inconsistencies and bugs in the loading of
tests. But without getting a sense of what the supposed behavior is I fi
Stefan Seefeld added the comment:
I believe what I actually want is for the discovery mechanism to be fully
implicit. It turns out that already *almost* works right now.
What doesn't work (and what this bug report really was about initially), is the
use of the 'discover' comma
Stefan Krah added the comment:
I agree, and that's pretty much what Guido said here, too:
https://mail.python.org/pipermail/python-dev/2001-February/012591.html
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
Yes, ideally the exceptions should be in sync. I don't find the list
of signals entirely uninteresting, but implementing it in _pydecimal
would require #8613 to be solved, which is unlikely to happen.
In _decimal the exceptions come directly from libmpdec,
Changes by Stefan Krah :
--
stage: -> needs patch
type: -> enhancement
versions: +Python 3.6
___
Python tracker
<http://bugs.python.org/issue26208>
___
___
Stefan Krah added the comment:
The spec was the only reasonable choice at the time decimal.py was
written. Incidentally, it is basically IEEE-754-2008 with arbitrary
precision extensions; this isn't surprising since Mike Cowlishaw was
on the IEEE committee and wrote the spec at the same
Stefan Krah added the comment:
Jurjen, this is very nice! -- Like Mark, I'm not sure if this should be in
CPython.
Decimal (Python >= 3.3) has sneaked in a couple of fast bignum
algorithms, so calculating and converting the latest Mersenne
prime takes a couple of seconds:
from decima
Stefan Krah added the comment:
On Wed, Feb 03, 2016 at 09:51:53AM +, STINNER Victor wrote:
> Well, nowhere means:
> https://docs.python.org/dev/whatsnew/3.3.html#decimal
Okay, but hardly anyone reads that, and I can't blame them. :)
For example, if I use something like Lua, I w
Stefan Krah added the comment:
In my experience it is very hard to get stable benchmark results with Python.
Even long running benchmarks on an empty machine vary:
wget http://www.bytereef.org/software/mpdecimal/benchmarks/telco.py
wget http://speleotrove.com/decimal/expon180-1e6b.zip
unzip
Stefan Krah added the comment:
I've cut off the highest result in the previous message:
Control totals:
Actual ['1004737.58', '57628.30', '25042.17']
Expected ['1004737.58', '57628.30', '25042.17&#x
Stefan Krah added the comment:
Core 1 fluctuates even more (My machine only has 2 cores):
$ taskset -c 1 ./python telco.py full
Control totals:
Actual ['1004737.58', '57628.30', '25042.17']
Expected ['1004737.58', '57628.30', '2
Stefan Krah added the comment:
> STINNER Victor added the comment:
> I modified Stefan's telco.py to remove all I/O from the hot code: the
> benchmark is now really CPU-bound. I also modified telco.py to run the
> benchmark 5 times. One run takes around 2.6 seconds.
>
Nic
New submission from Stefan Krah:
The telco benchmark is unstable. It needs some of Victor's changes from #26275
and probably a larger data set:
http://speleotrove.com/decimal/expon180-1e6b.zip is too big for
_pydecimal, but the one that is used is probably too small for
_de
Stefan Krah added the comment:
It's instructive to run ./python Modules/_decimal/tests/bench.py (Hit Ctrl-C
after the first cdecimal result, 5 repetitions or so).
fastint2.patch speeds up floats enormously and slows down decimal by 6%.
fastint_alt.patch slows down float *and* decimal (5%
Stefan Krah added the comment:
I've never seen 20% fluctuation in that benchmark between runs. The benchmark
is very stable if you take the average of 10 runs.
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
I mean, if you run the benchmark 10 times and the unpatched result is always
between 11.3 and 12.0 for floats while the patched result is
between 12.3 and 12.9, for me the situation is clear.
--
___
Python tracker
Stefan Krah added the comment:
I thought this was the usual telco benchmark instability, but with the patch
_decimal *does* seem to be faster in other areas, too.
--
___
Python tracker
<http://bugs.python.org/issue26
Stefan Krah added the comment:
Additionally, "single digit will always fit a double"?
--
nosy: +skrah
___
Python tracker
<http://bugs.python.o
Stefan Krah added the comment:
Sorry, I was a bit brief: The current comment says "decimal" instead of
"double". It should be changed to "double".
--
___
Python tracker
<
Stefan Krah added the comment:
The comment looks good to me -- I'll stay out of the benchmarking issue, I
didn't check any of that. :)
--
___
Python tracker
<http://bugs.python.o
Stefan Krah added the comment:
Well I *did* run the decimal/float milli-benchmark now and it shows at least
15% improvement for floats consistently.
Given that the official benchmark suite does not seem to be very stable either
(#21955), I actually prefer small and well-understood benchmarks
Stefan Krah added the comment:
Unfortunately, replacing io.BytesIO(data) with indexing does not make the
benchmark faster or more stable on my machine.
BTW, string conversion of the result is actually a crucial part of
the benchmark, it was taken out in
http://bugs.python.org/file41802
Changes by Stefan Krah :
--
title: FIx telco benchmark -> Fix telco benchmark
___
Python tracker
<http://bugs.python.org/issue26284>
___
___
Python-bugs-lis
Stefan Krah added the comment:
#26288 brought a great speedup for floats. With fastint5_4.patch *on top of
#26288* I see no improvement for floats and a big slowdown for _decimal.
--
___
Python tracker
<http://bugs.python.org/issue21
Stefan Krah added the comment:
As Serhiy mentioned, I'm really happy with the Py_SETREF() macro and I
understand the reasons why it was applied so broadly.
But if a module maintainer prefers not to change existing (and
correct) code, then that should have priority (also, the existing
ve
Stefan Behnel added the comment:
I like Serhiy's patch, too, but it feels like the single-digit case should be
enough. I found this comment by Yury a good argument:
"""
I can see improvements in micro benchmarks, but even more importantly, Serhiy's
patch reduces memor
Stefan Krah added the comment:
I like the feature for literals, but I'm not sure about conversions from
string. It slows down the conversion for (IMO) a very small benefit.
Other languages allow it, but I've never attempted to use the feature:
$ ocaml
OCaml vers
Stefan Krah added the comment:
If the string conversions stay, may I suggest two functions:
1) PyUnicode_NumericAsAscii()
2) PyUnicode_NumericAsAsciiWS()
The first one eliminates only underscores, the second one both
underscores and leading/trailing whitespace.
Decimal must support both
Stefan Krah added the comment:
Correction: The explanation of the functions should be reversed.
--
___
Python tracker
<http://bugs.python.org/issue26331>
___
___
Stefan Krah added the comment:
> Georg Brandl added the comment:
>
> Thanks, I hadn't looked at cdecimal yet - I was planning to ask you to do the
> necessary changes there :)
Oh, well. :)
> But there are a few versions of this (e.g. converting unicode digits to
Stefan Krah added the comment:
I still wonder about the complexity of all this for decimal. We now have two
grammars on top of each other, this being the actual one for decimal:
http://speleotrove.com/decimal/daconvs.html
For string conversions I'd prefer a lax way (similar to OCaml)
Stefan Krah added the comment:
Telco is a real world workload devised by Mike Cowlishaw. Some fixes
need to me made for the version in the benchmark suite; in particular,
the amount of input seems insufficient for _decimal (#26284).
I'm not a fan of weeding out real world benchmarks unti
Changes by Stefan Krah :
--
dependencies: +Fix telco benchmark
___
Python tracker
<http://bugs.python.org/issue26275>
___
___
Python-bugs-list mailing list
Unsub
New submission from Stefan Seefeld:
The unittest test discovery right now only looks into sub-packages if they
contain a `__init__.py` file. That's an unnecessary requirement, as packages
are also importable if only `__init__.pyc` is present.
--
components: Library (Lib)
mes
Stefan Behnel added the comment:
Nice one. While reimplementing it for Cython, I noticed that the grammar
described in the PEP isn't exactly as it's implemented, though. The grammar says
digit (["_"] digit)*
whereas the latest patch (v4) says
`digit` (`digi
Stefan Behnel added the comment:
Ah, thanks. Here's my implementation then:
https://github.com/cython/cython/pull/499/files
It seems that tests for valid complex literals are missing. I've added these to
the end of the list:
'1_00_00.5j',
'1_
Stefan Behnel added the comment:
Our CI build server says it's all fine. The fix will eventually be released,
certainly before Py3.6 comes out.
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
Thank you, this is excellent! Does that mean that all locale patches are no
longer needed? Here is one left (perhaps accidentally):
https://github.com/yan12125/python3-android/blob/cpython-hg/mk/ncurses/android-locale-fixes.patch
Stefan Krah added the comment:
Thanks, the test was not needed: It was more of a reminder to sync the version
numbers.
--
___
Python tracker
<http://bugs.python.org/issue26
Changes by Stefan Krah :
--
assignee: -> skrah
resolution: -> fixed
stage: -> resolved
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.pyt
Stefan Krah added the comment:
I did: Somehow roundup failed to catch it.
--
___
Python tracker
<http://bugs.python.org/issue26621>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
The roundup timeline is a lie. :) I pushed the 3.5 patch shortly after the 3.6
one and well before msg262302.
--
___
Python tracker
<http://bugs.python.org/issue26
Changes by Stefan Krah :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue26621>
___
___
Python-bugs-list mailing list
Unsubscrib
Stefan Krah added the comment:
is_integer() is very important for writing new functions. libmpdec has
it and it's used a lot inside mpdecimal.c.
In this case though I assume Robert needs it for duck typing.
--
___
Python tracker
Stefan Krah added the comment:
I've been thinking about this, and I'm +1 for the change now.
These structural typing issues for numbers come up regularly
(see also msg257088), and the functions are so simple and
self-explanatory that API-complexity does not really increase.
In
Stefan Krah added the comment:
Ping. Just a reminder that it would be nice to get this into 3.6-alpha-1. :)
--
___
Python tracker
<http://bugs.python.org/issue25
4601 - 4700 of 4955 matches
Mail list logo
