Here's the int questions. The entire list is too big to post (50k),
so it's here:
http://www.python.org/neal/header-ints
Should the following values be ints (limited to 2G)?
* dict counts (ma_fill, ma_used, ma_mask)
* line #s and column #s
* AST (asdl.h) sequences
* recursion limit
* read/
$ grep long */*.h
minus comments, etc yields several questions about whether some
values should use Py_ssize_t rather than C longs. In particular:
* hash values
Include/abstract.h: long PyObject_Hash(PyObject *o); // also in object.h
Include/object.h:typedef long (*hashfunc)(PyObject *);
On 5/28/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
> > On 5/28/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> >> In the process of reviewing and possibly extending getargs.c, I stumbled
> >> over the "compatibility" flag supposedly used for METH_OLDARGS functions.
> >> No code
On 5/28/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
>
> I think I've fixed the refleaks too, but running regrtest -R :: takes
> rther a while.
FYI, I typically run -R 4:3: since it seems to do a pretty good job
and takes 20% less time. I never run -R with -u all, only a normal
run or specif
On 5/29/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
On May 28, 2006, at 4:31 AM, Thomas Wouters wrote:>> I'm seeing a dubious failure of test_gzip and test_tarfile on my> AMD64 machine. It's triggered by the recent struct changes, but I'd> say it's probably caused by a bug/misfeature in zlibmodule:
On May 28, 2006, at 4:31 AM, Thomas Wouters wrote:
>
> I'm seeing a dubious failure of test_gzip and test_tarfile on my
> AMD64 machine. It's triggered by the recent struct changes, but I'd
> say it's probably caused by a bug/misfeature in zlibmodule:
> zlib.crc32 is the result of a zlib 'c
I am a recent subscriber to this list. A couple of months ago
I downloaded the Python source out of curiosity, then decided
to see if I could scratch a couple of small itches.
One of them was syntax errors reported on one line but actually
resulting from unbalanced brackets on the previous line.
On Sun, 28 May 2006, Armin Rigo wrote:
[...]
> Now I'm stumbling upon this test for urllib2:
>
>>>> mgr = urllib2.HTTPPasswordMgr()
>>>> add = mgr.add_password
>>>> add("Some Realm", "http://example.com/";, "joe", "password")
>>>> add("Some Realm", "http://example.com/ni";, "ni", "n
Georg Brandl wrote:
>> There's still a ton used under Modules. Also, if no flag is
>> specified, it will default to 0 (ie, METH_OLDARGS). I wonder how many
>> third party modules use METH_OLDARGS directly or more likely
>> indirectly.
>
> These modules can be converted.
I think that should be d
Michael Hudson wrote:
> Michael Hudson <[EMAIL PROTECTED]> writes:
>
>> I think I've fixed the refleaks too, but running regrtest -R :: takes
>> rther a while.
>
> I hadn't: test_codecs and test_codeccallbacks both leak, the latter
> quite spectacularly (9000+ refleaks a run). The test_codec
Michael Hudson <[EMAIL PROTECTED]> writes:
> I think I've fixed the refleaks too, but running regrtest -R :: takes
> rther a while.
I hadn't: test_codecs and test_codeccallbacks both leak, the latter
quite spectacularly (9000+ refleaks a run). The test_codecs leaks
come from calls to codecs.
Hi all,
I'm playing with dicts that mangle the hash they receive before using it
for hashing. The goal was to detect obscure dict order dependencies in
my own programs, but I couldn't resist and ran the Python test suite
with various mangling schemes. As expected -- what is not tested is
broken
Sorry I'm so far behind -- I'm aiming to get mostly caught up this
week. Please read through the summary if you have the time and send
me any comments or corrections.
Thanks!
=
Announcements
=
---
Python 2.5 schedule
---
Python 2.5 is mo
Georg Brandl <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>> Georg Brandl <[EMAIL PROTECTED]> writes:
>>
>>> Michael Hudson wrote:
>>>
So I think I'll be reading through exceptions.c pretty carefully. I
don't think Sean and Richard have acquired as much paranoid
anal-minded
Michael Hudson wrote:
> Georg Brandl <[EMAIL PROTECTED]> writes:
>
>> Michael Hudson wrote:
>>
>>> So I think I'll be reading through exceptions.c pretty carefully. I
>>> don't think Sean and Richard have acquired as much paranoid
>>> anal-mindedness and I have when hacking on Python C internals
Georg Brandl <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>
>> So I think I'll be reading through exceptions.c pretty carefully. I
>> don't think Sean and Richard have acquired as much paranoid
>> anal-mindedness and I have when hacking on Python C internals yet :)
>
> I intended to go thr
Neal Norwitz wrote:
> On 5/28/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> In the process of reviewing and possibly extending getargs.c, I stumbled
>> over the "compatibility" flag supposedly used for METH_OLDARGS functions.
>> No code in the core uses this calling convention any more, and it has
Michael Hudson wrote:
> So I think I'll be reading through exceptions.c pretty carefully. I
> don't think Sean and Richard have acquired as much paranoid
> anal-mindedness and I have when hacking on Python C internals yet :)
I intended to go through the code again today or tomorrow, looking for
The mailing-list bot said introduce myself so...
I'm Andy Chambers. I've been lurking on the web-interface to the list
for a while. I recently started trying to implement one of the items on
PEP 42 so I thought I should join the list and make myself known.
The item I'm working on is the new kin
"Thomas Wouters" <[EMAIL PROTECTED]> writes:
> Does 'a tuple containing two Nones, a string and an int' ring a bell to
> anyone? :)
I found this one on the train (look at SyntaxError_init, it's
obvious). I also found a number of other bugs in the new exceptions.c
code, from leaks:
>>> def f():
On 5/20/06, Hannu Krosing <[EMAIL PROTECTED]> wrote:
I try to move this to -dev as I hope there more people reading it whoare competent in internal working :). So please replay to -dev only.I'm not sure if you have found the problem on another mailinglist then, but I saw no answers on python-dev.
-
On 5/28/06, Tim Peters <[EMAIL PROTECTED]> wrote:
[... a huge number of reference leaks reported ...]FYI, I "reduced" the relatively simple test_bisect's leaks to thisself-contained program:Funny, I reduced it to more or less the same thing, except the other way 'round: I suspected exceptions to be
I'm seeing a dubious failure of test_gzip and test_tarfile on my AMD64 machine. It's triggered by the recent struct changes, but I'd say it's probably caused by a bug/misfeature in zlibmodule: zlib.crc32 is the result of a zlib 'crc32' functioncall, which returns an unsigned long.
zlib.crc32 turns
[... a huge number of reference leaks reported ...]
FYI, I "reduced" the relatively simple test_bisect's leaks to this
self-contained program:
libreftest = """
No actual doctests here.
"""
import doctest
import gc
def main():
from sys import gettotalrefcount as trc
for i in range(10
Raymond Hettinger wrote:
> No thanks. The resolution of this one was that windowing iterables is
> not a good idea. It is the natural province of sequences, not
> iterables. With sequences, it is a matter of using an index and
> offset. With iterables, there is a great deal of data shifting.
> In the process of reviewing and possibly extending getargs.c, I stumbled
> over the "compatibility" flag supposedly used for METH_OLDARGS functions.
> No code in the core uses this calling convention any more, and it has been
> deprecated for quite a long time (since 2.2), so would it be appropri
On 5/28/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> In the process of reviewing and possibly extending getargs.c, I stumbled
> over the "compatibility" flag supposedly used for METH_OLDARGS functions.
> No code in the core uses this calling convention any more, and it has been
> deprecated for qu
In the process of reviewing and possibly extending getargs.c, I stumbled
over the "compatibility" flag supposedly used for METH_OLDARGS functions.
No code in the core uses this calling convention any more, and it has been
deprecated for quite a long time (since 2.2), so would it be appropriate to e
28 matches
Mail list logo
