Stefan Krah added the comment:
I think all locale includes are unguarded now.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Okay, closing as a duplicate (the second patch here that checks for
locale.h seems too broad to me since it's a standard header).
--
nosy: +skrah
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Inter
Stefan Krah added the comment:
Thank you, closing this.
--
resolution: -> out of date
stage: -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.4
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Stefan Krah added the comment:
#14757 has an implementation of inline caching, which at least seemed to slow
down some use cases. Then again, whenever someone posts a new speedup
suggestion, it seems to slow down things I'm working on. At least Case van
Horsen independently verified
Stefan Krah added the comment:
My conclusion is: The error in msg263292 should have been
caught by the test suite.
I'd ask the WindRiver support if they actually run the test suite
before shipping the binaries.
--
___
Python tracker <
Stefan Krah added the comment:
Also, I don't understand how the test suite could pass with
these kinds of errors. Are you sure this is the Wind-River
system Python? Did they run the test suite?
--
___
Python tracker <rep...@bugs.python.org>
Stefan Krah added the comment:
An option would be to use the support of the probably commercial
http://www.windriver.com/products/linux/
and ask them why they're still on Python 2.7.3. They'll also
have gcc installed and can run the test case proposed in this
issue.
--
nosy: +skrah
Stefan Krah added the comment:
On Thu, Apr 14, 2016 at 08:55:25AM +, Stefan Krah wrote:
> I use it all the time in development:
... where "it" refers to "./configure && make", not to PGO.
--
___
Python tracker
Stefan Krah added the comment:
On Thu, Apr 14, 2016 at 08:39:20AM +, Alecsandru Patrascu wrote:
> @Stefan and @Marc, you say that people don't want to wait for PGO to build
> when running ./configure && make, but why? Even though many developers use
> it, this mod
Stefan Krah added the comment:
Not acceptable, I'm afraid. See #25702. I'm not sure why it is
considered so bothersome to type --with-pgo and --with-lto for
the rare case of a real production build.
--
___
Python tracker <rep...@bugs.python.
Stefan Krah added the comment:
LTO is not stable on all platforms (according to doko), and people don't
want to wait for PGO to build when they just run ./configure && make.
--with-pgo and --with-lto is fine.
--
___
Python trac
Stefan Krah added the comment:
Thank you. So technically, in the above NumPy example the format
string generated by NumPy would be considered incomplete if we assume
struct syntax:
>>> m = memoryview(x)
>>> m.format
'T{B:x:xxxL:y:B:z:}'
I find this "0L" thing
Changes by Stefan Krah <ste...@bytereef.org>:
--
versions: +Python 3.6 -Python 3.3
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pytho
Stefan Krah added the comment:
Here's a grammar that roughly describes the subset that NumPy supports.
As for implementing this in the struct module: There is a new data
description language on the horizon:
http://datashape.readthedocs.org/en/latest/
It does not have all the low-level
New submission from Stefan Krah:
On the x64 architecture gcc adds trailing padding bytes after the last
struct member. NumPy does the same:
>>> import numpy as np
>>>
>>> t = np.dtype([('x', 'u1'), ('y', 'u8'), ('z', 'u1')], align=True)
>>> x = np.array(
Stefan Krah added the comment:
Normally I hate environment variables, but perhaps in this case
PYTHON_DISABLE_MODULES="foo,bar,quux" would be sufficient?
Setup.py already has the "disabled_module_list" variable, it's
just a matter of setting this variable somehow.
This
Stefan Krah added the comment:
In any case: It is not uncommon that some C module does not build.
You can disable modules in setup.py:
# This global variable is used to hold the list of modules to be disabled.
disabled_module_list = []
--
assignee: -> skrah
resolut
Stefan Krah added the comment:
I thought you solved the locale problem in #20305. So it still does not build?
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
On Tue, Apr 05, 2016 at 02:20:19PM +, Robert Smallshire wrote:
> >> Were float to inherit from Rational, rather than Real ...
>
> > This would break the Liskov substitution principle.
>
> How so? Rational extends Real with onl
Stefan Krah added the comment:
On Tue, Apr 05, 2016 at 01:10:25PM +, Robert Smallshire wrote:
> Were float to inherit from Rational, rather than Real ...
This would break the Liskov substitution principle.
--
___
Python tracker &
Stefan Krah added the comment:
Raymond, you added your support in msg257097. I'm not very happy to spend my
time implementing the feature and then rehashing everything after 3 months.
--
nosy: +gvanrossum
___
Python tracker <rep...@bugs.python.
Stefan Krah added the comment:
I agree that Robert's "absurdity" argument was unfortunate and could
be reversed: Many people would consider an (10).is_integer() method
absurd.
I'm also only moderately interested in OOP or classification in general, but
we *do* have a numeric tow
Stefan Krah added the comment:
Ping. Just a reminder that it would be nice to get this into 3.6-alpha-1. :)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
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 general, I
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 <
Changes by Stefan Krah <ste...@bytereef.org>:
--
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26621>
___
_
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
I did: Somehow roundup failed to catch it.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Stefan Krah <ste...@bytereef.org>:
--
assignee: -> skrah
resolution: -> fixed
stage: -> resolved
status: open -> closed
type: -> behavior
___
Python tracker <rep...@bugs.python.org>
<htt
Stefan Krah added the comment:
Thanks, the test was not needed: It was more of a reminder to sync the version
numbers.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
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
Changes by Stefan Krah <ste...@bytereef.org>:
--
dependencies: +Fix telco benchmark
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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 until our
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 version 4.02.1
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
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:
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
version
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
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 <rep...@bugs.python.org>
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
Changes by Stefan Krah <ste...@bytereef.org>:
--
title: FIx telco benchmark -> Fix telco benchmark
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
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 <rep...@bugs.python.org>
Stefan Krah added the comment:
Additionally, "single digit will always fit a double"?
--
nosy: +skrah
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
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.
>
Nice. te
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']
Elapsed time: 7.304339
$ taskset -c 0 ./python telco.py full
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', '25042.17']
Elapsed time: 6.783009
Control totals:
Actual
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 <
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
_decimal
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
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% or so
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 won'
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 decimal imp
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 time
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, so
Changes by Stefan Krah <ste...@bytereef.org>:
--
stage: -> needs patch
type: -> enhancement
versions: +Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
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 <rep...@bugs.python.org>
<http://bugs.p
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
Stefan Krah added the comment:
Thanks, then the patch looks good to me.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24520>
___
__
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:
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 t
Changes by Stefan Krah <ste...@bytereef.org>:
--
nosy: skrah
priority: normal
severity: normal
status: open
title: Disable /W4 warning (non-standard dllimport behavior)
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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 <ste...@bytereef.org>:
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
type: -> compile error
___
Python tracker <rep...@bugs.python.org>
<http:/
Changes by Stefan Krah <ste...@bytereef.org>:
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Stefan Krah added the comment:
Pragma added for libmpdec in #26139.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25878>
___
___
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 <rep...@bugs.python.org>
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 <rep...@bugs.python.org>
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 <rep...@bugs.python.org>
<http://bugs.pyt
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 tra
Stefan Krah added the comment:
+1 for adding it to 3.5.2.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25486>
___
___
Pyth
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:
https://books.google.com/books?id=IIqwAy4qEl0C_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 you do need complete
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.
The book
Stefan Krah added the comment:
Is this a political nosying?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue20008>
___
___
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 <rep...@bugs.python.org>
<http://bugs.python.or
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 <rep...@bugs.python.
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 <rep...@bugs.python.org>
<http://bugs.pyt
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 tracker <
Changes by Stefan Krah <ste...@bytereef.org>:
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
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
messages: 257178
nosy
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 issue (no argument
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 <rep...@bugs.python.
Changes by Stefan Krah <ste...@bytereef.org>:
--
nosy: +serhiy.storchaka
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25972>
___
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.python.org
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 <
Stefan Krah added the comment:
Ah yes, the test_statistics failures look like #18841 again.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
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 really
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
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 decisions
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.
--
___
Python tracker
Changes by Stefan Krah <ste...@bytereef.org>:
--
nosy: +steven.daprano
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25928>
___
_
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 <
801 - 900 of 3373 matches
Mail list logo
