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 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 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
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 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
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 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 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 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 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
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 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 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 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
Stefan Krah added the comment:
Argh, forget the second Haskell example: inf / 0 is fine.
--
___
Python tracker
<http://bugs.python.org/issue22444>
___
___
Pytho
Stefan Krah added the comment:
Ok, so it is a debug thing in the current NumPy sources.
IMO ultimately the getbufferproc needs to return valid strides, even
if the first value isn't used.
For that matter, the getbufferproc is free to translate the multi-
dimensional corner case array to
Stefan Krah added the comment:
I think it would help discussing your options if the patch passes test_buffer
first. Currently it segfaults because shape can be NULL. Also, code in
memoryobject.c relies on the fact that ndim==0 means contiguous.
Then, it would help enormously if you give
Stefan Krah added the comment:
Thanks! I still have to review the patch in depth, but generally
I'm +1 now for relaxing the contiguity check.
Curiously enough the existing code already considered e.g. shape=[1],
strides=[-5] as conti
Stefan Krah added the comment:
Since the functions in abstract.c have been committed by Travis Oliphant:
Could there have been a reason why the {shape=[1], strides=[-5]}
case was considered but the general case was not?
Or is it generally accepted among the numpy devs that not considering
the
Stefan Krah added the comment:
Alexander Belopolsky wrote:
> Raymond suggested that "The PEP 3141 should be revised to say that floor
> division is defined to return a value that is *equal* to an Integral".
I guess it should say "equal to an Integral or a special value&
New submission from Stefan Krah:
The following URL contains copyrighted verbatim text from bytereef.org:
https://pypi.python.org/pypi/m3-cdecimal
I'm not surprised, since the ongoing Walmartization of Open Source
has little regard for authors.
--
messages: 227461
nosy:
Stefan Krah added the comment:
I don't see a license on PKG-INFO itself. Furthermore, even if
it is legal, it (again) shows an utter disregard for authors and
their stated preferences.
I'm not surprised though, given that even existing names are
reassigned in an autocrat
Stefan Krah added the comment:
Sorry, Donald, the actions on PyPI deserve wider exposure.
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/issu
Stefan Krah added the comment:
Yeah right, obviously I don't *really* care about the issue (ethics
in open source software, in case you did not understand).
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
I'm seeing the same, it could be an Ubuntu issue:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1348275
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
Ok, here's my take on the situation:
1) As far as Python is concerned, shape[0] == 1 was already special-cased, so
people could not rely on canonical Fortran or C strides anyway.
2) Accessing an element via strides should be done using PyBuffer_GetPo
Stefan Krah added the comment:
Sometimes I've used memoryview slices to model pointers in C code.
memoryview could have limited number methods for pointer arithmetic on the
buf pointer. Arithmetic would return new slices, so in fact everything would
be safe with respect to bounds checkin
Stefan Krah added the comment:
FWIW, I think it would be good to make this change early in the
3.5 release cycle, so issues can be found. Sebastian, do you
have an idea when the change will be decided in numpy?
Regarding the discussion here ...
https://github.com/numpy/numpy/issues/5085
Stefan Krah added the comment:
Okay, the whole thing isn't that urgent either.
Sorry for the confusion w.r.t slicing: I misremembered what the
latest numpy version did:
a)
>>> x = np.array([[1,2,3,]])
>>> x.strides
(9223372036854775807, 8)
b)
>>&g
Stefan Krah added the comment:
libmpdec has always been a separate project, predating the integration
into Python-3.3. Before the Python-3.3 release, Jim Jewett suggested
a cleaner library/module separation (and he was right, it made the
code much more readable).
Then distributors wanted
Stefan Krah added the comment:
Of course Windows is a problem. I do not know how to implement
--with-system-libmpdec on Windows.
--
___
Python tracker
<http://bugs.python.org/issue22
Stefan Krah added the comment:
Trent, did the HPUX CFLAGS/LDFLAGS change on the buildbots? I think
_decimal used to compile on the PA-RISC bot, but now there is an error.
Perhaps -AC99 or something like that is missing.
--
___
Python tracker
<h
Stefan Krah added the comment:
Antoine, could you add --with-system-libmpdec to my FreeBSD and Fedora
bots? Sorry for bothering you with all these obscure options. :)
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue19
New submission from Stefan Krah:
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/3601/steps/test/logs/stdio
==
FAIL: test_wait_for_handle (test.test_asyncio.test_windows_events.ProactorTests
Changes by Stefan Krah :
--
keywords: +buildbot
___
Python tracker
<http://bugs.python.org/issue19952>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Antoine Pitrou wrote:
> Should be done now. Can you check they work fine?
Thank you! Works OK.
--
___
Python tracker
<http://bugs.python.org/issu
Stefan Krah added the comment:
Matthias, my target is to release mpdecimal-2.4 on January 9th 2014.
I saw that you started to package mpdecimal-2.3:
http://packages.debian.org/pt/source/sid/misc/mpdecimal
I hope that it can be changed to 2.4: Packaging 2.3 would create
some confusion
2301 - 2400 of 3396 matches
Mail list logo
