Stefan Krah added the comment:
Memoryview sends a *request* to ctypes to fill in a Py_buffer struct according
to the buffer *protocol*. IOW, memoryview knows nothing about ctypes.
For some reason ctypes fills in 'B' as the format if _pack_ is set. I do not
know if that is intended
Stefan Krah added the comment:
Éric, thanks for taking a look.
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Stefan Behnel added the comment:
This is a duplicate of issue17011.
--
___
Python tracker
<http://bugs.python.org/issue19862>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
Did you use --suppressions=Misc/valgrind-python.supp?
--
___
Python tracker
<http://bugs.python.org/issue19893>
___
___
Python-bug
Stefan Krah added the comment:
Also, you have zero "definitely lost". "possibly lost" is not
particularly informative in the context of running Python:
These are almost certainly false positives.
--
___
Python tracker
<
Stefan Krah added the comment:
Did you compile Python --with-valgrind?
--
___
Python tracker
<http://bugs.python.org/issue19893>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
If performance is the reason for the feature: My impression is that
the goal of the struct module is not necessarily top performance.
E.g. in memoryview the custom unpackers for comparisons are 30-60 times
faster than using the struct module.
--
nosy
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)
[]
>>>
-
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
Changes by Stefan Krah :
--
assignee: docs@python -> skrah
___
Python tracker
<http://bugs.python.org/issue21778>
___
___
Python-bugs-list mailing list
Un
Stefan Behnel added the comment:
Your code adds a lot of new code. Why is that necessary? Can't the new feature
be integrated into the existing code?
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
Since the rewrite in 3.3 many memoryview tests are actually in test_buffer.py.
--
___
Python tracker
<http://bugs.python.org/issue21
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() i
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
Changes by Stefan Krah :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue21778>
___
___
Python-bugs-list
Stefan Krah added the comment:
6ab3193e890e exposes the issue.
--
nosy: +pitrou, skrah
___
Python tracker
<http://bugs.python.org/issue21897>
___
___
Python-bug
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:
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 trac
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
<h
New submission from Stefan Tatschner:
Hi,
i just discovered a missing colon in the docs. I have created a patch for this.
Stefan
--
assignee: docs@python
components: Documentation
files: fixed-missing-colon.patch
keywords: patch
messages: 222341
nosy: docs@python, rumpelsepp
priority
Stefan Krah added the comment:
Did you mean to upload a patch?
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue21922>
___
___
Python-bugs-list m
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 Behnel added the comment:
"you'd be surprised how much cheaper indexing a sequence is relative to
dictionary access"
This is a bit off-topic (and I realise that this ticket is closed now), but the
difference isn't really all that large:
$ python3.4 -m timeit -s &#
Stefan Behnel added the comment:
Ok. This has been idling long enough to just close it.
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
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:
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
<http://bugs.python.org/is
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 fro
Stefan Behnel added the comment:
Even if there is no way to explicitly request a RO buffer, the Py_buffer struct
that you get back actually tells you if it's read-only or not. Shouldn't that
be enough to enable this optimisation?
Whether or not implementors of the buffer protoco
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue7063>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
<http://bugs.python.org/issue15
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
<http://bugs.python.o
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:
>>&g
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
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
<http://bugs.python.o
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#te
Stefan Krah added the comment:
So I wonder why the benchmark suite says that the telco slowdown is
significant. :)
--
___
Python tracker
<http://bugs.python.org/issue22
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
___
Pyt
Stefan Behnel added the comment:
FWIW, functions in Cython (which C-level-inherit from PyCFunction) support weak
references just fine. Adding that as a general feature to PyCFunction sounds
like the right thing to do.
--
nosy: +scoder
___
Python
Stefan Behnel added the comment:
Patch looks ok. Not sure about the test dependency from test_weakref.py to
_testcapi, though. Is that module allowed to be used everywhere? Wouldn't it be
enough to test that one of the builtin functions is now weak referencible?
"len" seem
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
<http://bugs.python.org/issue18
Stefan Behnel added the comment:
Looks like a duplicate of issue 17781. Ubuntu already does this for their
builds and gets substantially better performance, so I can't see a reason why
CPython shouldn't just follow.
--
nosy: +scoder
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
<http://bugs.python.org/is
Changes by Stefan Krah :
Added file: http://bugs.python.org/file36378/api-demo[1].c
___
Python tracker
<http://bugs.python.org/issue22194>
___
___
Python-bugs-list mailin
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 c
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:
A modified version of telco.py (using floats instead of decimals) runs
about 5-6% slower with the change here.
--
___
Python tracker
<http://bugs.python.org/issue22
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 trac
Stefan Behnel added the comment:
> (for the record, the context is that we would like to support decimal objects
> efficiently in Numba)
Same for Cython, although I guess we wouldn't do more than shipping the
necessary declarations and (likely) also enable auto-coercion between th
Stefan Behnel added the comment:
The current implementation doesn't work with Unicode file paths. Try passing a
Unicode string e.g. as "cafile" into context.load_verify_locations(). It calls
PyString_AsEncodedObject() on it, which then fails with a PyErr_BadArgument()
on the e
Stefan Behnel added the comment:
I'm now getting duplicated slashes in URLs, e.g.:
https://new//foo.html
http://my.little.server/url//logo.gif
In both cases, the base URL that gets joined with the postfix had a trailing
slash, e.g.
"http://my.little.server/url/"; + "
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
&g
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
Stefan Krah added the comment:
Antoine Pitrou 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 to
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
<http://bu
Stefan Krah added the comment:
Antoine Pitrou 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_* functio
Changes by Stefan Krah :
--
components: +Library (Lib)
resolution: -> fixed
stage: -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.4
___
Python tracker
<http://bugs.python.or
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 bui
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
<http://bugs
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&
Stefan Krah added the comment:
Yeah, I know -- I have to release libmpdec-2.4.1. The bot is currently testing
the supported configuration that if _decimal fails to build, decimal.py should
be used automatically.
The tests fail due to #22280, otherwise the bot would be green even with the
Stefan Krah added the comment:
I agree. I plan to fix this as part of #19232. If decimal.py and
_decimal are split properly, these things show up immediately.
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/issue22
Changes by Stefan Krah :
--
dependencies: +Speed up _decimal import
___
Python tracker
<http://bugs.python.org/issue22284>
___
___
Python-bugs-list mailin
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
___
Pyth
Stefan Krah added the comment:
I think we have this behavior since 6c468df214dc and 227ce85bdbe0 (#17095).
--
nosy: +ned.deily, twouters
___
Python tracker
<http://bugs.python.org/issue22
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
<http://bugs.python.org/issue22
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
> ac
Stefan Behnel added the comment:
> Stefan (Behnel), could you comment on the strategy that you had in mind?
> Is it similar to module_get_symbol.diff or entirely different?
I agree with Antoine that a Capsule would work better here (and yes, the
performance problem of capsules is onl
Stefan Krah added the comment:
The behavior is according to the specification:
http://speleotrove.com/decimal/decarith.html
The idea behind it is that 1/0 can be reasonably defined as infinity,
whereas 0/0 is undefined. You can see that if you disable the exceptions:
>>> c = g
Stefan Krah added the comment:
According to IEEE 754-2008 binary floats should use the same exceptions
in this case.
7.2 Invalid operation
...
e) division: division(0, 0) or division(∞, ∞)
7.3 Division by zero
The divideByZero exception shall be signaled if and only if an
exact
Stefan Krah added the comment:
I've upgraded the system libmpdec to 2.4.1.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.pyth
Stefan Behnel added the comment:
I noticed this, too. I think it's due to the urllib changes in issue 22118.
--
components: +Library (Lib)
nosy: +pitrou, scoder
type: -> behavior
___
Python tracker
<http://bugs.python.org
Changes by Stefan Behnel :
--
nosy: -scoder
___
Python tracker
<http://bugs.python.org/issue20035>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Stefan Behnel:
"longintrepr.h" is a non-public header file (not included by Python.h) that
defines the inner struct layout of PyLong objects. Including it allows for very
fast access to "small" integers through ob_digit[0] when -1 <= Py_SIZE(n)
Stefan Behnel added the comment:
Were the tests in
http://bugs.python.org/file32591/urischemes.py
merged yet, that Nick Coghlan mentioned in
http://bugs.python.org/issue22118#msg225662 ?
--
___
Python tracker
<http://bugs.python.org/issue22
Changes by Stefan Krah :
Removed file: http://bugs.python.org/file36446/module_get_symbol.diff
___
Python tracker
<http://bugs.python.org/issue22194>
___
___
Python-bug
Stefan Krah added the comment:
Thanks, Stefan. So everyone agrees that Capsule is the right way for the API.
Then this issue is about making the libmpdec symbols public. I've tried
to produce a collision with duplicate symbols as outlined in msg176486,
but I haven't been successful
Stefan Behnel added the comment:
CPython 3.5, latest development versions. This started failing on August 21st,
presumably with the changes for issue 22118.
--
___
Python tracker
<http://bugs.python.org/issue22
Stefan Behnel added the comment:
Is this superseded by issue 22194 now or the other way round?
--
nosy: +scoder
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue15
Changes by Stefan Behnel :
--
nosy: +scoder
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Well, we have two issues now:
1) Make the _decimal API available via capsule.
2) Make the libmpdec symbols public (i.e. remove "GCC visibility push(hidden)"
from Modules/_decimal/libmpdec/mpdecimal.h.
The question here is now whether 2) is
Stefan Krah added the comment:
Also, they aren't safe with the Turkish "i".
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue22330>
___
__
Stefan Krah added the comment:
Unfortunately they seem to be part of the stable ABI (#18603).
--
___
Python tracker
<http://bugs.python.org/issue22330>
___
___
Stefan Krah added the comment:
Antoine Pitrou wrote:
> > large parts of the cdecimal on PyPI (which uses the incompatible
> > libmpdec-2.3) would need to be rewritten.
>
> Ah, so it has an incompatible ABI? That will complicate things a bit :-)
Yes, cdecimal on PyPI is slowe
Stefan Krah added the comment:
Sure, if there are people who write python3-only C modules (I can't think
of one right now).
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
The compatibility discussion was for the cdecimal-2.3 package that's
hosted on PyPI and used for Python 2.7. IOW, will people use a capsule
API that's Python-3 only?
Compatibility with pypy would be esote
Stefan Behnel added the comment:
Yes, please. The sequential build in distutils is very annoying.
(too late for Py3.4, though, I guess...)
--
nosy: +scoder
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue5
Stefan Krah added the comment:
I didn't add __all__ to _decimal because of this thread here:
https://mail.python.org/pipermail/python-dev/2001-February/012591.html
--
components: +Library (Lib)
dependencies: -Speed up _decimal import
resolution: -> fixed
stage: -> reso
Stefan Behnel added the comment:
Agreed that it's not a bug in CPython, but my guess is that it's not a bug in
NumPy either. The C function you call (which IIRC creates a new NumPy array)
almost certainly needs the GIL to protect it against race conditions, and since
you mentioned O
Stefan Krah added the comment:
We could speed up the import further by not importing collections
in _decimal. That could be done once structseq fully implements
the namedtuple protocol (for DecimalTuple).
--
___
Python tracker
<h
Stefan Krah added the comment:
I'm fine with closing this. The structseq issue is #1820.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http:
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue22444>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
There is another oddity: #12845. Does NumPy have a formal definition of
array contiguity somewhere?
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue22
Stefan Krah added the comment:
BTW, if you have NumPy installed and run test_buffer in Python3.3+,
numpy.ndarray has many tests against memoryview and _testbuffer.ndarray
(the latter is our exegesis of PEP-3118).
--
___
Python tracker
<h
Stefan Krah added the comment:
This was a bug in NumPy that has been fixed.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
versions: +Python 3.5 -Python 3.3
___
Python tracker
<http://bugs.python.or
Stefan Krah added the comment:
Thanks, #12845 is indeed fixed in NumPy.
Why does NumPy consider an array with a stride that will almost
certainly lead to undefined behavior (unless you compile with
-fwrapv) as valid?
In CPython we try to eliminate these kinds of issues (though
they may still
Stefan Krah added the comment:
Perhaps it's worth mentioning that several people on Python-ideas took the
opposite view: math.floor() should return a float.
PEP-3141 does not mention Infinities and NaNs:
"The Real ABC indicates that the value is on the real line, and supports
the
3401 - 3500 of 4952 matches
Mail list logo
