Stefan Krah added the comment:
Visual studio apparently has the option /F to set the stack size.
Maybe ICC has one, too.
--
___
Python tracker
<http://bugs.python.org/issue24
Stefan Krah added the comment:
Thanks, I've contacted Robert.
--
___
Python tracker
<http://bugs.python.org/issue24999>
___
___
Python-bugs-list mailing list
Stefan Krah added the comment:
According to the human readable grammar in the docs
https://docs.python.org/3/reference/expressions.html#calls
I'd say this was a bug that is now fixed in 3.5. The call should
either take a single unparenthesized generator expression or an
argument_list (
Stefan Krah added the comment:
See:
https://docs.python.org/3/reference/lexical_analysis.html#blank-lines
--
assignee: -> docs@python
components: +Documentation -Interpreter Core
nosy: +docs@python, skrah
resolution: -> not a bug
stage: -> resolved
status: open ->
Stefan Krah added the comment:
I think the issue can be closed (after updating "what's new").
Even if we wanted to keep backwards compatibility, it's too
late now.
--
___
Python tracker
<http://bug
New submission from Stefan Krah:
If a type scheme is instantiated, should the type variables in the
class body be substituted? This is an example (typed by hand on
a locked down Windows machine, may contain errors):
alpha = TypeVar('alpha')
beta = TypeVar('beta')
class A
Stefan Krah added the comment:
Yes, errno should always be cleared before use (in C99 at least,
not sure what the crt does).
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue25
Stefan Krah added the comment:
Clearing is easy: errno = 0; :)
C library functions are not supposed to set errno to 0 by
themselves (C99: paragraph 7.5).
--
___
Python tracker
<http://bugs.python.org/issue25
Stefan Krah added the comment:
Steve, sorry if I misunderstand you: My point (and eryksun's)
was that errno is currently not cleared before the call to
format_time() in
Modules/timemodule.c:657
I didn't look at this issue in depth, just pointing out a
poss
Stefan Krah added the comment:
Argh, finally I got it: You suggested that Python users work
around this in 3.5 by setting errno from the interpreter.
I think it's better to release 3.5.1 early.
--
___
Python tracker
<http://bugs.py
Changes by Stefan Krah :
--
nosy: +loewis, skrah
___
Python tracker
<http://bugs.python.org/issue25124>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
In theory we should set FENV_ACCESS whenever the control word is
changed (C99):
"If part of a program tests floating-point status flags, sets
floating-point control modes, or runs under non-default mode
settings, but was translated with the state fo
Stefan Krah added the comment:
Ok, clang does not support it either:
https://llvm.org/bugs/show_bug.cgi?id=10409
--
___
Python tracker
<http://bugs.python.org/issue24
Stefan Krah added the comment:
Regarding volatile: gcc/clang seem to honor *some* changes to
the control word. At least in libmpdec both compilers have
always left the settings 80bit-prec/ROUND_CHOP intact, even
though it's not the default.
Let's rewrite Python in asm to avoid th
Stefan Krah added the comment:
> There are similar issues with Decimal.from_float() (C implementation only),
> chain.from_iterable(), epoll.fromfd() and kqueue.fromfd(). All these
> alternative constructors don't call __new__ or __init__.
Could you create new issues? I
Stefan Krah added the comment:
Usually these segfaults are toolchain bugs (I've had at least 8,
including gcc, suncc, libc...).
Just a couple of observations:
- The bot builds with -DCONFIG_32=1 -DANSI=1 despite being PPC64.
- When we had an AIX snakebite machine, the xlc compile w
Stefan Krah added the comment:
I've checked: test_decimal does not require abnormal amounts of
memory or stack. On Linux/x86 a stack size of 256 (default 8192)
is sufficient, and memory requirements aren't that high.
We assumed that there is some memory limit on the buildbot, since
Stefan Krah added the comment:
And the segfaults are apparently somewhat random. This is beginning
to look like an issue unrelated to decimal that was perhaps recently
introduced (in which case "hg bisect" would be the fastest
way to debug).
http://buildbot.python.org/all/builders/P
Stefan Krah added the comment:
If you have time, you could use an explicit seed (and gdb):
# test_email segfault:
./python -m test -j 1 -u all -W --randseed 5634141
--
___
Python tracker
<http://bugs.python.org/issue25
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue25300>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
In principle adding the option is fine, but do we have a buildbot
with a Skylake processor? We have lots of options that are untested
and that break periodically.
--
nosy: +zach.ware
___
Python tracker
<h
Stefan Krah added the comment:
Static types leak memory on finalization, see PEP 3121. Normally it
does not matter, but you see it when embedding Python.
PEP 3121 isn't widely implemented because a) it complicates the
code for large modules and b) there are some performance issues.
Ther
Stefan Krah added the comment:
> Whether the hardware is MPX enabled is irrelevant for the build process.
The build process is only one part of the equation. Compilers do have
bugs (Python has been affected by gcc, Visual Studio and suncc bugs),
and we should test the actual generated
Stefan Krah added the comment:
> It's possible that Python needs to be built with special options to allow
> additional malloc space (-bmaxdata:0xN000).
It seems to be the case, see Misc/README.AIX. This could explain the
MemoryErrors, but not the segfaults.
Are computed-goto
Stefan Krah added the comment:
Wouldn't setting CFLAGS be sufficient?
./configure CFLAGS="-fcheck-pointer-bounds -mmpx"
Otherwise we could also add --with-stack-protector and --with-fortify-source
and others. I'm not sure if we should add a special --with*
optio
New submission from Stefan Krah:
I think tokenize.py needs to be updated to support f-strings.
BTW, the f-string implementation seems to be incredibly robust. Nice work!
--
components: Library (Lib)
messages: 252274
nosy: eric.smith, skrah
priority: normal
severity: normal
stage
Stefan Krah added the comment:
> Third party modules might need patching to work with MPX...
If the flags go into CFLAGS, these modules won't compile with
distutils. Perhaps we should also add LDFLAGS_NODIST, if that
would solve your
Stefan Krah added the comment:
Try setting the stack size to 8MB (the default on Linux) in login.conf.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue25
Stefan Krah added the comment:
It's not noise, we also have problems on Windows with test_json.
In theory we should set Py_DEFAULT_RECURSION_LIMIT in Python/ceval.c
to appropriate values for the default OS stack sizes in order to get
a proper RuntimeError instead of a segfault.
For Op
Stefan Krah added the comment:
The ratio (1000/8MB) seems to be stable on Linux. Perhaps we could
write a getrlimit program for ./configure to get the stack size and
adjust the recursion limit to keep the ratio the same.
It's just an estimate of c
Stefan Krah added the comment:
Or did you want to compute it at runtime? Actually, why not?
--
___
Python tracker
<http://bugs.python.org/issue25342>
___
___
Stefan Krah added the comment:
Adjusting the estimate at runtime sounds good to me.
--
___
Python tracker
<http://bugs.python.org/issue25342>
___
___
Python-bug
Stefan Krah added the comment:
> The Python MPX binary will be built with –O0 because other optimization
> levels will change instruction order and cause crashes, making it useful for
> debugging purposes.
I've trouble understanding this: Is the gcc mpx feature not stable?
Stefan Krah added the comment:
We should ultimately do something like I suggested in msg235256.
Everything else is a hack (N.B.: the issues that 1da9630e9b7f
tried to fix were also hacks, so it isn't really the fault of
that commit).
--
nosy: +
Stefan Krah added the comment:
If memoryview B is created from memoryview A, then B must be
registered with the same ManagedBuffer as A, otherwise the
whole scheme breaks down (PyMemoryView_FromObject() performs
this check).
PyMemoryView_FromBuffer() is really a legacy function that
should be
Stefan Krah added the comment:
Per the docs the readonly flag must be consistent for all consumers,
so checking for writability after getting the view should be okay in
principle.
--
___
Python tracker
<http://bugs.python.org/issue25
New submission from Stefan Krah:
See for example #25498.
--
messages: 253787
nosy: skrah
priority: normal
severity: normal
status: open
title: Add PyMemoryView_FromObjectWithFlags()
versions: Python 3.6
___
Python tracker
<http://bugs.python.
Changes by Stefan Krah :
--
assignee: -> skrah
___
Python tracker
<http://bugs.python.org/issue25524>
___
___
Python-bugs-list mailing list
Unsubscrib
Stefan Krah added the comment:
The current hack isn't necessary. I didn't review eryksun's patch
in depth, but on the surface it looks good.
I don't think the other issues you mentioned are closely related:
The cause here is that the obj fields of both the second memoryview
Stefan Krah added the comment:
> But I think there should be some way of guaranteeing that a memoryview will
> not try to access memory which has already been freed.
Unless the "buffered *self" parameter in _buffered_raw_read() is
made a full PEP-3118 exporter, I'm not
Stefan Krah added the comment:
Florin, thanks for the explanation. I'd suggest to wait until
the mpx support is stable in gcc.
Some security features in gcc never take off (-ftrapv is broken,
libmudflap is deprecated, ...) so it would be nice to have some
reassu
Stefan Krah added the comment:
The "chained memoryviews" you refer to are a hack and simply
aren't supported. Please stop spreading FUD.
--
___
Python tracker
<http://bugs.pyt
Stefan Krah added the comment:
> First garbage collector calls tp_clear for all objects in the loop
> (memory_clear() for memoryview).
If self->exports != 0 for memoryview, _memory_release() fails and the
_Py_MEMORYVIEW_RELEASED flag is not set.
I don't understand:
1) memor
Stefan Krah added the comment:
Hmm, I have some reservations about linking to statistics. They
can really give wrong incentives for committing (and IMO this
is already happening on GitHub).
--
nosy: +skrah
___
Python tracker
<http://bugs.python.
Stefan Krah added the comment:
First of all, the premise "exports > 0" in your example looks wrong
to me. The deallocation process for the first view should start precisely when
it no longer has any exports.
In fact, the check for "exports > 0" is for the case wh
Stefan Krah added the comment:
Thanks, no big problem. The thing is that the parts I wrote
(Modules/_decimal/*, Objects/memoryobject.c, Modules/_testbuffer.c)
have been audited rather heavily and have 100% code coverage
with a privately maintained patch that inserts allocation
failures.
There
Stefan Krah added the comment:
The MASK idiom is nice and I think it's good to be exposed to
it from time to time.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
Victor, I'm adding you just in case this also affects your
optimizer (like #2).
--
___
Python tracker
<http://bugs.python.org/is
Changes by Stefan Krah :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue24623>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Serhiy, could you please not change stuff that I maintain? I know
you have the best intentions, but I really don't like these kinds
of changes (just like you don't like trailing whitespace :).
--
no
Stefan Krah added the comment:
Thank you!
--
___
Python tracker
<http://bugs.python.org/issue25558>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
> It looks to me that all issues are related to floating points.
You need to compile with "-fp-model strict" or the Windows
equivalent (I think "-fp-model precise").
--
___
Python tracker
Stefan Krah added the comment:
If anyone worries that "-fp-model strict" will slow
things down: In the Python context these settings have
no measurable impact: A while ago I tested setting/restoring
the control word *for every operation*, and even that did
not have
Stefan Krah added the comment:
It's a Linux issue. Disable overcommitting of memory (at your own
peril) or set user limits (for example with djb's softlimit), then
the process will be killed instead of freezing the machine.
--
nosy: +skrah
Stefan Krah added the comment:
I had a similar issue with ucspi-ssl that was fixed by following
the O'Reilly book's recommendations w.r.t WANT_READ/WANT_WRITE
with non-blocking sockets to the letter.
The recommendations are quite complex since apparently
WANT_READ/WANT_WRITE mean
New submission from Stefan Krah:
memory_hex from #9951 fails for non-contiguous buffers.
--
assignee: skrah
files: memhex.diff
keywords: patch
messages: 254454
nosy: skrah
priority: normal
severity: normal
status: open
title: Fix memory_hex (#9951) for non-contiguous buffers
type: crash
Changes by Stefan Krah :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue25598>
___
Stefan Krah added the comment:
I think you may have meant Eli Bendersky -- I'm not an elementree
expert (Eli, I'm adding you back just to clear this up).
--
nosy: +eli.bendersky
___
Python tracker
<http://bugs.python.o
Stefan Krah added the comment:
> Py_ssize_t ob_array[1] Py_VARIABLE_SIZE; /* Looks weird and confusing */
Yes, I dislike that, too. The question is why gcc has supported
the "struct hack" for more than 20 years but needs an annotation
just for MPX.
Is the annotation also neede
Stefan Krah added the comment:
The compiler does not perform type checking. These are
type *annotations* for third party tools like Mypy.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue25
Stefan Krah added the comment:
Usually unaligned accesses are believed to carry a big performance
penalty, though rumor has it that for the latest generation of CPUs
this is no longer an issue.
--
nosy: +skrah
___
Python tracker
<h
Changes by Stefan Krah :
--
nosy: +steven.daprano
___
Python tracker
<http://bugs.python.org/issue25928>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
3101 - 3200 of 3396 matches
Mail list logo
