New submission from Stefan Krah:
There's a test_float failure on HPUX (and many compiler warnings):
test test_float failed -- Traceback (most recent call last):
File
"/home/cpython/buildslave/2.7.snakebite-hpux11iv3-ia64-1/build/Lib/test/test_float.py",
line 622, in test_
Stefan Krah added the comment:
Fixed in 2.7, 3.3 and 3.4.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue16535>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Stefan Krah:
==
FAIL: test_unknown_options (test.test_cmd_line.CmdLineTest)
--
Traceback (most recent call last):
File
"/srv/bui
Stefan Krah added the comment:
I wouldn't use "bytes-like object". One can certainly argue that *memoryview*
should be bytes-like as a matter of preference, but the buffer protocol
specifies strongly (or even statically) typed multi-dimensional arrays.
PEP-3118 Py_buffer structs
Stefan Krah added the comment:
Antoine Pitrou wrote:
> > PEP-3118 Py_buffer structs are essentially how NumPy works internally.
>
> Well, we should still write a Python documentation, not a NumPy
> documentation (on this tracker anyway). Outside of NumPy, there's li
Stefan Krah added the comment:
Antoine Pitrou wrote:
> > How about "object does not provide a byte buffer" for error messages
> > and "(byte) buffer provider" as a shorthand for "any buffer provider
> > that exposes its memory as a sequence of unsig
Stefan Krah added the comment:
For some reason ./configure detects x87-style-double-rounding=yes, but when
I compile the test manually with the same command line "cc -Ae -g", no
double rounding is detected.
--
___
Python trac
Stefan Krah added the comment:
This should be fixed now (see #6308).
--
nosy: +skrah
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> termios fix for QNX breaks HP-UX
___
Python tr
Stefan Krah added the comment:
The issue here is that the BASECFLAGS variable contains the mysterious
option -Olimit 1500, which makes the X87_DOUBLE_ROUNDING test fail (i.e.
X87_DOUBLE_ROUNDING is set to true when it should be false).
When BASECFLAGS is unset, test_float passes.
-Olimit
Stefan Krah added the comment:
The test still seems to fail on Fedora 16:
http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%202.7/builds/906/steps/test/logs/stdio
--
nosy: +skrah
___
Python tracker
<http://bugs.python.
Stefan Krah added the comment:
./configure is fixed, sys.float_repr_style is 'short' now.
I agree that it's not worth backporting Py_NAN fixes; I guess we can
close this then.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> c
Stefan Krah added the comment:
The gdb version is "GNU gdb (GDB) Fedora (7.3.50.20110722-16.fc16)", which
looks like either a pre-release of 7.4 or a patched version.
Testing for (gdb_major_version, gdb_minor_version) >= (7, 3) would fix the
specific failure on Fedora 16, but I don
Stefan Krah added the comment:
I'm using the .gdbinit solution on the Fedora buildbot now. Trying to
categorize gdb pre-releases and patched versions is probably not a good
use of time. ;)
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
I think this commit broke the --without-threads buildbot:
http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/3581/steps/test/logs/stdio
--
nosy: +skrah
___
Python tracker
<h
Stefan Krah added the comment:
I second Antoine's request for a PEP. I'm not only concerned about the DSL:
This approach may work for modules like posixmodule.c, where each function
is largely a self-contained unit wrapping some API function.
On the other hand, I don't want
Stefan Krah added the comment:
Here are some things that I'm interested in right now:
1) From what kind of data structure are signature objects generated?
2) Is there an easy way to do this manually?
3) Can at least part of the verboseness go into header files (virtually
Stefan Krah added the comment:
Larry Hastings wrote:
> I disagree that the Clinic DSL is "verbose". Certainly I find it
> more succinct than what we do now.
I was referring to the total size of the generated output, not to the DSL.
> On the other hand, the syntax you pro
Stefan Krah added the comment:
Gregory, I'm talking about the size of the *total output* of the tool, not
about the size of the actual DSL parts:
posixmodule.c: 1138211514+132 (2 functions)
_cursesmodule.c:3434 3499 +65 (1 function)
zlibmodule.c:
Stefan Krah added the comment:
Robin, if you use ...
[diff]
git = on
... in your .hgrc, then the bug tracker will automatically generate
a Rietveld review link (At least I think that's what prevents links
from being generated).
--
nosy: +
Stefan Krah added the comment:
Larry Hastings wrote:
> Finally, since you have not addressed it directly, let me ask you:
> are you interested in Clinic having a more boilerplate-friendly macro
> processing mode, with templates or recycling old entries or something?
> Or do you not
Stefan Krah added the comment:
Ezio, thanks for the Rietveld comments.
There are still unsupported None default values in the Context
constructor, so I'm leaving the issue open.
--
title: decimal.localcontext(None) fails when using the C accelerator module ->
decimal: Supp
Stefan Krah added the comment:
I think I've found all of them now. Closing.
--
assignee: -> skrah
components: +Library (Lib)
resolution: -> fixed
stage: test needed -> committed/rejected
status: open -> closed
versions: +Python 3.4
_
Stefan Krah added the comment:
``./configure --without-pymalloc'' fails here:
gcc -pthread -Xlinker -export-dynamic -o python Modules/python.o
libpython3.4.a -lpthread -ldl -lutil -lm
libpython3.4.a(sysmodule.o): In function `sys_getallocatedblocks':
/home/stefan/hg/c
Stefan Krah added the comment:
Antoine Pitrou wrote:
> Hmm, interesting. When built --without-pymalloc, we could make
> sys.getallocatedblocks() always return 0, or we could not define it all
> (which would make like a bit harder for regrtest). What do you think?
Given
Changes by Stefan Krah :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue16730>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
If Irix support is the reason for the Olimit test, perhaps we can limit
the check to Irix?
http://www.gossamer-threads.com/lists/python/dev/689524?do=post_view_threaded#689524
--
nosy: +skrah
___
Python tracker
<h
New submission from Stefan Krah:
This issue is for the _decimal specific parts from #4555. The patch
depends on _Pragma (C99) and gcc >= 4.0 for the contents of the pragma.
I think it will work for clang, too.
Should the libmpdec API symbols (i.e. the ones starting with mpd_*)
be hidden
Stefan Krah added the comment:
Adding everyone from issue #4555, in case you can think of a different
(portable) solution for hiding symbols (with minimal effort).
--
nosy: +christian.heimes, dmalcolm, doko, lemburg, loewis, pitrou
___
Python tracker
Stefan Krah added the comment:
Meador Inge wrote:
> Personally I prefer using attributes instead of pragmas. The GCC manual
> recommends such as well.
I followed www.akkadia.org/drepper/dsohowto.pdf . Drepper seems to be fine
with the use of pragmas in internal headers.
> There
Stefan Behnel added the comment:
Just for the record, I've compiled Raymond's roadmap version in Cython (with
only slight changes to make 'self.maxsize' a Py_ssize_t and using an external
.pxd for typing) and ran Serhiy's benchmark over it (Ubuntu 12.10, 64bit). Thi
New submission from Stefan Krah:
This is strictly a buildbot issue. #include seems broken on
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%203.3/builds/248/steps/compile/logs/stdio
In file included from /usr/include/ctype.h:83,
from
/usr/home
Stefan Behnel added the comment:
Any news on this?
--
___
Python tracker
<http://bugs.python.org/issue11379>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Krah :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Stefan Krah added the comment:
Hmm. Judging by the numbers for the Python version, my machine appears
to be slower than Stefan (Behnel)'s machine, and yet the C version is
much faster here than the posted Cython numbers.
If I adjust the results for the machine differences, the C version
Stefan Krah added the comment:
I've managed to build the Cython version now. It's in fact between 4 and 6
times slower here than the C version.
--
___
Python tracker
<http://bugs.python.o
Stefan Krah added the comment:
Thanks, it's really a FreeBSD issue then. I was wondering how this
could go undetected in a production release. The reason is probably
that __GNUC_STDC_INLINE__ (which libmpdec uses) is quite rare.
--
resolution: -> invalid
stage: -> committ
Stefan Krah added the comment:
On second thought, gcc defines __GNUC_STDC_INLINE__ to 1, so probably
libmpdec should do the same.
--
___
Python tracker
<http://bugs.python.org/issue16
Stefan Behnel added the comment:
Yep, I basically didn't do any optimisation, it's the plain Python code
compiled, just with the class being converted into an extension type.
--
___
Python tracker
<http://bugs.python.o
Stefan Krah added the comment:
Perhaps I misunderstood something, but test_decimal.py *is* using the
exact idiom from PEP-399 and it works. Why do you want to "fix" the
usage of this idiom?
--
nosy: +skrah
___
Python tracker
<http://bu
Stefan Krah added the comment:
I finally understood the issue. So this does not work:
./python -m unittest discover Lib/test/ 'test_dec*.py'
Neither does this:
./python -m unittest discover Lib/test/ 'test_multipro*.py'
And this fails, too (still hanging):
Changes by Stefan Krah :
--
nosy: +jkloth
___
Python tracker
<http://bugs.python.org/issue9709>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
I think this is the same as #9709. Please just reopen if it isn't.
--
nosy: +skrah
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> test_distutils warning: initfunc exported
New submission from Stefan Behnel:
Line 522 in test file Lib/test/test_pep380.py says:
trace.append("Should not have yielded:", y)
However, 'trace' is a list and list.append() only takes one parameter, so this
should read:
trace.append(&quo
Stefan Behnel added the comment:
If runtime checks are needed to prevent mixing arbitrary objects into the tree,
then I don't think they should be considered too costly.
I agree with Florent that this is worth reopening. It doesn't look like a
"Tests" bug to me rath
Stefan Behnel added the comment:
FWIW, PyPy has an (R)Python implementation already:
https://bitbucket.org/pypy/pypy/src/default/pypy/rlib/rrandom.py
--
nosy: +scoder
___
Python tracker
<http://bugs.python.org/issue16
Stefan Krah added the comment:
Yes, currently the C version is also used for unpickling. Actually
this problem was one of the reasons why _decimal sets its name to
"decimal".
from test.support import import_fresh_module
import pickle, sys
C = import_fresh_module('xml.et
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue16748>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Daniel Shahaf wrote:
> Is there a requirement that it loads a particular module? Would etree
> users notice the difference if pickle.load() returns an instance of the
> "other" Element implementation than the one they pickled?
Stefan Krah added the comment:
unicode-leak.patch doesn't fix #16143 though. unicode_empty and
unicode_latin1 need to be initialized, too.
Actually we could close this in favor of #16143.
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
Closing as a duplicate of #10156, which has several patches.
--
resolution: -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder: -> Initialization of globals in uni
Changes by Stefan Krah :
--
nosy: +Gregory.Andersen, georg.brandl, kushou, pitrou
___
Python tracker
<http://bugs.python.org/issue10156>
___
___
Python-bugs-list m
Changes by Stefan Krah :
--
priority: high -> critical
___
Python tracker
<http://bugs.python.org/issue10156>
___
___
Python-bugs-list mailing list
Unsubscri
Stefan Krah added the comment:
The utf_32_le_decode invalid access is gone; for Valgrind the issue
is fixed (I didn't look at the patch, no time ATM, sorry).
--
___
Python tracker
<http://bugs.python.org/i
Stefan Krah added the comment:
Nick, I'm adding you to the nosy list since this issue seems related to PEP 432.
Quick summary: Globals are used in unicodeobject.c before they are initialized.
Also, Unicode objects are created before PyType_Ready(&PyUnicode_Type) has been
called.
Thi
Stefan Krah added the comment:
Nick Coghlan wrote:
> There should still be a check in tp_new (IIRC) that calls PyType_Ready on
> unready types.
Indeed there is one in type_new(), but that isn't used here AFAICS. If
you apply this patch and start up python, there are many &quo
Stefan Krah added the comment:
What is the output of this?
>>> locale.localeconv()
{'mon_decimal_point': ',', 'frac_digits': 2, 'p_sign_posn': 1, 'thousands_sep':
'.', 'p_sep_by_space
Stefan Krah added the comment:
127 means "no-more-grouping", so Python behaves as instructed by the OS.
As you see, the OS prescribes 1.345.677,222 for *monetary* quantities
and 1345677,222 otherwise.
According to http://de.wikipedia.org/wiki/DIN_1333 , for non monetary
quantitie
Stefan Krah added the comment:
I agree, we can't really do anything here.
--
resolution: -> invalid
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.pyth
New submission from Stefan Krah:
This issue proposes an additional 'm' format specifier that behaves like
'n', but uses mon_grouping, mon_decimal_point and mon_thousands_sep.
See #16944 for the rationale.
--
components: Interpreter Core
messages: 179955
nosy: Pet
Stefan Krah added the comment:
In the absence of an enum type, string constants are nicer to read in
the REPL, so here's a patch. Translating between strings and ints is
fast if you use the module constants.
--
keywords: +patch
Added file: http://bugs.python.org/file28736/issue
Stefan Krah added the comment:
In the version I committed the string constants are interned, so
anything but legacy strings should be reasonably fast.
--
assignee: -> skrah
components: +Extension Modules
resolution: -> fixed
stage: -> committed/rejected
status: open
New submission from Stefan Krah:
_ssl is not built on the Fedora buildbot:
http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/3798/steps/test/logs/stdio
building '_ssl' extension
gcc -fPIC -Wno-unused-result -g -O0 -Wall -Wstrict-prototypes -I./
Stefan Krah added the comment:
In 3.3 libffi has been updated to 3.0.11. Our clang buildbot does not
show this particular warning, but still fails to compile libffi:
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%2Bclang%203.3/builds/320/steps/compile/logs/stdio
It
Stefan Krah added the comment:
Thanks for the link. The diff was committed last week to the upstream
libffi development tree, so I backported it.
--
assignee: -> skrah
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: -> behavior
versio
Stefan Krah added the comment:
Fixed in OpenBSD 5.2.
--
resolution: -> out of date
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Stefan Krah added the comment:
All threading issues are fixed in OpenBSD 5.2.
--
resolution: -> out of date
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Stefan Krah added the comment:
On OpenBSD 5.2 this is fixed. The AIX buildbot looks okay and I doubt
that anyone will commit something for Solaris 9.
--
nosy: +skrah
resolution: -> out of date
stage: test needed -> committed/rejected
status: open -&g
Stefan Krah added the comment:
Could we merge this with #6419?
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue16952>
___
___
Python-bugs-list m
Stefan Krah added the comment:
This is a duplicate of #11729, which is fixed.
--
nosy: +skrah
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> libffi assembler relocation check is not robust, fails with
clang
type: ->
Stefan Krah added the comment:
Trent, do you want to keep this open? I think sys.mk is behaving exactly
as intended.
--
___
Python tracker
<http://bugs.python.org/issue15
Stefan Krah added the comment:
Does this apply to Python 3.3 as well? I don't think we're going to
fix this in 2.7.
--
nosy: +skrah
status: open -> pending
___
Python tracker
<http://bugs.pytho
Changes by Stefan Krah :
--
assignee: -> skrah
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: +Python 3.4
___
Python tracker
<http://bugs.python
Stefan Krah added the comment:
Since this occurs only on 2.7 and *very* rarely, let's close it.
--
resolution: out of date -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.
Changes by Stefan Krah :
--
assignee: -> skrah
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python
Stefan Krah added the comment:
What is in sample.txt? I cannot reproduce this with a source build
(Windows 7, 64-bit pgo build):
Python 2.7.3+ (default, Jan 17 2013, 20:26:24) [MSC v.1500 64 bit (AMD64)] on
win32
Type "help", "copyright", "
New submission from Stefan Krah:
Since 5e33b27c71a8 SHLIB_EXT is not set in configure.ac, since
the block in which $SO is defined has been moved below this line:
AC_DEFINE_UNQUOTED(SHLIB_EXT, "$SO", [Define this to be extension of shared
libraries (including the dot!).])
Thi
Stefan Krah added the comment:
I tend to agree with the argument that the removal of intobject.h was
a good thing, since it avoids subtle errors.
Probably no one wants to reinstate intobject.h at this point, so unless
there are objections, I'll update the docs in a couple of
Changes by Stefan Krah :
--
assignee: -> skrah
keywords: +3.3regression
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python
Stefan Krah added the comment:
koobs wrote:
> Stefan, can we merge this to the 2.7 branch as well please?
If Benjamin is okay with it, yes. The problem with these configure fixes
is that they might break other systems in unexpected ways. I already hesitated
to put it into 3.3, but
Stefan Krah added the comment:
The buildbot coverage is good, but the number of (OS, shell, compiler)
combinations is much higher.
--
___
Python tracker
<http://bugs.python.org/issue11
Stefan Krah added the comment:
Several 2.7 buildbots are failing.
> Unfortunately I have only platforms where sizeof(int) == sizeof(long) ==
sizeof(size_t).
You can use your cpython ssh key to login to all snakebite buildbot
machines. They are tagged with [SB].
http://mail.python.
Changes by Stefan Krah :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.3, Python 3.4 -Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.o
New submission from Stefan Behnel:
There's a bug originally report for lxml that also applies to ElementTree:
https://github.com/lxml/lxml/issues/95
Passing different namespace mappings into the Element.find*() methods will
always reuse the first one due to incorrect caching based only o
Changes by Stefan Behnel :
--
components: +Library (Lib) -XML
___
Python tracker
<http://bugs.python.org/issue17011>
___
___
Python-bugs-list mailing list
Unsub
Changes by Stefan Behnel :
--
components: +XML
___
Python tracker
<http://bugs.python.org/issue17011>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
Here is a test case (for lxml):
https://github.com/lxml/lxml/commit/76f2ee991afd15d4f8c98cee3e095967bbf9937f
--
___
Python tracker
<http://bugs.python.org/issue17
Stefan Behnel added the comment:
I'm not sure if it's a good idea to keep bikeshedding about this for another
two years. Personally, I would prefer having someone with commit rights fix
this and be done with it.
Eric's last patch looks ok and parts of it went in already, so i
New submission from Stefan Behnel:
The following compatibility unit test fails for me in lxml since Py3.3.
etree = xml.etree.ElementTree
def test_parser_target_error_in_start(self):
assertEqual = self.assertEqual
events = []
class Target(object
Stefan Krah added the comment:
Serhiy, test_pathext_checking still fails on many Windows buildbots:
http://buildbot.python.org/all/waterfall?category=3.x.stable&category=3.x.unstable
--
nosy: +skrah
status: closed -> open
___
Python tracker
Stefan Behnel added the comment:
I agree that [0] should be treated as a visible error as it's easy to get
wrong. It's certainly too late to change this to 0-based indexing and I think
it's ok to keep it 1-based for XPath compatibility (or at least similarity) as
that
Stefan Behnel added the comment:
Yes, I think it makes sense to be rigid now and *maybe* add a new feature later.
--
___
Python tracker
<http://bugs.python.org/issue12
Stefan Krah added the comment:
I just ran the 2.7 tests while dealing with another issue, and
I'm getting a memory error or excessive swapping in test_ucn:
The statement
x = b'\\N{SPACE' + b'x' * int(_testcapi.UINT_MAX + 1) + b'}'
uses over 8GB on my
Stefan Krah added the comment:
The test is fixed here, thanks.
The limits appear to be different in 2.7 and 3.4: In 2.7 the bigmem tests
are executed with -M x > 16G, in 3.4 with -M x >= 12G.
I don't know if that's deliberate, ju
Stefan Krah added the comment:
> It is in the combination with jumpahead(), getstate(), setstate() that you'll
> experience random() to produce values >= 1.0
Let me reiterate what David said: Can you post a self-contained program
that exhibits the issue?
-
Stefan Krah added the comment:
Since Rietveld didn't mail me this time: I left some comments on the 2.7 patch.
--
versions: +Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
The 2.7 comments also apply to the 3.2 patch. Otherwise the 3.2 patch
(without the _sre changes :) looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue10
Stefan Krah added the comment:
Floris van Manen wrote:
> From what i understand is that issue14591 was able to reproduce the same
> feature as it seems related to the jumpahead() malfunctioning.
I'm also quite sure that it's the same issue. It would be nice to have
confirm
Stefan Krah added the comment:
Nice. I think the latest patches are commit-ready.
--
___
Python tracker
<http://bugs.python.org/issue10156>
___
___
Python-bug
Stefan Krah added the comment:
Floris van Manen wrote:
> Did compile that version and it launches.
> To test with my code i do not want to have it interfere with my current
> version.
> I remember it is possible to setup n isolated environment with pip en
> virtualenv.
> Bu
3101 - 3200 of 4952 matches
Mail list logo
