Changes by Stefan Behnel :
--
nosy: +pitrou, serhiy.storchaka
___
Python tracker
<http://bugs.python.org/issue24469>
___
___
Python-bugs-list mailing list
Unsub
Changes by Stefan Krah :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue24473>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Stefan Krah :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue24472>
___
___
Python-bugs-list mailing list
Unsubscrib
Stefan Behnel added the comment:
> 1) The intended solution is to require that int subclasses override tp_free.
In the way I showed? By calling either PyObject_GC_Del() or PyObject_Del()
directly? I'll happily do that (Py2.7 and Py2 "int" being dead ends makes
that pretty
Stefan Behnel added the comment:
I added three more comments to the review. The rest looks good to me, too.
--
___
Python tracker
<http://bugs.python.org/issue24
Stefan Krah added the comment:
If it is a DNS failure, the timeout of 3s indeed looks too low for me.
On a misconfigured machine I'm easily getting timeouts of 20s, (not for
this particular test, just in general, e.g. when using ssh).
--
___
P
Stefan Krah added the comment:
I think it's also possible to misconfigure /etc/nsswitch.conf.
When I opened this issue, my buildbot had the FreeBSD default
configuration. I no longer have any FreeBSD machines, so I
cannot check thi
Stefan Behnel added the comment:
> I originally planned to make the next Cython release patch the Generator
> and Coroutine ABCs into collections.abc, but I now think it would be worth
> uploading an "abc_backports" package to PyPI instead that does that and on
> which asyn
Stefan Krah added the comment:
For libmpdec (and thus _decimal) I've always used the latest version
of dectest.zip. Upgrading decimaltestdata/* will not make any difference.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
I'm saying that decimal has already been tested against the
most recent test cases. For (non-technical) reasons that I
don't want to go into right now, I'd prefer to postpone the
update though.
--
resolution: -> later
stat
Stefan Behnel added the comment:
> isawaitable(), however, should continue using abc.Awaitable, since it only
> checks for __await__ presence on the type (or should we just drop it?)
I'd really remove it. It's not referring to an actual type, so it doesn't fit
the p
Changes by Stefan Krah :
--
nosy: +schwab
___
Python tracker
<http://bugs.python.org/issue24543>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Krah :
--
type: crash -> behavior
___
Python tracker
<http://bugs.python.org/issue24545>
___
___
Python-bugs-list mailing list
Unsubscrib
Stefan Krah added the comment:
Okay, I'll have a look then (I first assumed this was mc68881 specific).
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/is
Changes by Stefan Krah :
--
resolution: -> duplicate
status: open -> closed
superseder: -> Configure script wrongly detects x64/x87/mc68881 with -flto
option passed
___
Python tracker
<http://bugs.python.or
Changes by Stefan Krah :
--
nosy: +ivank
___
Python tracker
<http://bugs.python.org/issue24543>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
In what way are the x64/x87 tests broken? ./configure runs smoothly
here (gcc 4.8.2) with and without -flto.
Can you try "=m" and "m" for the asm output operands?
--
___
Python tracker
<
Stefan Krah added the comment:
"-c" is apparently generated by AC_COMPILE_IFELSE, which uses ac_compile.
The alternative is using AC_RUN_IFELSE, which uses ac_link.
Do you see any other possibility of dropping the "-c"
Stefan Krah added the comment:
> Very surprising! Which platform & Python is that?
I'm unable to reproduce this using Linux-amd64, Python 2.7.6, gcc 4.8.2.
--
nosy: +skrah
___
Python tracker
<http://bugs.python
Stefan Krah added the comment:
I guess we should backport the x87 fix to 2.7.
--
versions: +Python 2.7 -Python 3.5
___
Python tracker
<http://bugs.python.org/issue24
Stefan Behnel added the comment:
This is not purely about speeding up the code. It's also about avoiding to
replace the code object of a function, which is essentially a big and clumsy
hack only to achieve setting a flag. Some tools, namely line_profiler, use the
current code object as a
Stefan Behnel added the comment:
> 1. abc.Coroutine and abc.Awaitable will guarantee that objects that implement
> them have '__await__' and it's safe to access it (that means that they will
> fail for generator-based coroutines).
Absolutely. That was the main the
Stefan Behnel added the comment:
> the undecorated form will never be visible to any code other than the
> decorator
Assuming that 1) it's the first and/or only decorator, 2) it's used to
decorate a generator function that returns its own generator and 3) it's
really us
Stefan Krah added the comment:
Just to defend gcc. :) I still cannot reproduce Steven's problem
even with the C example and -m32.
Steven's gcc [GCC 4.1.2 20080704 (Red Hat 4.1.2-52)] is very old
and probably has quite a lot of distro patches.
I'd try a modern
Stefan Krah added the comment:
Could you perhaps rephrase this "bug report"?
--
nosy: +skrah
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue24559>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Fixed in 2.7, 3.5 and default. Thanks everyone for the comments.
--
assignee: -> skrah
components: +Build
resolution: -> fixed
stage: -> resolved
status: open -> closed
type: -> compile error
versions: +Python
Stefan Krah added the comment:
People have posted the asm now:
https://mail.python.org/pipermail/python-list/2015-July/693509.html
The fmull result appears to be the same. The good gcc versions set
the control word to "truncate" and then use fistpl (single rounding
with the co
Stefan Krah added the comment:
> Now I'm wondering what further test coverage we really need...
Ideally we'd test every C module with the tests executing "in
parallel" (sort of) in multiple interpreters.
I have done so for _decimal, which is mostly okay due to th
Stefan Krah added the comment:
Andrew, given that you did not upload the package, I don't see
how you have anything to do with this.
Creating an internal or a *clearly distinguished* external
package is fine; taking up a misleading second spot on PyPI,
plagiarizing the package descri
Stefan Krah added the comment:
I think for fast access we need a hybrid solution that allows
static types (heap types slowed down _decimal) *and* cache the
thread local values (like it's currently done for the thread-local
context in _decimal).
Caching the context brought an enormous sp
Stefan Krah added the comment:
I've finally gotten hold of a gcc (5.1.0) that produces the unwanted code.
For a *different* test case, even the -O0 and -O2 results differ, since
with -O2 gcc uses mpfr (I think!) for constant folding, which produces
the correct result.
Using -mfpmath=sse
Stefan Krah added the comment:
Nick, this may be a misunderstanding, but you mentioned issues
that PEP 489 did not address yet. The only issue left for _decimal
is the speed issue. Sub-interpreter tests run fine even with the
existing module state API, *if* one is willing to take a speed hit
Stefan Krah added the comment:
Any chance that another program (C-extension) had set the FPU control
word to an unusual value (24bit prec?).
--
___
Python tracker
<http://bugs.python.org/issue24
Stefan Krah added the comment:
> Python-the-language makes no promises about adhering to IEEE 754 arithmetic
> rule.
Still, I think we could switch to -mfpmath=sse, which would at least
guarantee consistent behavior across different gcc ve
Stefan Krah added the comment:
Qt had a similar initiative regarding -msse2 -mfpmath:
http://lists.qt-project.org/pipermail/development/2013-December/014530.html
They say that also Visual Studio 2012 has switched to sse2 by default.
The only problem are the Linux distributions that are stuck
Stefan Behnel added the comment:
It's generally worth running the benchmark suite for this kind of optimisation.
Being mostly Python code, it should benefit quite clearly from dictionary
improvements, but it should also give an idea of how much of an improvement
actual Python code (an
Stefan Behnel added the comment:
> Your benchmarks are not affected by this change see the other issue.
Then you ran them, I assume? Could you show the output here that you got?
> They are also not representative of every workload out there.
Certainly not, but they do provide a c
Stefan Behnel added the comment:
I'm witnessing a crash in the C implementation during garbage collection.
Interestingly, it only shows in the Py3.6 branch, not in Py3.5 (both latest).
Here's the gdb session:
Program received signal SIGSEGV, Segmentation fault.
lru_cache_tp_trav
Stefan Behnel added the comment:
It's not actually my own code using the lru_cache here. From a quick grep
over the code tree, the only potentially related usage I found was in
Python's fnmatch module, on the "_compile_pattern()" function. Commenting
that out then made the cr
Stefan Behnel added the comment:
test_fnmatch.py also passes, BTW.
--
___
Python tracker
<http://bugs.python.org/issue14373>
___
___
Python-bugs-list mailin
Stefan Behnel added the comment:
It looks like perfectly valid syntax to me and I cannot see why it should be
semantically rejected. I disagree that it shouldn't be changed. I think it's a
(minor) bug that should eventually get fixed.
--
nos
Stefan Behnel added the comment:
Hmm, right. I see your point and also the analogy with "yield". I could live
with (maybe) giving it a better error message suggesting to use parentheses for
clarity and otherwise keeping it a S
Stefan Krah added the comment:
The double rounding problem even occurs between different versions
of gcc. I think ultimately we should put our foot down and ship with
sse2 enabled (not possible for 2.7 though, unless an LTS-PEP emerges).
If distributions want to break that, it's their bus
New submission from Stefan Krah:
If I understand the reference manual correctly, these should probably
be rejected by the compiler:
>>> async def f():
... def g(): pass
... async = 10
...
>>> async def f():
... def async():
... pass
...
>>>
New submission from Stefan Krah:
While trying to find a possible cause for #24546, I came across this
glitch:
Python 3.6.0a0 (default:02b81a82a57d, Jul 12 2015, 20:33:44)
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more i
New submission from Stefan Krah:
ELLIPSIS and RARROW are missing in EXACT_TOKEN_TYPES. Patch attached.
--
files: tokenize.diff
keywords: patch
messages: 246663
nosy: meador.inge, skrah
priority: normal
severity: normal
status: open
title: tokenize.py: missing EXACT_TOKEN_TYPES
Added
New submission from Stefan Krah:
IMO the string should start at lineno=1, col_offset=0.
$ ./python
Python 3.6.0a0 (default:02b81a82a57d, Jul 12 2015, 20:33:44)
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more infor
Changes by Stefan Krah :
--
nosy: +benjamin.peterson
___
Python tracker
<http://bugs.python.org/issue24623>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
I think it's just a matter of checking for self->index <= N in setstate().
--
___
Python tracker
<http://bugs.python.
Stefan Krah added the comment:
I think with the ASYNC/AWAIT changes any code using tokenize.py
will have to be updated anyway in 3.5 and in 3.7 (when ASYNC/AWAIT
will finally be real keywords).
So this is probably an ideal time for the change. I'll add
Stefan Krah added the comment:
+1 for python -m test.subinterpretertest. Based on my experiments,
most tests will either fail or leak memory at the very least.
--
___
Python tracker
<http://bugs.python.org/issue24
Stefan Behnel added the comment:
Benchmark results look good to me (although a header line is missing) and seem
to match my expectations. Sounds like we should allow this change.
--
___
Python tracker
<http://bugs.python.org/issue23
Stefan Behnel added the comment:
Thanks for updating the micro-benchmark. Just FYI (and sorry for hijacking this
ticket), I ran it through Cython. Here are the numbers:
Cython 0.23 (latest master)
binary(21) * 3: total 1.609s
abinary(21) * 3: total 1.514s
CPython 3.5 (latest branch)
binary(21
Stefan Krah added the comment:
This is a very nice solution!
I'm just curious if the 'ctx' is still needed: It looks like
the outermost "async def" dominates all further nested scopes
w.r.t the tokenizer mode, no matter whether they're "def" or
"a
Stefan Behnel added the comment:
> Hm, I think there's little need for new exceptions...
While I agree with Yuri that the names are a bit awkward, I actually second
this. The StopIteration is almost an implementation detail of how the return
value is passed on to become the (Future) r
Stefan Behnel added the comment:
Agreed that it's misleading. Note that the section refers to the *following*
example, not the one that readers just went through.
I would actually start that paragraph with the reference to XPath (because
that's the difference to el.iter()), and
New submission from Stefan Krah:
There's a corner case in cwr_next(), where the pool size is zero
but pool[0] is accessed:
from itertools import *
it = combinations_with_replacement([], 0)
next(it)
Patch attached.
--
components: Extension Modules
files: itertools_invalid_access
Stefan Krah added the comment:
Sorry, I'm still not convinced that the C-contiguity explanation is in the
right place. The docs have to be terse in order to be useful as a reference,
and the explanation at that particular location breaks the flow of reading.
So, please don't c
Stefan Krah added the comment:
Closing, since I'm -0 and usually Raymond is against these kinds of
changes (Raymond: please correct me if I'm wrong).
--
resolution: -> rejected
stage: patch review -> resolved
status: open -> closed
___
Stefan Krah added the comment:
Unassigning, since I've no time for reviewing (I think the patch
needs review though, either by Mark or Raymond).
--
assignee: skrah ->
___
Python tracker
<http://bugs.python.org
Stefan Krah added the comment:
Steve, this issue has been open for a while: Do you have an
opinion on whether this is useful to have?
I originally opened the issue because I am using masm in cdecimal,
but there are workarounds.
--
nosy: +skrah, steve.dower
Stefan Krah added the comment:
Victor, there was no actual crash, just a potential one. In
terms of the observable runtime behavior the code behaved
correctly.
I would not know what to test for, unless we set up a buildbot
running Valgrind (which is impracticable for a number of reasons
Stefan Krah added the comment:
The workaround is telling users to run e.g. ``vcvarsall x64'' before
the build. setup.py then contains
extra_objects = ['vcdiv64.obj']
os.system("ml64 /c /Cx vcdiv64.asm"),
which is run before creating the extension.
Stefan Behnel added the comment:
Note that the expected usage is not as a function but as a decorator. That
should be stated in the docs as well. IMHO, users should only do two things
with whatever the result is: either use it as a Generator (as before), or pass
it as an argument to "
Stefan Krah added the comment:
> $ make test > Go.res3 2>&1 &
The test suite does seem to behave poorly when run in the background:
I'm getting constant swapping, excessive kworker activity, and indeed,
one hang.
With nohup prepended at least the tests have finished now
Stefan Krah added the comment:
c-contig.v3.patch LGTM.
--
___
Python tracker
<http://bugs.python.org/issue23756>
___
___
Python-bugs-list mailing list
Unsub
Stefan Krah added the comment:
Personally I'm happy to run the tests in the foreground. :)
BTW, I didn't intend to reopen this one. Shall we close it
or do you want to keep it open for improving the test suite?
--
___
Python trac
Stefan Behnel added the comment:
could we apply this patch, please?
--
___
Python tracker
<http://bugs.python.org/issue24079>
___
___
Python-bugs-list mailin
Stefan Behnel added the comment:
Here's a complete drop-in replacement.
"""
More specific constraints on which elements to look for and where to look for
them in the tree can be expressed in :ref:`XPath `.
:meth:`Element.iterfind` iterates over all elements matching suc
Stefan Behnel added the comment:
> The proposed patch downplays that generality.
That is completely intentional. Almost all readers of the documentation will
first need to understand the difference between text and tail before they can
go and think about any more advanced use cases that w
Stefan Behnel added the comment:
Personally, I would prefer getting the improved version applied over
bikeshedding for another couple of months. But maybe that's just me.
--
___
Python tracker
<http://bugs.python.org/is
Stefan Behnel added the comment:
Whenever you feel a need for using range(len(...)), you are almost always doing
something wrong. The problem in your code is that you are modifying the tree
while iterating over it. However, please ask this question on the mailing list
as the bug tracker is
Stefan Behnel added the comment:
Funny. I just thought about this yesterday and came up with pretty much the
same idea. +1 for the patch.
I don't think there are more classes to support here. Quite the contrary,
other tools should try to integrate via concurrent.futures.Future in
Stefan Behnel added the comment:
It would be nice to have this applied to 3.5 even. I'm aware that this is a
new feature that shouldn't go in any more at this point, but if it could
get added in 3.5.1 at least, I think it would fill a rather clear and
annoying gap when it com
Stefan Behnel added the comment:
> I find it questionable to mix await and threads, as I have said several
> times in the discussion about Nick Coghlan's proposal to introduce
> helper functions with a similar function.
There are a couple of use cases in the context of asyncio,
Stefan Behnel added the comment:
The fix wasn't applied yet, so the current code in 3.4 and later branches is
still incorrect. Any of the last two patches ("*_value") will fix it, with my
preference on the last one.
--
versio
Stefan Behnel added the comment:
Regarding tests, it looks like iteration isn't currently tested at the C
level at all. At least, the xx test modules don't have any types that use
it. I can write one up next week, or add it to one of the existing types
(Xxo_Type?). Unlikely that I&#
Stefan Krah added the comment:
Yuriy: cast() does not do this. What's requested is that e.g. a
single float is represented as a bytes object instead of a float.
Thus, you'd be able to do:
m[0] = b'\x00\x00\x00\x01'
This has other implications, for example, two NaNs
Stefan Krah added the comment:
The question is whether we want this behavior.
--
assignee: -> skrah
___
Python tracker
<http://bugs.python.org/issu
Stefan Krah added the comment:
If people are content with writing m[124:128] = b'abcd' and accept
that tolist() etc. won't represent the original structure of the
object, then let's do it.
On the bright side, it is less work. -- I
Changes by Stefan Krah :
--
title: memoryviews and ctypes -> memoryview: allow all casts to bytes
___
Python tracker
<http://bugs.python.org/issue15944>
___
_
Stefan Krah added the comment:
Ok, shall we sneak this past Larry for 3.5?
--
___
Python tracker
<http://bugs.python.org/issue15944>
___
___
Python-bugs-list m
Stefan Krah added the comment:
Done. Thanks for the patch.
--
components: +Interpreter Core
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.5
___
Python tracker
<http://bugs.python.or
Stefan Krah added the comment:
I would commit this, except that I'm not too happy with the use of
the term "bytes-like" in general. Yesterday I mistyped this:
>>> import ctypes
>>> x = ctypes.c_double
>>> m = memoryview(x)
Traceback (most recent ca
Stefan Krah added the comment:
For end users it's probably adequate. But several committers find
the term confusing (msg236283, msg188484). :)
Anyway, I'm going to commit this since it adds clarity.
--
___
Python tracker
<http://bu
Stefan Krah added the comment:
Martin, thanks for the patch!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.4
___
Python tracker
<http://bugs.python.or
New submission from Stefan Krah:
On my machine (Lenovo T400, Linux) the load average during running
the 2.7 test suite is about 0.5 (with some exceptions like test_io).
The system is still usable even during test_io.
In 3.6 the load average is > 2.0, with some tests making
the sys
Stefan Krah added the comment:
Scratch the comment about test_io in 2.7: It also renders the
system unusable.
--
___
Python tracker
<http://bugs.python.org/issue24
Stefan Krah added the comment:
It's very likely an I/O issue. There are several large file
tests that run even if 'largefile' is disabled. It already
helps a lot if the following tests are decorated with
requires_resource('largefile'):
test_mmap: class LargeMmapTests()
Stefan Krah added the comment:
Thanks, this clears up the mystery! -- I made the mistake of choosing
the eCryptfs-homedir option when installing Ubuntu, so now I have eCryptfs on
top of LVM on top of full-disk encryption.
So I can't create sparse files in my home directory, but I *can*
c
Stefan Krah added the comment:
I don't know whether this is worth reopening, but the ecryptfs
performance is still very poor on my Lenovo T400 (see #24831).
For most people an extra option for choosing the tmpdir
would not help, since they'd simply blame the hardware
or the
Stefan Krah added the comment:
Yes, the current scheme is probably good for easy buildbot cleanup.
> Maybe we can blacklist some filesystems to choose the temporary directory.
If that's easily possible, it would be a good solution at least
for ecryptfs.
I've removed ecryptfs
Stefan Krah added the comment:
Actually, for ecryptfs we could just check for ~/.ecryptfs and
then use /tmp.
--
___
Python tracker
<http://bugs.python.org/issue24
Stefan Behnel added the comment:
> Also, the uptake for SNs are nearly zero.
That suggests to me that pointing users to it could help. It's currently hidden
in the types module and if I didn't know it existed, I could end up looking in
collections, and failing to find it there,
Stefan Behnel added the comment:
The "can store arbitrary objects" sentence is now duplicated, and still way too
visible. I have to read three sentences until it tells me what I need to know.
--
___
Python tracker
<http://bugs.python.o
Stefan Behnel added the comment:
I think the first two sentences can simply be removed to fix this, without loss
of readability or information.
--
___
Python tracker
<http://bugs.python.org/issue24
Stefan Behnel added the comment:
Please upload your patches as separate, uncompressed files for review.
PGO was already proposed here, but nothing came out of it:
https://bugs.python.org/issue17781
I suggest rejecting that old ticket and sticking with this one since it has an
actual patch
Stefan Behnel added the comment:
Issue 24915 suggests PGO and comes with an actual patch. I suggest rejecting
this ticket as too broad.
--
nosy: +scoder
___
Python tracker
<http://bugs.python.org/issue17
Stefan Krah added the comment:
Yacc uses low to high.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue24921>
___
___
Python-bugs-list mailin
4401 - 4500 of 4955 matches
Mail list logo
