Stefan Krah added the comment:
Hmm, the bug is in the 32-bit build. The 64-bit build is fine. Or do you
mean MMX registers?
--
___
Python tracker
<http://bugs.python.org/issue15
New submission from Stefan Krah:
According to issue #9799 configuring --without-computed-gotos might
solve the AIX compile error.
--
components: Build
keywords: buildbot
messages: 171013
nosy: skrah, trent
priority: normal
severity: normal
status: open
title: AIX buildbot compile errors
Stefan Krah added the comment:
I tested --without-computed-gotos on the AIX machine and that solves
the problem.
Antoine, I understood that ./configure parameters can only be changed
on the build master. Could you add --without-computed-gotos?
--
nosy: +pitrou
Stefan Krah added the comment:
Thanks!
--
___
Python tracker
<http://bugs.python.org/issue16002>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Stefan Krah:
The locale failures on the DragonFly buildbot are caused by an OS bug:
bugs.dragonflybsd.org/issues/2415
I'm opening an issue so that this is recorded and other people hopefully
won't waste time debugging the failures. I intend to close the issue
as
Stefan Krah added the comment:
The compile errors are fixed, let's open separate issues for the
test failures.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.pyth
Stefan Krah added the comment:
PATH_MAX seems to be a mess on HP-UX: It's only defined in limits.h
if _INCLUDE_XOPEN_SOURCE_PRE_500 is defined.
But MAXPATHLEN is always defined in sys/param.h, so I suggest to use that
(patch attached).
Other projects take a similar approach by just def
Stefan Krah added the comment:
test_threaded_import also takes around 5 min on Windows. I think
we should go for 0.1 on all platforms.
--
___
Python tracker
<http://bugs.python.org/issue15
Stefan Krah added the comment:
I'm glad I found this. Without the long incantation _decimal is
seriously miscompiled on SPARC/Solaris 10/Sun Studio 12.3. I was
using just ...
./configure --without-gcc CFLAGS=-m64 LDFLAGS=-m64
..., and that seems to trigger an optimizer bug that pro
Stefan Krah added the comment:
Closing since this an OS bug.
--
resolution: -> wont fix
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Stefan Krah added the comment:
I don't get a segfault, but a fatal error. Here's the back trace
(unfortunately I've no time to debug this further today; sqlite
is the latest version compiled from source):
#0 0x771e6a75 in *__GI_raise (sig=) at
../nptl/sysdeps/unix/sys
Stefan Krah added the comment:
Hi Trent, nice setup BTW!
Trent Nelson wrote:
> Hi Stefan, quick question: how did you invoke ./configure on the AIX box?
> The reason for asking is that a7/arsenic is a little quirky, you need to
> run a zsh subroutine via `_xlc 12` to set up the rig
Stefan Krah added the comment:
[Adding the apsw author to the cc.]
Antoine is right, no Python bug here. I think we can close this.
--
nosy: +rogerbinns
stage: -> committed/rejected
status: pending -> closed
___
Python tracker
Stefan Krah added the comment:
Thanks for the report. -- The locale wasn't properly reset in
test_wide_char_separator_decimal_point(). Should be fixed now.
--
nosy: +skrah
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type
Stefan Krah added the comment:
Here we go. The new code fails if ps_AF isn't available.
--
resolution: fixed ->
stage: committed/rejected ->
status: closed -> open
___
Python tracker
<http://bugs.pyth
New submission from Stefan Krah:
A couple of links still need to be updated:
http://docs.python.org/
Python 3.3 says "in development" and points to 3.4.
http://docs.python.org/dev/
Python 3.3 is missing.
--
assignee: docs@python
components: Documentation
messages: 1
Stefan Krah added the comment:
I can't reproduce this, so just a wild guess: Does the segfault still
happen if you replace Py_XDECREF() with Py_CLEAR() in xmlparser_gc_clear()?
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
I'm now able to reproduce the issue with a non-debug build. As
Christian says, using Py_CLEAR() does not help (though I wonder
if it shouldn't be used anyway).
Reverting part of 20b8f0ee3d64 "fixes" the segfault, see the
attached diff. I don&
Stefan Krah added the comment:
Do note that the patch is somewhat cargo-cult. I don't understand yet why
it works; it may very well just silence the real problem.
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
For once a Linux bot shows the failure that is the topic of this
issue:
http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/3101/steps/test/logs/stdio
==
FAIL
Stefan Krah added the comment:
I can't reproduce it either even on the machine that magically caught
every problem in #15781.
FWIW, the Gentoo bot also had a completely isolated segfault in
test_ssl lately.
Antoine, are you OK with setting the switch interval to 1e-5 for
all plat
Stefan Krah added the comment:
Nice find. -- The Python version does this:
_Element = _ElementInterface = Element
So (naively) I would think the same should be done for the C version
after importing Element.
But then one runs into the object layouts conflict that you mentioned.
On the
Stefan Friesel added the comment:
What is the status of this? Does the patch need more reviewing?
--
nosy: +Stefan.Friesel
___
Python tracker
<http://bugs.python.org/issue812
Stefan Krah added the comment:
This seems related to #9242: _Py_InitializeEx_Private() calls _Py_ReadyTypes(),
which uses the Unicode API, well before actually calling _PyUnicode_Init().
--
nosy: +georg.brandl, skrah
priority: normal -> release blocker
stage: -> needs
Stefan Krah added the comment:
Sorry, wrong issue number: Related to #10156.
--
___
Python tracker
<http://bugs.python.org/issue16143>
___
___
Python-bugs-list m
Stefan Krah added the comment:
See also #16143.
--
versions: +Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue10156>
___
___
Python-bug
Stefan Krah added the comment:
In general APSW does not look ready for the Python 3.3 Unicode
implementation. Example: src/statementcache.c:217
Py_UNICODE *out;
PyObject *res=PyUnicode_FromUnicode(NULL, size);
Python 3.3 docs:
"If the buffer is NULL, PyUnicode_READY() must be c
Stefan Krah added the comment:
R. David Murray wrote:
> My understanding was that code that calls the public APIs should continue to
> work. Is this a new requirement in 3.3, or is it that it has always been a
> requirement but code could get away without the ready before?
I
Stefan Krah added the comment:
David is right, the existing (APSW) code should continue to work.
I think we need to add a couple of PyUnicode_READY() to some
functions in Modules/_csv.c.
--
___
Python tracker
<http://bugs.python.org/issue16
Stefan Krah added the comment:
Here's a patch.
Victor, I guess I have a feature request for fusil: It would be nice
if fusil also generated legacy strings (or does it already do so?).
--
keywords: +patch
Added file: http://bugs.python.org/file27454/issue16145
Stefan Krah added the comment:
> The PEPs and doc said the C API would remain backwards compatible.
Roger: Yes, you don't need to change anything. I was misled by the
PyUnicode_AsUnicode() docs, thinking that the responsibility to call
PyUnicode_READY() also applies if the generated
Stefan Krah added the comment:
a7ec0a1b0f7c broke the Windows buildbots: In Visual Studio variables
can only be declared at the top of a block.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue16
Stefan Krah added the comment:
I don't know the reason for the previous behavior, but it's documented:
http://docs.python.org/dev/c-api/unicode.html?highlight=pyunicode_fromformatv#PyUnicode_FromFormat
"An unrecognized format character causes all the rest of the format string t
Stefan Krah added the comment:
--with-system-ffi should probably solve some problems, see #12927.
The summary of that issue is that the unpatched libffi is not
compatible with suncc and any issues should be reported upstream
(at least that was Meador's and my own opinion).
--
Stefan Krah added the comment:
Closing as out-of-date.
--
resolution: -> out of date
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Stefan Holek:
Please allow for surrogates in the zipfile module like it was done for tarfile
in #8390.
Currently zipfile breaks when encountering surrogates:
Traceback (most recent call last):
File "/usr/local/python3.3/lib/python3.3/zipfile.py", li
Stefan Holek added the comment:
A little more context perhaps:
The use-case is building Python distributions containing non-ASCII filenames.
These seemingly "invalid" filenames can occur in real-life when the files have
been created by, say, a 'git clone' operation.
So
Stefan Holek added the comment:
What we are trying to do is make distribute work with non-ASCII filenames, and
this is one of the things we ran into.
Fact 1: Filenames are bytes, whether you like it or not. Treating them as
strings is going to give you more trouble than dragging the bytes
Stefan Krah added the comment:
FWIW, Solaris 9 has EOL status:
http://www.oracle.com/technetwork/server-storage/solaris10/overview/index-138972.html
I suspect we might as well close this issue, since the motivation to work
on it will be pretty low in general
Stefan Krah added the comment:
Right, they distinguish between EOL and "Extended Support Phase":
http://www.oracle.com/technetwork/server-storage/solaris10/overview/general-137378.html
--
___
Python tracker
<http://bugs.python.
Stefan Holek added the comment:
> It's possible to distribute Python packages with non-ASCII filenames.
Well, it wasn't until very recently (distribute 0.6.29):
https://bitbucket.org/tarek/distribute/issue/303/no-support-for-unicode-manifest-files
Unless we are not talking about t
Stefan Krah added the comment:
Mark Dickinson wrote:
> I wonder whether we can sneak this in after 3.4 is released?
+1. m68k affects a relatively small group of people, and Andreas Schwab is
the gcc m68k port maintainer, so ...
--
___
Pyt
Stefan Behnel added the comment:
Agreed that this should be done. The XInclude spec suggests that the processing
is transitive. Also, lxml does it that way, in both the libxml2 based
implementation and the ElementInclude compatibility module.
https://github.com/lxml/lxml/blob/master/src/lxml
Stefan Krah added the comment:
It looks like there's typo: Psuedo => Pseudo. (Unless the first one
is an alternate spelling I'm not aware of.)
--
___
Python tracker
<http://bugs.pytho
Stefan Behnel added the comment:
catalog = xml.etree.ElementTree.parse('books.xml')
# This succeeds
for book in catalog.findall('book'):
print(book.tag)
This is a bit of a convenience break in the API. The "normal" way to do it
would be either c
Stefan Krah added the comment:
So far there are only very few m68k patches. Additionally, the patches are
well researched and sometimes highlight ANSI C violations.
The submitters of the patches are highly competent and apparently take testing
seriously. I see no reason to reject the
Stefan Krah added the comment:
Yes, ยง6.7.2.1:
A bit-field declaration with no declarator, but only a colon and a width,
indicates an unnamed bit-field.
With a footnote:
105) An unnamed bit-field structure member is useful for padding to conform to
externally imposed layouts.
Unnamed
Changes by Stefan Krah :
--
stage: -> patch review
versions: +Python 3.5 -Python 3.3
___
Python tracker
<http://bugs.python.org/issue20904>
___
___
Python-
Stefan Krah added the comment:
Mark Lawrence, stop playing off committers against each other. This is
outright trolling.
--
___
Python tracker
<http://bugs.python.org/issue19
Stefan Krah added the comment:
I think we should really apply #19232. At least that would take care
of the import issue.
--
___
Python tracker
<http://bugs.python.org/issue16
Stefan Krah added the comment:
Benjamin Peterson wrote:
> I don't want to scare away contributors.
I think this is a very important point. Initially I was skeptical about m68k,
too (msg182388), but I've completely changed my opinion due to the nature
of the patches.
So far, th
Stefan Behnel added the comment:
I think you attached the wrong file.
--
___
Python tracker
<http://bugs.python.org/issue20375>
___
___
Python-bugs-list mailin
Changes by Stefan Krah :
--
nosy: +larry
priority: normal -> high
___
Python tracker
<http://bugs.python.org/issue21121>
___
___
Python-bugs-list mai
Stefan Behnel added the comment:
> Add all the element methods to the elementtree object.
Ok, but why? An ElementTree object *is not* an Element. It's a
representation of a document that *has* a root Element.
It makes sense for a document to allow searches over its content, and the
Ele
Stefan Behnel added the comment:
> I don't see any benefit from having this code fail:
>
> from xml.etree.ElementTree import parse
>
> catalog = parse('books.xml')
> for book in catalog:
> print book.get('id')
Why would you
Stefan Behnel added the comment:
> How about just making a sensibly-behaving __iter__ for ElementTree?
Well, the problem is to determine what "sensibly-behaving" is. I can see
three options.
1) tree.iter() == tree.getroot().iter()
2) iter(tree.getroot())
3) iter([tree.get
Stefan Krah added the comment:
This looks like a duplicate of #12546.
--
resolution: -> duplicate
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.5 -Python 2.7, Python 3.3
___
Python track
Changes by Stefan Krah :
--
superseder: -> builtin __format__ methods cannot fill with \x00 char
___
Python tracker
<http://bugs.python.org/issue17705>
___
_
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue20361>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue20355>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Is this still an issue?
--
status: open -> pending
___
Python tracker
<http://bugs.python.org/issue19354>
___
___
Python-bugs-lis
Stefan Krah added the comment:
Can we somehow merge this issue with #20904?
--
___
Python tracker
<http://bugs.python.org/issue18062>
___
___
Python-bugs-list m
Stefan Krah added the comment:
If the asm instructions silently fail, I'd say add a test to ./configure
that detects the broken versions of the emulator in question.
Or don't bother and tell people to use the proper version of
th
Stefan Krah added the comment:
FreeBSD 9 is failing as well:
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/6583/steps/test/logs/stdio
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue21
Stefan Krah added the comment:
Did you compile with "-fp-model strict"? IIRC icc is not IEEE-754
compliant by default.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.o
Stefan Krah added the comment:
I agree we should add "-fp-model strict" to the icc build flags, provided that
there is a way that it does not show up in the distutils flags.
Apparently icc users want unsafe fast math by default, so this flag should
probably not be enforced in extens
Stefan Krah added the comment:
I think it's possible to misunderstand this error message if the
reader does not realize that range(0, 256) is to be taken literally.
Perhaps we should just use closed intervals of the form [0, 255]
everywhere.
--
nosy: +
Stefan Krah added the comment:
OverflowError during initialization dates back to the early days of Python:
http://hg.python.org/cpython/rev/0437738279a8
Integer arithmetic actually did raise OverflowError back then:
>>> 2 * 22
Traceback (most recent
Stefan Krah added the comment:
Mark Dickinson wrote:
> > the whole idea of OverflowError seems slightly outdated.
>
> Well, not entirely. It's still got a place for overflow of mathematical
> operations, and I think it's clearly the correct exception in that case
Stefan Krah added the comment:
There's no real problem. I find "must be in the range [0, 255]" easier to
understand, but I also would not make a big effort to change this.
As for me, we can close this issue.
--
___
Python
Stefan Krah added the comment:
This is for FreeBSD-9 (which, to be fair, has EOL status):
[stefan@freebsd-amd64 ~]$ openssl ciphers -v
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
AES256-SHA
Stefan Krah added the comment:
Antoine Pitrou wrote:
> > I suggested "must be in the range [0; 255]" which is not a valid Python
> > list: ";" is the instruction operator and there is "range" word in front of
> > the "list". In my opinio
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue16991>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
@gene_wood: that's unrelated. This ticket is about attributes being rejected
incorrectly.
Fixing the example of the OP:
>>> from xml.etree.ElementTree import *
>>> svg = ElementTree(XML("""
... htt
Stefan Krah added the comment:
FreeBSD 9.0 has the same broken install:
$ openssl version
OpenSSL 0.9.8y 5 Feb 2013
$ ls /usr/include/openssl/ecd*
/usr/include/openssl/ecdh.h /usr/include/openssl/ecdsa.h
I'm inclined to view this as
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue21233>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Krah :
--
assignee: docs@python -> skrah
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue21227>
___
___
Python-bugs-list mai
Stefan Krah added the comment:
I left a Rietveld comment, which probably did not get mailed.
--
___
Python tracker
<http://bugs.python.org/issue21233>
___
___
Stefan Krah added the comment:
In case anyone wonders why the FreeBSD bot works again: I've
installed OpenSSL from source.
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
Here is a patch. I do not see a really nice way to deal with the problem.
The cleanest way I found was to introduce a new Makefile variable CFLAGS_NODIST
and use that in the interpreter and stdlib build.
--
keywords: +patch
nosy: +skrah
Added file: http
Stefan Krah added the comment:
Mark, if you agree that "fp-model strict" should not show up in
the distutils CFLAGS once Python is installed, the issue now depends
on #21121.
--
dependencies: +-Werror=declaration-after-statement is added even for extension
modules throug
Stefan Krah added the comment:
Antoine Pitrou wrote:
> Did you install the same version?
No, I used the latest version + FIPS. Since FreeBSD 9.0 is EOL, I did not
feel like investigating too much. :)
--
___
Python tracker
<http://bugs.pyth
Stefan Krah added the comment:
It is hard to get fine grained error messages in _decimal, since
the errors come from libmpdec. A clean solution would require
changes to libmpdec, and I'm reluctant to do that right now.
It is certainly possible to document DivisionImpossibl
Stefan Krah added the comment:
Meanwhile, the pure Python decimal versions prior to Python 3.2
have better error messages.
Right now in Python 3.3+ it is hard to import the Python version
without going into contortions, but that may be fixed in #19232.
--
dependencies: +Speed up
Stefan Krah added the comment:
My apologies if that wasn't clear: "fine grained" refers to the exception
messages. A function can raise InvalidOperation for different reasons.
decimal.py gives a specific error message in each case. libmpdec just
signals the standard conforming I
Stefan Krah added the comment:
I would like to go ahead with this. As Antoine mentioned, most
people don't diagnose import problems, especially when they compare
Python 2 against Python 3.
As it turns out, the slowdown is even significant in a simple tcpserver
application that starts a P
Stefan Krah added the comment:
In the case of DivisionImpossible it would actually be possible to use
the error message 'quotient too large in //, % or divmod'.
But that's just one condition. In the case of InvalidOperation there
are something like 30 different
Stefan Krah added the comment:
Raymond Hettinger wrote:
> > It is certainly possible to document DivisionImpossible etc.
>
> This should not be done. We've made strong efforts to not extend the Decimal
> Arithmetic Specification.
The exceptions are already there:
Python
Stefan Krah added the comment:
I quite agree, and it's hard to tell what users want. Basically I'm afraid
of a bug report "C extension using unsafe math got slower in Python-3.5".
I would find either decision reasonable.
--
___
P
Stefan Krah added the comment:
leewz wrote:
> - Error message for `DivisionImpossible` is
> []
> instead of an actual error message.
No, the error message for the *signal* that is raised (InvalidOperation) lists
the *condition* that triggered the signal (DivisionImposs
Stefan Krah added the comment:
The idea behind the list as the exception message is this: If multiple
conditions would have raised the signal they are all listed, while the
"highest ranking" signal is the one that is ultimately raised.
>>> from decimal import *
>>>
Stefan Krah added the comment:
Larry Hastings wrote:
> Andreas, is there someone who would normally check this in for you, or should
> I do it?
Traditionally Mark commits the floating point stuff. :)
--
___
Python tracker
<http://bugs.p
Stefan Behnel added the comment:
You can already use iterparse for this.
it = ET.iterparse('somefile.xml')
for _, el in it:
el.tag = el.tag.split('}', 1)[1] # strip all namespaces
root = it.root
As I said, this would be a little friendlier with suppor
New submission from Stefan Schwarzer:
I recently was confused whether to raise a `PicklingError` or `TypeError` in
`__getstate__` if objects of my class can't and shouldn't be pickled. [1]
Terry Reedy advised I should use `TypeError`. [2]
I wonder if the `pickle` module document
Stefan Krah added the comment:
This looks like a duplicate of #7511.
--
nosy: +skrah
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> msvc9compiler.py: ValueError when trying to compile with VC
Express
__
Stefan Krah added the comment:
I pushed a minimal patch that focuses on the array.array issue. For
broader changes, I suggest to use #14198 (though it is unlikely
tha anyone will work on it).
--
resolution: -> fixed
stage: patch review -> resolved
status: open -&g
Changes by Stefan Krah :
--
assignee: skrah ->
___
Python tracker
<http://bugs.python.org/issue14198>
___
___
Python-bugs-list mailing list
Unsubscrib
Stefan Krah added the comment:
Just to add another data point, I don't find the calloc() API
cumbersome.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue20230>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue1820>
___
___
Python-bugs-list mailing list
Unsubscribe:
2801 - 2900 of 4951 matches
Mail list logo
