Stefan Krah added the comment:
Ah nice, let's continue with your issue then.
--
resolution: - duplicate
stage: - resolved
status: open - closed
superseder: - The Modules/ directory should not be added to sys.path
___
Python tracker rep
Stefan Krah added the comment:
I think we have this behavior since 6c468df214dc and 227ce85bdbe0 (#17095).
--
nosy: +ned.deily, twouters
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22285
Stefan Krah added the comment:
The revisions that cause the bot to go red (6c468df214dc and 227ce85bdbe0) are
quite recent, so I suggest we address the failure in #22285.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22090
Stefan Krah added the comment:
I'm not going to argue this any further, but recent is exactly the
point...if all of the bots had turned red you'd understand that it needed to
be fixed *immediately* or the triggering change (regardless of what the
actual bug was) backed out. Since
Changes by Stefan Krah stefan-use...@bytereef.org:
--
components: +Library (Lib)
resolution: - fixed
stage: - resolved
status: open - closed
versions: +Python 2.7, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Stefan Krah added the comment:
I think only the builders --with-system-libmpdec fail. That's inevitable,
since they still use libmpdec-2.4.0.
Starting from 7fbb912c0789 they should fail building _decimal entirely until I
upgrade the system libmpdec on the builders
New submission from Stefan Krah:
This may be related to PEP 451: Previously, if the _decimal.so build
failed for whatever reason, decimal.py would be used instead. For that
to work, importing _decimal needs to fail.
But now the import is successful:
# Simulate build failure:
rm Modules
Stefan Krah added the comment:
It seems _decimal is imported even if _decimal.so is not built.
I've opened #22280 for that.
Regarding this patch, everything looks fine to me.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http
Stefan Krah added the comment:
The effect can also be seen on the two buildbots that currently fail
to build _decimal due to a libmpdec version mismatch:
http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/7088/steps/test/logs/stdio
--
keywords
Stefan Krah added the comment:
I'm not sure that I understand. IMHO this issue does not break any buildbots.
The current situation is that it exposes an unrelated import issue (#22280).
I can camouflage that issue by upgrading the FreeBSD and the Fedora bot to
libmpdec-2.4.1 (once it's out
Stefan Krah added the comment:
Antoine Pitrou rep...@bugs.python.org wrote:
Who are those people? #16745 was opened by you :-)
MvL, in #4555 (msg176486).
Platform specific maybe, but no hack: I was thinking about storing the DSO
handle in the PyModuleObject struct and add functions
Stefan Krah added the comment:
Ah yes, the array of function pointers is directly accessible. I did not look
close enough -- reading the word spam 100x in the docs always makes me skim
the text. ;)
--
___
Python tracker rep...@bugs.python.org
http
Stefan Krah added the comment:
Antoine Pitrou rep...@bugs.python.org wrote:
(which means that, perhaps, the answer is to make the mpd_ prefix
configurable with a #define?)
I don't know 100% what you have in mind, but Debian and Arch already ship
--with-system-libmpdec, so only the mpd_
Stefan Krah added the comment:
That's what I meant. The issue here is that Python's libmpdec is not exposed
to third-party code at all. Also there should probably be a (thin?) API to get
at the underlying mpdec object from a cdecimal PyObject (apologies for the
poor
wording, I'm actually
Stefan Krah added the comment:
Thanks. I agree about 2.7 -- including 3.4 would perhaps make
external libmpdec management easier for Debian and Arch.
I'm not suggesting that we should always consider the distributors,
but this particular issue seems so minor
Stefan Krah added the comment:
I guess it's the right thing to do and here's a patch. Could one of you double
check the decimal.py part?
--
keywords: +patch
Added file: http://bugs.python.org/file36410/issue22090.diff
___
Python tracker rep
Stefan Krah added the comment:
A modified version of telco.py (using floats instead of decimals) runs
about 5-6% slower with the change here.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2
Changes by Stefan Krah stefan-use...@bytereef.org:
Added file: http://bugs.python.org/file36378/api-demo[1].c
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22194
Stefan Krah added the comment:
I'm a little unsure what to do with the API, see also #15237:
1) I'm not too fond of the Capsule method, especially because
it *seems* possible to get at the symbols directly on Linux
and Windows (provided that they aren't static of course).
2) I
Stefan Krah added the comment:
I think the intention of the standard is pretty much as Mark
said in msg225314. The fact that decimal behaves that way is
another indicator, since Cowlishaw really tried to mirror the
2008 standard as closely as possible
Stefan Krah added the comment:
If it works without -flto, isn't that a toolchain rather than a Python issue?
--
nosy: +schwab, skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22126
Stefan Krah added the comment:
Hi Sowmya. Currently we have the option to use --with-valgrind or
the old method --without-pymalloc. Both methods work.
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18859
Stefan Krah added the comment:
This works in Python 3.3+. It is a bug in 2.7, so we have to wait for
someone motivated enough to work on an outdated Python version.
--
components: +Interpreter Core
nosy: +skrah
stage: - needs patch
___
Python
Stefan Krah added the comment:
Just curious, what causes e.g. telco to differ up to 7% between runs? That's
really huge.
telco.py always varies a lot between runs (up to 10%), even in the
big version telco.py full:
http://bytereef.org/mpdecimal/quickstart.html#telco-benchmark
Using
Stefan Krah added the comment:
So I wonder why the benchmark suite says that the telco slowdown is
significant. :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22003
Stefan Krah added the comment:
Thanks, David. If this is fixed in 2.7 we can close the issue.
--
nosy: +skrah
resolution: - out of date
stage: needs patch - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http
Stefan Krah added the comment:
Actually we have an extra safety net in memory_hash() apart from
the readonly check: We also check if the underlying object is
hashable.
This might be applicable here, too. Unfortunately mmap objects
*are* hashable, leading to some funny results:
import mmap
Stefan Krah added the comment:
I think the mmap behavior is probably worse than the NumPy example.
I assume that in the example the exporter sets view.readonly=0.
mmap objects set view.readonly=1 and can still be mutated.
--
___
Python tracker rep
Stefan Krah added the comment:
I think checking for a readonly view is fine. The protocol is this:
1) Use the PyBUF_WRITABLE flag in the request. Then the provider must
either have a writable buffer or else deny the request entirely.
2) Omit the PyBUF_WRITABLE flag in the request
Stefan Krah added the comment:
The original wording in the PEP is this:
readonly
an integer variable to hold whether or not the memory is readonly. 1
means the memory is readonly, zero means the memory is writable.
To me this means that a hypothetical compiler that could
Stefan Krah added the comment:
I'm sure many exporters aren't setting the right flags; on the other hand
we already hash memoryviews based on readonly buffers, assuming they are
immutable.
--
___
Python tracker rep...@bugs.python.org
http
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7063
___
___
Python-bugs-list
Stefan Krah added the comment:
We deal with it when we have time. IMO there is little value in
bumping up issues this way.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15994
Stefan Krah added the comment:
I think we should perhaps leave the xxmodule as an example for
static types and create another pep-384 version that mentions
*potential* performance traps.
Of course many modules won't suffer from this, but first-time
extension writers tend to paste from
Stefan Krah added the comment:
Sorry Robin, I was wrong about the context -- it should be fine
since it's thread-local. So the slowdown is back to 25%.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15722
Stefan Krah added the comment:
FreeBSD 6.4 is EOL though, for quite some time already:
http://lists.freebsd.org/pipermail/freebsd-announce/2010-September/001344.html
Maybe we should ask the buildbot owner to upgrade to something
newer.
--
nosy: +skrah
Stefan Krah added the comment:
Did you mean to upload a patch?
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21922
___
___
Python
Stefan Krah added the comment:
Hmm, the license (LGPL) should only matter for the Windows binaries
and we can just compile without --enable-big-digits=gmp.
Even *if* the Windows binaries were built with gmp support, it would
be sufficient for any redistributor to point to the external library
Stefan Krah added the comment:
I think you need to figure out the right build flags -- we had
an xlc build slave for a while that did not have this behavior.
The flags were quite complicated though.
--
nosy: +skrah
___
Python tracker rep
Stefan Krah added the comment:
Yes, python-ideas is probably better. -- I just noticed that the
total slowdown is even 40% if the global variable cached_context
is also placed into the module state (as it should).
--
___
Python tracker rep
Stefan Krah added the comment:
In order to avoid the significant slowdown: Could we create a new
kind of method (METH_STATE) and change ceval to pass a state struct
that contains the thread and the module state as the first parameter
if the METH_STATE flag is present
Stefan Krah added the comment:
6ab3193e890e exposes the issue.
--
nosy: +pitrou, skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21897
Stefan Krah added the comment:
Andrew, thanks for signing the agreement!
[Sunny]
Is this what you expect?
I find the initialization in os.stat_result somewhat strange. Also,
a certain use of unnamed fields that worked in 2.5 is now broken,
which we should sort out before proceeding any
Changes by Stefan Krah stefan-use...@bytereef.org:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21778
Stefan Krah added the comment:
Since the rewrite in 3.3 many memoryview tests are actually in test_buffer.py.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21856
Stefan Krah added the comment:
And Terry is right, the actual slice clamping happens in
PySlice_GetIndicesEx(), which should always produce values
that are in the correct range. Hence the tests focus on
slices that already are in the correct range.
I'm not sure if PySlice_GetIndicesEx() itself
Changes by Stefan Krah stefan-use...@bytereef.org:
--
assignee: docs@python - skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21778
Stefan Krah added the comment:
It's a slice of length zero:
b = bytearray([1,2,3,4])
m = memoryview(b)
b2 = b[2**100:]
m2 = m[2**100:]
list(b2)
[]
list(m2)
[]
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21856
Stefan Krah added the comment:
Victor, shall we close this? The behavior is basically as specified:
The slice of s from i to j is defined as the sequence of items with index k
such that i = k j. If i or j is greater than len(s), use len(s). If i is
omitted or None, use 0. If j is omitted
Changes by Stefan Krah stefan-use...@bytereef.org:
Added file: http://bugs.python.org/file35681/ull_vctest.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15993
Stefan Krah added the comment:
The two issues were unrelated - the 'invalid filter ID'
(4611686018427387905 == 0x4000_0001) is the correct
value but the wrong branch in the switch was taken, leading
to the error message.
Unfortunately I don't have a Visual Studio setup right now
Stefan Krah added the comment:
I guess the tests --without-doc-strings are broken:
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/6900/steps/test/logs/stdio
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http
Stefan Krah added the comment:
The flags from mb_getbuf() have to be passed to PyBuffer_FillInfo():
return PyBuffer_FillInfo(view, (PyObject *)self,
internal, 5,
/*readonly=*/0, flags);
The flags contain the actual request
Stefan Krah added the comment:
Yes, PyBuffer_FillInfo() is a bit confusing: The canonical usage *looks* as
if flags were somehow used in the Py_buffer struct to mark a buffer as having
certain capabilities:
Modules/_io/bufferedio.c:
-
if (PyBuffer_FillInfo(buf
Stefan Krah added the comment:
I think it's worth adding a note to the docs about passing the flags unmodified
inside a getbufferproc.
--
assignee: - docs@python
components: +Documentation
nosy: +docs@python
resolution: not a bug -
stage: - needs patch
versions: +Python 3.4, Python
Stefan Krah added the comment:
Isn't PyLong_FromUnsignedLongLong() still involved through spec_add_field()?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15993
Stefan Krah added the comment:
I ran a quick test with profile-guided optimization (PGO, pronounced pogo),
which has supposedly been improved since VC9, and
+saw a very unscientific 20% speed improvement on pybench.py and 10% size
reduction in python35.dll. I'm not sure what we used
+to get
Stefan Krah added the comment:
Let's open a new issue for system load detection. This one is not asyncio
specific.
--
resolution: - not a bug
stage: needs patch -
status: open - closed
___
Python tracker rep...@bugs.python.org
http
Stefan Krah added the comment:
Sunny, is there a definition of visible positional fields? Currently,
it seems to me that in os.stat_result we have the opposite problem, namely
visible non-positional fields:
For example, st_atime_ns is visible but not indexable:
os.stat_result(st_mode=33188
Stefan Krah added the comment:
OverflowError vs. ValueError is a debatable issue (msg215873). In my
view ValueError should be raised in most of the cases.
I do not see anything wrong with the docs though, since the link
you posted talks about arithmetic operations.
--
nosy: +skrah
Stefan Krah added the comment:
While NumPy is of course not normative, this is what they do:
numpy.random.triangular(left=1, right=2, mode=0)
Traceback (most recent call last):
File stdin, line 1, in module
File mtrand.pyx, line 3218, in mtrand.RandomState.triangular
(numpy/random/mtrand
Stefan Krah added the comment:
Hi Andrew. Did you by any chance sign the contributor agreement?
[It's perfectly okay if you don't want to, but then we cannot use
the patch from #20230.]
--
___
Python tracker rep...@bugs.python.org
http
Stefan Krah added the comment:
This might be out of date: _decimal has never implemented alternate
formatting and so far there have been no reported issues.
Another data point: Go apparently implements alternate formatting
only for octal, hex and strings:
http://golang.org/pkg/fmt/
So I'm
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16442
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18061
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20260
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19463
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15989
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20015
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19533
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19531
___
___
Python-bugs-list
Stefan Krah added the comment:
memoryobject.c is converted with a minimal patch (I would like to keep
100% code coverage for the file).
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20186
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20177
___
___
Python-bugs-list
Stefan Krah added the comment:
I've run Evgeniy's example under Valgrind and changed it to import
various C extensions. Unfortunately they all leak more or less, so
perhaps we can revisit this when (if?) the PEP 3121 and PEP 384
changes have been implemented
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16594
___
___
Python-bugs-list
Stefan Krah added the comment:
I won't have time to work on this. It would also be an option to do
these checks in test_capi.
--
resolution: - later
stage: patch review - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16533
___
___
Python-bugs-list
Stefan Krah added the comment:
Since this is 2.7 and an exotic system, I'm removing myself from the nosy list.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16533
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18777
___
___
Python-bugs-list
Stefan Krah added the comment:
The HP-UX issue is fixed. Are we leaving this open for IRIX?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16442
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3539
___
___
Python-bugs-list
Stefan Krah added the comment:
The original problem is fixed, but a similar one exists with
testembed (see msg113305 for instructions):
gcc -pthread -Xlinker -export-dynamic -o Modules/_testembed
Modules/_testembed.o libpython3.5dm.a -lpthread -ldl -lutil -lm
gcc: error: Modules
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20128
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12619
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16124
___
___
Python-bugs-list
Stefan Krah added the comment:
This is actually a lot of work, I don't think I'll have time for it.
Please just reopen if you think there's a chance that someone will take the
task.
--
resolution: - wont fix
stage: - resolved
status: open - closed
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15871
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16108
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20051
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13669
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2552
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
--
resolution: - wont fix
stage: needs patch - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13869
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6467
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7836
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4999
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12923
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7424
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6895
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14341
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5619
___
___
Python-bugs-list
1301 - 1400 of 3373 matches
Mail list logo
