Stefan Krah added the comment:
> PyUnicode_EncodeDecimal() is either unnecessary or should be exposed
> as a codec.
I'm depending on PyUnicode_EncodeDecimal in cdecimal. In fact, it saved
me quite a bit of trouble. I wouldn't be surprised if other extension
writer
Stefan Krah added the comment:
[Antoine]
> I didn't want to mess with these things too much. I guess you can try
> and we'll see.
You're right, it's better not to touch the Darwin stuff.
The 2.7 buildbots are green (including the FreeBSD ones!). I also
tested
Stefan Krah added the comment:
> (Anyone knows whether Arabic numbers are written right to left or left
> to right? What is the proper decimal point character?)
Thousands separator: U+066C
Decimal point: U+066B
١٢٣٬١٢٣٫١٢ should be: 123,123.12
Wikipedia says that digits are arran
Stefan Krah added the comment:
> UnicodeEncodeError: 'decimal' codec can't encode character '\u066b'
Hmm, looks like a bug? I think U+066B is correct.
--
___
Python tracker
<ht
Stefan Krah added the comment:
Without the patch, you see the warning if test_build_ext is run in
verbose mode. With the patch, the warning disappears.
--
___
Python tracker
<http://bugs.python.org/issue9
Stefan Krah added the comment:
Alexander Belopolsky wrote:
> On Thu, Dec 2, 2010 at 4:34 PM, Marc-Andre Lemburg
> wrote:
> ..
> > * Please change the API _PyUnicode_NormalizeDecimal() to
> > PyUnicode_ConvertToASCIIDecimal() - that's closer to what
> > i
New submission from Stefan Krah :
I'm not sure if this is a documentation issue or a bug. If watchexp=0,
quantize() also allows any number of digits:
>>> x = Decimal("6885998238912213556789006667970467609814")
>>> y = Decimal("1e2")
>>> x.q
Stefan Krah added the comment:
NaNs, however, are decapitated:
>>> x = Decimal("NaN5357671565858315212612021522416387828577")
>>> y = 0
>>> x.quantize(y, watchexp=0)
Decimal('NaN8315212612021522416387828577')
--
__
Stefan Krah added the comment:
Before anyone does any further testing:
Tarek, can this go into distutils 2.7/3.2 (after 3.2 has been released)?
Due to the popularity of this issue I think it might be worthwhile to
make an exception and ignore the distutils freeze
Stefan Krah added the comment:
[Alexander]
if sys.getenv('PYTHONSEGVHANDLER'):
import segvhandler
segvhandler.enable()
+1
If this doesn't find support, I'd name sys.setsegfaultenabled()
sys.setsegvhandlerenabled() or sys.enable_segvhandler().
---
Stefan Krah added the comment:
STINNER Victor wrote:
> Note: To avoid the signal-safe requirement, another solution is to use
> sigsetjmp()+siglongjmp().
FWIW, there is a caveat in the OpenBSD man page concerning the use of
siglongjmp():
http://www.openbsd.org/cgi-bin/man.cgi
New submission from Stefan Krah :
When CFLAGS are set, distutils drops -fno-strict-aliasing (among other
flags):
$ python2.7 setup.py build
...
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -fPIC -I./src -I/usr/local/include
-I/usr/local/include
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue9880>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Stefan Krah added the comment:
I narrowed this issue down to -ftree-vectorize, which is part of
-O3.
--
___
Python tracker
<http://bugs.python.org/issue9
Stefan Behnel added the comment:
I've extracted and fixed the part of this patch that implements the slice
object cache. In particular, PySlice_Fini() was incorrectly implemented. This
patch applies cleanly for me against the latest py3k branch.
--
Added file: http://bugs.pytho
Stefan Krah added the comment:
If OrderedDict is used, the test case quickly uses 8GB of memory. With
this change (I'm not suggesting this as a fix!), the timings are normal:
Index: Lib/ConfigParser.py
===
--- Lib/ConfigPars
Stefan Behnel added the comment:
> Any benchmark numbers for the slice cache?
I ran the list tests in pybench and got this:
Test minimum run-timeaverage run-time
thisother diffthisother d
Stefan Behnel added the comment:
There's a "PyObject_Del(obj)" in all code paths.
--
___
Python tracker
<http://bugs.python.org/issue10227>
___
___
Stefan Behnel added the comment:
Here are some real micro benchmarks (note that the pybench benchmarks actually
do lots of other stuff besides slicing):
base line:
$ ./python -m timeit -s 'l = list(range(100)); s=slice(None)' 'l[s]'
100 loops, best of 3: 0.464 usec pe
Stefan Behnel added the comment:
Here's another base line test: slicing an empty list
patched:
$ ./python -m timeit -s 'l = []' 'l[:]'
1000 loops, best of 3: 0.0847 usec per loop
original:
$ ./python -m timeit -s 'l = []' 'l[:]'
1000 l
Stefan Behnel added the comment:
> of course, this will not help for other common cases such as l[x:x+2]
... which is exactly what this slice caching patch is there for. ;-)
--
___
Python tracker
<http://bugs.python.org/issu
Stefan Behnel added the comment:
A quick test against the py3k stdlib:
find -name "*.py" | while read file; do egrep '\[[-0-9]*:[-0-9]*\]' "$file";
done | wc -l
This finds 2096 lines in 393 files.
--
___
Python tr
New submission from Stefan Behnel :
Follow-up to ticket 10227. The following facts seem to indicate that it would
be worth caching constant instances of the slice type, such as in [:] or [:-1].
with cached slice instance:
$ ./python -m timeit -s 'l = list(range(100)); s=slice(None)&
Stefan Behnel added the comment:
Created follow-up issue 11107 for caching constant slice objects.
--
___
Python tracker
<http://bugs.python.org/issue10
Stefan Behnel added the comment:
Erm, issue 10227.
--
___
Python tracker
<http://bugs.python.org/issue11107>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
Hmm, ok, but AFAICT, your patch was rejected rather because of the way it
approached the problem, not so much because of the issue itself.
Plus, the fact that Python 3 requires slices in more places than Python 2
(which had the lower level getslice protocol
Stefan Krah added the comment:
This seems to be a duplicate of #7424.
--
nosy: +skrah
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> segmentation fault in listextend during install
___
Py
Stefan Krah added the comment:
See also:
http://gnats.netbsd.org/42627
--
nosy: +H.Xu, haypo, loewis, skrah
___
Python tracker
<http://bugs.python.org/issue7
New submission from Stefan Krah :
Hi,
to_integral() should behave like quantize() for negative exponents:
"Otherwise (the operand has a negative exponent) the result is the
same as using the quantize operation using the given operand as the
left-hand-operand, 1E+0 as the right-hand-op
New submission from Stefan Krah :
Another exciting corner case in plus/minus:
"The operations are evaluated using the same rules as add and subtract;
the operations plus(a) and minus(a) (where a and b refer to any numbers)
are calculated as the operations add(’0’, a) and subtract(’
Stefan Krah added the comment:
Éric, the Debian patch looks good to me and it solves my build problem.
The only question I have is why EXTRA_CFLAGS still go behind CFLAGS
and cannot be overridden via the environment.
But as it is, the patch is an improvement. I'm attaching the version
fo
Stefan Krah added the comment:
Antoine Pitrou wrote:
> Why is OPT duplicated in get_config_vars(...)?
I missed that, thanks.
> Why do OPT and BASECFLAGS environ vars override their Makefile values
> instead of accumulating with them?
I think it would go too far to append in three p
Stefan Krah added the comment:
EXTRA_CFLAGS were removed in r38848. Is it necessary to configure
OPT, BASECFLAGS and EXTRA_CFLAGS via the environment? I think it
might be sufficient to take CFLAGS from the Makefile and append
the environment CFLAGS.
Chris, would the new minimal patch solve
Stefan Krah added the comment:
For the record, I prefer Python's behavior. The quantize() definition
does not work well for arbitrary precision input and leads to situations
like:
Precision: 1
Maxexponent: 1
Minexponent: -1
tointegral 101 -> 101
tointegral 101.0
Stefan Krah added the comment:
The patch and the test cases look good, but the implicit context must
be looked up earlier now (see the altered patch).
I just realize that there aren't any regression tests for this sort
of situation, since for the main tests we are only testing the co
Stefan Krah added the comment:
Chris Lambacher wrote:
> I was cross-compiling to a target architecture that does not support
> the -march option so I would not be able to provide a different one
> as override.
Just out of curiosity: You are cross-compiling a C-extension? How can
yo
New submission from Stefan Krah :
Due to an integer overflow in unicode_hash, the python interpreter
crashes if built with -ftrapv:
./configure --with-pydebug CFLAGS="-ftrapv"
Starting program: /home/stefan/svn/py3k/python
[Thread debugging using libthread_db enabled]
Progra
Stefan Krah added the comment:
Ok, this is known, see #1621. Closing.
--
resolution: -> duplicate
status: open -> closed
superseder: -> Do not assume signed integer overflow behavior
___
Python tracker
<http://bugs.python.or
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue1621>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Stefan Krah added the comment:
Marc-Andre Lemburg wrote:
>
> Marc-Andre Lemburg added the comment:
>
> Could you try the same in Python 2.7 ?
It's the same, just in stringobject.c. Many hash functions have this issue.
> The overflow is intended (after all, it's
New submission from Stefan Behnel :
During installation of Python packages (setup.py install or bdist), distutils
puts .pyc files into the installed source directory, instead of moving them
into __pycache__. This may mean that they are not getting used after
installation (with potentially no
Stefan Behnel added the comment:
Here's a patch. I basically copied over the way py_compile determines the .pyc
file name.
It works for me for a "normal" installation. However, I couldn't test it with
"-O", as 2to3 crashes for me when I enable it during i
New submission from Stefan Behnel :
When running a distutils installation of Cython (which uses lib2to3) as
"python3.2 -O setup.py bdist", I get this:
Skipping implicit fixer: buffer
Skipping implicit fixer: idioms
Skipping implicit fixer: set_literal
Skipping implicit fixer
New submission from Stefan Behnel <[EMAIL PROTECTED]>:
The following fails in Py3.0a5:
>>> import re
>>> re.search(b'(\d+)', b'-2.80 98\n')
I get a TypeError: "Can't convert 'int' object to str implicitly&
New submission from Stefan Behnel <[EMAIL PROTECTED]>:
Using 3.0a5, the following code crashes in vgetargskeywords (getargs.c:1542)
>>> d = {b"encoding": "abc"}
>>> str(b"abc", **d)
It should raise a TypeError instead, i.e. line 1535 s
New submission from Stefan Behnel <[EMAIL PROTECTED]>:
While porting the code that Cython generates to Py3a5 (almost completed,
BTW), I noticed a problem with class creation. We are currently using
this call to create a new class in Py3:
PyObject_CallFunctionObjArgs((PyObject *)&P
Stefan Behnel <[EMAIL PROTECTED]> added the comment:
Ah, I now see what the actual problem is. Byte strings return the byte
value on indexing.
Changing the title accordingly.
--
title: re module fails to handle digits in byte strings -> re module fails to
handle byt
Stefan Behnel <[EMAIL PROTECTED]> added the comment:
Sorry, the bug was in Cython, which didn't call InstanceMethod().
Please ignore.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
New submission from Stefan Behnel <[EMAIL PROTECTED]>:
The method cache is deactivated in current Py3. As Lisandro Dalcín
noticed, the following code in typeobject.c always returns false for a
Py3 identifier:
#define MCACHE_CACHEABLE_NAM
New submission from Stefan Behnel <[EMAIL PROTECTED]>:
Here is a fix for Objects/classobject.c in Py3.0a5 that fixes a ref
count crash for classmethods.
--
components: Interpreter Core
files: instancemethod-fix.patch
keywords: patch
messages: 67334
nosy: scoder
severity: normal
Stefan Behnel <[EMAIL PROTECTED]> added the comment:
Here is a patch that fixes this.
--
keywords: +patch
Added file: http://bugs.python.org/file10435/py3k-method-cache-fix.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Stefan Behnel <[EMAIL PROTECTED]>:
Here is a patch that makes this function public. This allows C code to
correctly taint a type after updating its attributes or base classes.
--
components: Interpreter Core
files: pytype_modified.patch
keywords: patch
me
New submission from Stefan Behnel <[EMAIL PROTECTED]>:
Similar to the "decref before set" issue solved by Py_CLEAR(), the code
in typeobject.c calls DECREF in the middle of a cache update. This
leaves one cache entry in an invalid state during the DECREF call, which
might r
New submission from Stefan Behnel <[EMAIL PROTECTED]>:
Here is a patch that removes three unused fields from the
PyNumberMethods struct in Py3. Since two fields were already removed
(one even before the ones this patch removes), there is no way existing
Py2 C code that uses this struct ca
Stefan Behnel <[EMAIL PROTECTED]> added the comment:
Ok, I buy that argument. The patch may be considered a code uglification
then.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Stefan Behnel <[EMAIL PROTECTED]> added the comment:
This seems to have been applied in current SVN.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Stefan Behnel <[EMAIL PROTECTED]>:
Running a doctest with Py2 syntax in Py3 currently involves either
running the 2to3 tool by hand or writing code to convert the doctest
using lib2to3, and then running the modified version. This basically
pushes the burden of automatin
New submission from Stefan Behnel <[EMAIL PROTECTED]>:
Here is a patch against the current PEP 3118 that removes the LOCK flag.
It follows this discussion on the Py3k mailing list:
http://comments.gmane.org/gmane.comp.python.python-3000.devel/13409?set_lines=10
It has not yet been ap
Stefan Behnel <[EMAIL PROTECTED]> added the comment:
As a quick summary of the problems with the current PEP:
1) Many use cases will not require any locking at all, either because
they run single-threaded with a short-read/short-write pattern, or
because they do not write at all.
2)
Stefan Behnel <[EMAIL PROTECTED]> added the comment:
:) sorry, that's the problem when you don't have commit rights and leave
the changes in your local copy.
So this is still an open issue that should be fixed before beta1, thanks.
___
Python
Stefan Behnel <[EMAIL PROTECTED]> added the comment:
Here is a patch that removes all occurrences of the locking protocol
from the current py3k branch code base.
There are still some issues in memoryobject.c:
- there was an occurrence of PyBUF_SHADOW that might have to be h
Stefan Behnel <[EMAIL PROTECTED]> added the comment:
While PyUnicode_AsStringAndSize() may be a better solution if the length
is required, PyUnicode_AsString is enough() when it is not required. So
I don't buy that argument. Since there are dedicated UTF-8 encoding
functions, both fu
Stefan Behnel <[EMAIL PROTECTED]> added the comment:
I would accept that if this had been done in all cases, but as I wrote
in my first comment, the previously existing slot "nb_divide", which
comes *before* the named ones, has already been removed, so there is no
way existing P
Stefan Behnel <[EMAIL PROTECTED]> added the comment:
As noted in issue2997, the nb_divide slot (4th field!) has already been
removed, so Py2 code has to be adapted anyway. I therefore recommend to
just remove all unused fields to get a clean struct for Py3.
--
nosy: +
Stefan Behnel <[EMAIL PROTECTED]> added the comment:
The change that removed the nb_divide and nb_inplace_divide members is here:
http://svn.python.org/view?rev=43285&view=rev
http://svn.python.org/view/python/branches/p3yk/Include/object.h?rev=43285&view=diff&r1=43285&r
New submission from Stefan Behnel <[EMAIL PROTECTED]>:
operator.delslice() and friends were removed in Python 3.0, as the
underlying object methods no longer exist. In the same way that the
slicing special methods were deprecated in favour of the item methods
should the functions in the op
New submission from Stefan Behnel <[EMAIL PROTECTED]>:
I get a reproducible crash under Linux when running the test cases of
lxml's trunk in Py3b2. As usual with these things, it's not reproducible
when running the crashing test by itself, only when it hits the test
during th
Stefan Behnel <[EMAIL PROTECTED]> added the comment:
Thanks a lot for the analysis. I was considering that this was a problem
with Cython, but since this was the first time I got a crash on this
(even Py3.0b1 didn't expose this), I wanted to ask here first.
Your explanation soun
Stefan Behnel <[EMAIL PROTECTED]> added the comment:
Also, the implementation does not follow the revised buffer PEP 3118. It
still calls get/releasebuffer(NULL) to acquire a lock, which is no
longer allowed by the buffer protocol.
I think this should become a release blocker for the las
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue2531>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Stefan Krah added the comment:
This is what Valgrind complains about:
==4750== 3,456 (1,440 direct, 2,016 indirect) bytes in 30 blocks are definitely
lost in loss record 3,302 of 3,430
==4750==at 0x4C2412C: malloc (vg_replace_malloc.c:195)
==4750==by 0x41B7B5: PyMem_Malloc (object.c
Stefan Krah added the comment:
Mark, thanks for the explanation! - You can generate suppressions for the
Misc/valgrind-python.supp file, but you have to know exactly which errors can
be ignored.
Going through the Valgrind output again, it looks like most of it is about what
you already
Stefan Krah added the comment:
With the latest dtoa.c, your non-caching pow5mult and a quick hack for Balloc
and Bfree I get zero (dtoa.c related) Valgrind errors.
So the attached memory_debugger.diff is pretty much all what's needed for
Valgrind.
--
Added file:
Stefan Krah added the comment:
All outstanding issues mentioned here have been solved in Rev. 77696:
(1) New ANSI path for unknown 64bit platforms (ia64 and Alpha build
without problems now).
(2) Unified tests for decimal and cdecimal.
(3) Documentation for cdecimal.
Other
Stefan Krah added the comment:
(6) Yes, I think that is logical. In cdecimal, I accept integers for all unary
methods except is_canonical and number_class.
--
___
Python tracker
<http://bugs.python.org/issue7
Stefan Krah added the comment:
I'm new to this thread, so I hope I didn't miss anything that has been
said already. I don't fully understand why TypeError cannot be raised
in 2.x. The 2.6 documentation for tp_richcompare says:
"If you want to implement a type for which o
Stefan Krah added the comment:
If none of you is working on it right now, I'll produce a new patch.
Mark, how about this:
def __add__(self, other, context=None, raiseit=False):
"""Returns self + other.
-INF + INF (or the reverse) cause Inv
Stefan Krah added the comment:
Juan: Sure, take your time. :) I just wanted to know if you were still busy
with it.
--
___
Python tracker
<http://bugs.python.org/issue7
Stefan Krah added the comment:
Marc-Andre,
on 64-bit Ubuntu, this method ...
BASECFLAGS=-m32 LDFLAGS=-m32 ./configure
... results in a gcc segfault:
gcc -pthread -m32 -Xlinker -export-dynamic -o python \
Modules/python.o \
libpython3.2.a
Stefan Krah added the comment:
The builds are almost identical, so I attach a diff of the build output.
For both builds, I used a fresh Python-3.1.1 directory. This looks
suspicious:
-checking whether va_list is an array... yes
+checking whether va_list is an array... no
For completeness
Changes by Stefan Krah :
Removed file:
http://bugs.python.org/file16023/basecflags-vs-patch-3.1.1-builddiff.txt
___
Python tracker
<http://bugs.python.org/issue1628
Changes by Stefan Krah :
Added file:
http://bugs.python.org/file16024/basecflags-vs-patch-3.1.1-builddiff.txt
___
Python tracker
<http://bugs.python.org/issue1628
Stefan Krah added the comment:
(1) I can get around the configure problem by patching configure.in,
meaning that va_list is detected correctly now. Perhaps BASECFLAGS
should be used by default for the compile tests?
(2) Now I run into the problem that distutils somehow ignores the
Stefan Krah added the comment:
I also think that the added docstrings are not really necessary.
Another thing: I forgot to mention 'canonical' in the list of functions
that should only accept Decimals. As with the other two (number_class
and is_canonical), this is a matter of taste.
Stefan Krah added the comment:
Yes, indeed 'canonical' can be justified to take an integer, if we interpret
the spec as:
'canonical' takes an operand and returns the preferred _decimal_
encoding of that operand.
But then 'is_canonical' should return false
New submission from Stefan Krah :
As discussed privately, the following test cases should raise TypeError
(currently ValueError):
self.assertRaises(TypeError, Decimal, (0., (4, 3, 4, 9, 1), 2) )
self.assertRaises(TypeError, Decimal, (Decimal(1), (4, 3, 4, 9, 1), 2))
self.assertRaises(TypeError
Stefan Behnel added the comment:
Looks like this is one of those bugs that run away when you look too close...
I can get it to crash reliably for me with the latest py3k branch (and all
Python 3.x release versions) when I run the test suite completely, so here's a
new recipe. The inte
Stefan Behnel added the comment:
I'll add a couple of comments about the relevant parts of the code that appears
to trigger the crash.
The code runs through the parse tree and applies transformations to it.
1) For node matching, we use a dispatcher (in Visitor.py) that looks up methods
Stefan Krah added the comment:
I wonder if this is technically a bug. The stream is not opened for reading and
yet you do an fread. I quickly glanced through the
C-Standard and I did not find an _explicit_ paragraph that this is
undefined behavior, but personally I'd expect it
Stefan Krah added the comment:
Bug or not, this can be handled since fread sets EBADF on Windows.
--
keywords: +patch
Added file: http://bugs.python.org/file16071/fileread-errno.patch
___
Python tracker
<http://bugs.python.org/issue5
Stefan Krah added the comment:
I see that a complete errno based solution would get messy. To avoid
interfering with EAGAIN special cases, this would be needed:
#if defined(EBADF)
#define ERRNO_EBADF(x) ((x) == EBADF)
#else
#define ERRNO_EBADF(x) 0
#endif
Then, additional checks would need to
Stefan Krah added the comment:
An errno+ferror approach works except for two cases:
(1) MS fgets() does not consider reading from a write-only stream
an error. While annoying, I think this is standard conforming.
(2) OpenSolaris sets errno unreliably after getc.
I do not know how
Changes by Stefan Krah :
Added file: http://bugs.python.org/file16104/errno-ebadf-tests.patch
___
Python tracker
<http://bugs.python.org/issue5677>
___
___
Python-bug
Stefan Krah added the comment:
The new patch takes over the logic from fileio.c. Tested on Linux, Windows
x86/x64 and OpenSolaris.
--
Added file: http://bugs.python.org/file16115/add-readable-writable.patch
___
Python tracker
<h
Stefan Krah added the comment:
I tested bsd3.diff on OpenBSD-4.4/py3k and it works fine. ncurses
doesn't build and I get a libssl assertion failure in test_ftplib,
but without the patch I can't build py3k at all.
This is a significant improvement, so +1 for applying
Stefan Krah added the comment:
Thanks Antoine, I fixed both issues.
--
Added file: http://bugs.python.org/file16140/add-readable-writable2.patch
___
Python tracker
<http://bugs.python.org/issue5
Stefan Krah added the comment:
Ok, I'll fix that. Perhaps I should also remove the comment in err_mode(). I
wonder if the ValueError in fileio.c is intentional:
>>> import io
>>> f = io.open("testfile", "w")
>>> f.write("xxx")
3
&
Changes by Stefan Krah :
Added file: http://bugs.python.org/file16141/add-readable-writable3.patch
___
Python tracker
<http://bugs.python.org/issue5677>
___
___
Python-bug
New submission from Stefan Krah :
I think that certain FileIO methods should raise IOError instead of
ValueError when a file operation is attempted with the wrong mode.
The methods of IOBase are documented to raise IOError in these situations.
>>> import io
>>> f = io.o
Stefan Krah added the comment:
Thanks for reporting. This looks like a duplicate of issue3920.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue7
501 - 600 of 4949 matches
Mail list logo
