Changes by Stefan Krah :
--
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue13084>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue6632>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Stefan Krah added the comment:
The PEP-393 changes apparently fix this leak; at least I can't reproduce
it in default any longer (but still in 3.2).
--
___
Python tracker
<http://bugs.python.org/is
New submission from Stefan Krah :
Seen in test_mailbox:
==31621== 6 bytes in 2 blocks are definitely lost in loss record 27 of 10,370
==31621==at 0x4C2154B: malloc (vg_replace_malloc.c:236)
==31621==by 0x5271A5: parsetok (parsetok.c:179)
==31621==by 0x526E8A
New submission from Stefan Krah :
Seen in test_multiprocessing:
==31662== 37 bytes in 1 blocks are definitely lost in loss record 629 of 10,548
==31662==at 0x4C2154B: malloc (vg_replace_malloc.c:236)
==31662==by 0x53BBE9: PyBytes_FromStringAndSize (bytesobject.c:98)
==31662==by
New submission from Stefan Krah :
Seen in test_multiprocessing:
==31662== 44 bytes in 1 blocks are definitely lost in loss record 687 of 10,548
==31662==at 0x4C2154B: malloc (vg_replace_malloc.c:236)
==31662==by 0x41CC27: PyMem_Malloc (object.c:1699)
==31662==by 0x127D9F51: resize
New submission from Stefan Krah :
I found a couple of additional leaks related to the PEP-393 changes.
--
components: Interpreter Core
files: pep-393-leaks-2.diff
keywords: patch
messages: 144767
nosy: loewis, skrah
priority: normal
severity: normal
stage: patch review
status: open
Stefan Krah added the comment:
Patch looks good to me (and it fixes the problem).
--
___
Python tracker
<http://bugs.python.org/issue13084>
___
___
Python-bug
New submission from Stefan Krah :
I can't see what this code is supposed to accomplish (see patch):
while (collend < end) {
if ((0 < *collend && *collend < 256) ||
!Py_UNICODE_ISSPACE(*collend) ||
Py_UNICODE_TODECIMAL(*collend))
break
Stefan Krah added the comment:
The automatic conversion of 'u' to 'I' or 'L' causes test_buffer
(PEP-3118 repo) to fail:
# Not implemented formats. Ugly, but inevitable. This is the same as
# issue #2531: equality is also used for membership testing and must
# re
Changes by Stefan Krah :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13072>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
>It would be better to use a format for a Py_UCS4 string, but struct doesn't
>support such type.
PEP-3118 suggests for the extended struct syntax:
'c' -> ucs-1 (latin-1) encoding
&
Stefan Krah added the comment:
STINNER Victor wrote:
> > # Not implemented formats. Ugly, but inevitable. This is the same as
> > # issue #2531: equality is also used for membership testing and must
> > # return a result.
> > a = array.array('u&
Stefan Krah added the comment:
I haven't seen this in a while, so let's assume it's fixed.
--
resolution: -> out of date
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http:/
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue3163>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
New submission from Stefan Krah :
The FreeBSD-amd64 and Fedora buildbots are recently failing with:
==
ERROR: test_thishost (test.test_urllib.Utility_Tests)
Test the urllib.request.thishost utility function returns a tuple
Changes by Stefan Krah :
--
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> urllib.request.thishost() returns a garbage value
type: -> behavior
___
Python tracker
<http://bugs.pyt
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue13104>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
/etc/hosts was incomplete; works fine now. Closing again.
--
resolution: -> fixed
stage: test needed -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Stefan Krah added the comment:
Naturally, as soon as I declare it fixed, it occurs again:
http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%202.7/builds/326
--
status: closed -> open
___
Python tracker
<http://bugs.pyth
Stefan Krah added the comment:
I think the whole security paragraph should be deleted. The
discussion on python-dev has overstated the risks.
Anyone who is *that* security conscious and in effect does
not trust the Python committers should also audit the thousands
of lines of ./configure and
New submission from Stefan Krah :
The Fedora bot fails since yesterday:
Breakpoint 1, builtin_id (self=, v=Traceback
(most recent call last):
File "/home/buildbot/buildarea/3.x.krah-fedora/build/python-gdb.py", line
1329, in to_string
return pyop.get_truncated_repr(MAX_
New submission from Stefan Behnel :
Starting at line 1223 in classobject.c, you can find this code:
if (item == NULL)
arg = PyInt_FromSsize_t(i);
else
arg = Py_BuildValue("(nO)", i, item);
if (arg == NULL) {
Py_DECREF(func);
return -1;
Stefan Krah added the comment:
I temporarily changed the Fedora bot to run Fedora-14-i386. The
same failures can be observed:
==
ERROR: test_no_optimize_flag (distutils.tests.test_bdist_rpm.BuildRpmTestCase
Stefan Krah added the comment:
test_errno fails quite often on FreeBSD:
==
FAIL: test_errno (test.test_select.SelectTestCase)
--
Traceback (most recent call
Stefan Krah added the comment:
Hmm, maybe this is a FreeBSD bug:
http://osdir.com/ml/freebsd-bugs/2011-03/msg00201.html
--
___
Python tracker
<http://bugs.python.org/issue12
Stefan Krah added the comment:
I'm not sure it's exactly the same FreeBSD bug as in kern/155606,
since I can also reproduce the test_errno failure --without-threads.
Seems good to skip the test though.
--
___
Python tracker
<http://bu
New submission from Stefan Krah :
The failures seen on the Fedora buildbot are caused by the fact that
INSTALLED_FILES does not use __pycache__:
[stefan@fedora-14-i386 foo]$ cat
build/bdist.linux-i686/rpm/BUILD/foo-0.1/INSTALLED_FILES
/usr/local/lib/python3.3/site-packages/foo.py
/usr/local
Stefan Krah added the comment:
For the buildbot failures see #13307. I think that it's indeed a
different issue, since AFAIK __pycache__ didn't exist when this one
was opened.
--
___
Python tracker
<http://bugs.python.
Stefan Krah added the comment:
The buildbot runs as non-root, so it should reproduce this
issue (but it's green).
The original report was for 2.6/3.1, so I think closing this as
out-of-date is reasonable.
--
___
Python tracker
Changes by Stefan Krah :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue12998>
___
___
Python-bugs-list mailing list
Unsubscri
Stefan Holek added the comment:
This is with Python 3.2.2 on Mac OS X 10.6 (SL). I have built Python from
source with: ./configure; make; make install.
--
___
Python tracker
<http://bugs.python.org/issue13
Stefan Holek added the comment:
Python 3.2.2 (default, Nov 4 2011, 22:28:55)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, io
>>>
Stefan Holek added the comment:
Oops, the last one wasn't meant for the bug tracker.
--
___
Python tracker
<http://bugs.python.org/issue13342>
___
___
Pytho
Stefan Holek added the comment:
I can make it work at the interpreter prompt with your patch applied. Sorry for
cluttering up the ticket. ;-)
--
___
Python tracker
<http://bugs.python.org/issue13
Stefan Krah added the comment:
Looking at it again, the intention was probably to increment
collend so that it points to the first non-garbage character
(or '\0'). If that's the case, the loop should be something
like this:
while (collend < end) {
if ((0 < *coll
Stefan Behnel added the comment:
Florent, thanks for the notification.
Nekmo, note that you are misusing this feature. The _namespace_map is meant to
provide "well known namespace prefixes" only, so that common namespaces end up
using the "expected" prefix. This is al
Stefan Behnel added the comment:
Reading the proposed patch, I must agree that it makes more sense in
ElementTree to support this as a serialiser feature. ET's tree model doesn't
have a notion of prefixes, whereas it's native to lxml.etree.
Two major advantages of puttin
New submission from Stefan Behnel :
In Python modules, the top-level module code sees the __file__ variable and can
use it to refer to resources in package subdirectories, for example. This is
not currently possible in extension modules, because __file__ is only set after
running the module
Changes by Stefan Behnel :
--
keywords: +patch
nosy: +loewis
Added file: http://bugs.python.org/file23725/ext_module_init_file_path.patch
___
Python tracker
<http://bugs.python.org/issue13
Stefan Behnel added the comment:
Here is an extension to the patch that implements the protocol also for
extension module reinitialisation, so that the module creation can also set
__file__ and the proper package in that case. Currently without tests (and
users, I guess).
--
Added
Stefan Behnel added the comment:
Updated single slice caching patch for latest Py3.3 hg tip.
--
Added file: http://bugs.python.org/file23727/slice-object-cache.patch
___
Python tracker
<http://bugs.python.org/issue10
Stefan Behnel added the comment:
I don't know how the import lock applies here. Would it have to be protected by
it? The lifetime is restricted to the call of the extension module init
function, and its value is saved recursively if the init function triggers
further imports.
It
Stefan Behnel added the comment:
... and the module init function could create and register a different module
first, and ...
Well, yes, it's a best effort thing. It's rather unlikely that the GIL would
get released in between the call to the init function and the creation of t
Stefan Behnel added the comment:
I'm aware that these things happen, that's why I said it. Actually, wouldn't it
rather be *correct* for __file__ to be set to the same file path for all
modules that an extension module creates in its init function? That woul
Stefan Behnel added the comment:
Updated patch that does not reset _Py_ModuleImportContext after use.
--
Added file: http://bugs.python.org/file23728/ext_module_init_file_path_2.patch
___
Python tracker
<http://bugs.python.org/issue13
New submission from Stefan Behnel :
This is a follow-up to issue 13429, which deals with setting __file__ on newly
created extension modules earlier than it is currently the case.
Currently, the module init function of extension modules lacks a way to find
out the context in which it is being
Stefan Behnel added the comment:
Replying to myself:
> I think the right fix for Python 4 would be to simply pass
> a context struct into the module init function.
Actually, this doesn't have to wait for Python 4. Changing the module init
function to take a parameter should b
Stefan Behnel added the comment:
Yes, that's unfortunate. I found the same paragraph in section 6.5.2.2p6 of the
C99 standard now, so it seems that this idea isn't suitable for the Py3.x
series.
There's no Python 4 target version in the b
Stefan Krah added the comment:
My last comment could be misinterpreted: This *is* actually
already fixed in features/pep-3118.
--
versions: +Python 3.3 -Python 3.1
___
Python tracker
<http://bugs.python.org/issue7
Stefan Behnel added the comment:
The problem with having that information "internally" is that it's currently
stored in local variables in the call chain from the dynamic library loader.
Passing that information on into a callable function, without passing it as an
argumen
Stefan Behnel added the comment:
As MvL noted in his response to issue 13431, simply adding a parameter to the
module init function cannot safely be done before Python 4. So we are back to
the idea of passing the information through to the module creation function,
i.e. this very issue.
A
Stefan Krah added the comment:
I'm only using the function with the NULL error handler. If I had
to use 'xmlcharrefreplace', presumably I'd overallocate 'output'
for the worst case scenario: sizeof("�") per encoded
character.
It's
Stefan Behnel added the comment:
Ok, so, what do we make of this? I proposed improvements to the wording in the
documentation, which make it much clearer for users what they are buying into
when they start using minidom. I still think that "factually correct" but
clearly
Stefan Behnel added the comment:
I find a factor of an order of magnitude worth mentioning, because it prevents
certain kinds of usages.
--
___
Python tracker
<http://bugs.python.org/issue11
Stefan Behnel added the comment:
I don't think "FUD" is a suitable term for the rather minidom-friendly wording
in my last proposal. Seriously, minidom is widely known for being extremely
slow and extremely memory hungry. And that is backed by basically any benchmark
that has
Stefan Behnel added the comment:
Ezio Melotti, 29.11.2011 16:26:
>> Seriously, minidom is widely known for being extremely slow and
>> extremely memory hungry. And that is backed by basically any benchmark
>> that has ever been done on the subject.
>
> Do you have any l
Stefan Behnel added the comment:
Given that the links were generally somewhat dated and used Py2.x instead of
the post-PEP393 Py3.3, here is another little benchmark, comparing the parser
performance of minidom to lxml.etree (latest), ElementTree and cElementTree
(stdlib) in a recent Py3.3
Stefan Behnel added the comment:
Hmm, looks like I messed up the last example. I accidentally left in the
formatting whitespace, thus growing the file to 6.2 MB. Removing that, I get
this for the (now really) 4.5 MB XML file with lots of structure and very
little data:
Memory usage: 11600
Stefan Krah added the comment:
Binary versus decimal
-
> There is already gmpy and bigfloat, based on the heavily optimized GMP
> library,
> for example. Is it a license issue? Can't we reuse GMP/MPFR to offer a
> Decimal API?
_decimal is a PE
Stefan Krah added the comment:
Mark Dickinson wrote:
> The only problem from my perspective is getting someone to find time to
> review such a massive patch. I've been wondering whether we could get away
> with some kind of 'statistical' review: do a large-scale rev
Stefan Krah added the comment:
Antoine Pitrou wrote:
> It is also helped by the fact you are a core developer and we trust you to
> be here to do maintenance :)
Sure. The specification doesn't really change, so the work will hopefully
be limited. :)
> I think it's still p
Stefan Krah added the comment:
Raymond Hettinger wrote:
> We've been wanting this for a long time.
>
> Strong +1 from me.
Thank you, Raymond!
--
___
Python tracker
<http://bugs.pyt
Stefan Krah added the comment:
Amaury Forgeot d'Arc wrote:
> I can help with the review. Is http://bugs.python.org/review/7652/show a
> good starting point? I already have some comments.
Yes, that would be great. Apart from two or three changes that I still
need to push patch s
Changes by Stefan Krah :
Added file: http://bugs.python.org/file23822/bba956250186.diff
___
Python tracker
<http://bugs.python.org/issue7652>
___
___
Python-bugs-list m
Stefan Krah added the comment:
Stefan Krah wrote:
> Yes, that would be great. Apart from two or three changes that I still
> need to push patch set 4 is the latest version.
Hmm, no. I'll create a slightly newer patch from Oct. 1st.
--
___
Stefan Krah added the comment:
[Amaury]
> Overall, I think that the "mpd" C library should be better separated from the
> _decimal module (a bit like _ctypes, with the libffi library): its own
> configure
> & makefile, its own test suite... which are not necessarily
New submission from Stefan Krah :
A couple of -1.0 error return codes aren't documented, see for
example PyFloat_AsDouble() and PyComplex_AsCComplex().
--
assignee: docs@python
components: Documentation
keywords: easy
messages: 148789
nosy: docs@python, mark.dickinson, skrah
pri
Stefan Krah added the comment:
> Ultimately, I think it would make sense to remove all __int__
> conversions from Objects/longobject.c;
+1
I think this API cleanup is worth some (probably very limited)
breakage in third party m
Stefan Krah added the comment:
Good point. - I just had to figure out if the pattern
Py_complex c = PyComplex_AsCComplex(w);
if (c.real == -1.0 && PyErr_Occurred()) {
...
will always be reliable in the future. The source of PyComplex_AsCComplex()
suggests that it will
New submission from Stefan Krah :
I think that `make distclean` should remove Lib/_sysconfigdata.py and
Modules/_testembed. On second thought, `make clean` should probably
also remove those.
--
components: Build
messages: 148969
nosy: skrah
priority: normal
severity: normal
stage: needs
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue13441>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
localeconv_wchar.c runs fine on Ubuntu with hu_HU and fi_FI.
I tried on OpenSolaris, but I only have UTF-8 locales. The package
with ISO locales seems to be SUNWlang-cs-extra, but Oracle took down
http://pkg.opensolaris.org/release
Stefan Krah added the comment:
I guess this still needs to be fixed for Visual Studio.
--
___
Python tracker
<http://bugs.python.org/issue13547>
___
___
Pytho
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue13560>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Excellent, closing then.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Stefan Krah :
I just ran the telco benchmark ...
http://www.bytereef.org/mpdecimal/quickstart.html#telco-benchmark
... on _decimal to see how the PEP-393 changes affect the module.
The benchmark reads numbers from a binary file, does some calculations
and prints the
Changes by Stefan Behnel :
--
nosy: +effbot
___
Python tracker
<http://bugs.python.org/issue13378>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
Given that this is a major new feature for the serialiser in ElementTree, I
think it's worth asking Fredrik for any comments.
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
> I prefer to not expose such function or someone will use it without
> understanding exactly how dangerous it is.
OK. - I'm afraid that I made an error in the benchmarks, since I
accidentally used a changed version of telco.py, namely:
# t i
Stefan Krah added the comment:
Sorry, the title of the issue isn't correct any more. The revised
issue is that in 3.3
a) outfil.write("%s\n" % t)
is about 11% slower than in Python2.7 and 8% slower than in Python3.2.
On the other hand in 3.3 the hack
b) outfil.write(str(t)
Stefan Krah added the comment:
I just tried out http://www.bitvise.com/winsshd , which is free for personal
and noncommercial use. If you run the tests via an ssh connection, WinSSHD
automatically translates pop-ups into error messages:
C:\Users\stefan\cdecimal\PCbuild>python.exe -m test -u
Changes by Stefan Krah :
Added file: http://bugs.python.org/file23959/be8a59fcba49.diff
___
Python tracker
<http://bugs.python.org/issue7652>
___
___
Python-bugs-list m
Stefan Krah added the comment:
Amaury has asked for more comments (and I agree). However, I'm not sure what
level of detail would be appropriate. As an example, I've posted the full
proof of the x87 modular multiplication in umodarith.h.
Even with the Coq parts stripped, this woul
Stefan Krah added the comment:
Stefan Krah wrote:
> Would you prefer that level of detail or should I just post the core
> of the algorithm?
Argh. s/post/add to comments in umodarith.h/
--
___
Python tracker
<http://bugs.python.org/
New submission from Stefan Behnel :
The ElementC14N.py module by Fredrik Lundh implements XML canonicalisation for
the ElementTree serialiser. Given that the required API hooks to use it are
already in xml.etree.ElementTree, this would make a nice, simple and straight
forward addition to the
Stefan Krah added the comment:
> For my part, a two-lines description of the purpose of file is enough.
OK, I'll go for small comments in the files themselves and put big
ones in separate files.
--
___
Python tracker
<http://bugs
Stefan Behnel added the comment:
I started a mailing list thread on the same topic:
http://thread.gmane.org/gmane.comp.python.devel/127963
Especially see
http://thread.gmane.org/gmane.comp.python.devel/127963/focus=128162
where I extract a proposal from the discussion. Basically, there
Stefan Behnel added the comment:
Any comments on the last patch?
--
___
Python tracker
<http://bugs.python.org/issue13429>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
So the problem occurs on:
http://www.debian.org/ports/kfreebsd-gnu/
Did I get that right? Is __FreeBSD__ defined on that system?
I'm not sure though if we should start supporting hybrid systems.
--
___
P
New submission from Stefan Krah :
It used to be possible to specify Unicode fill characters in numeric
formatting:
Python 3.3.0a0 (default:1dd6908df8f5, Jul 16 2011, 11:16:00)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for mo
Stefan Krah added the comment:
Hum, somehow I always refuse to acknowledge that ASCII is a subset
of Unicode. :)
--
___
Python tracker
<http://bugs.python.org/issue13
Changes by Stefan Krah :
--
title: Unicode fill characters no longer work in numeric formatting ->
non-ascii fill characters no longer work in numeric formatting
___
Python tracker
<http://bugs.python.org/issu
Stefan Krah added the comment:
Actually the issue is not restricted to numeric formatting. It's not
possible to pad a Unicode string with a non-ascii whitespace:
>>> format("abcd", "\u2007<7")
Traceback (most recent call last):
File "", line 1,
Stefan Krah added the comment:
[Mark]
> So I think the current code is correct.
I agree with this. Currently the 'g' format is like to_sci_string()
with the added possibility of adjusting the number of significant
digits. It's probably hard to come up with a better way
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue13703>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
[[fill]align][sign][#][0][width][,][.precision][type]
The ',' must be before [.precision]:
>>> '{:,.2%}'.format(55.537568)
'5,553.76%'
In my opinion this is not a bug.
--
nosy: +skrah
__
Stefan Krah added the comment:
This should have been fixed in issue 11715. Could you try to
build from a mercurial checkout?
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue12
Stefan Krah added the comment:
Thanks for testing. I guess we can close this one then.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Stefan Krah :
There are still a couple of issues on the Fedora buildbot. Most of
them are caused by the absence of threading.
--
components: Tests
keywords: buildbot
messages: 136890
nosy: skrah, tarek
priority: normal
severity: normal
status: open
title
101 - 200 of 4949 matches
Mail list logo
