Greg Ewing schrieb:
Martin v. Löwis wrote:
We had this discussion before; if you use ob_size==0 to indicate
that it's an int, this space isn't needed in a long int.
What about int subclasses?
It's what Guido proposes.
It would still leave two types (perhaps three) at the C level,
so C code
Greg Ewing schrieb:
Guido van Rossum wrote:
I worry that dropping the special allocator will be too slow.
Surely there's some compromise that would allow
recently-used ints to be kept around, but reclaimed
if memory becomes low?
Hardly. The efficiency of the special-case allocator also
Greg Ewing schrieb:
There isn't? Actually a lot of APIs currently assumen that.
Also it means you'd pay a penalty every time you
access it, whereas presumably short ints are the
case we want to optimise for speed as well.
That penalty is already paid today. Much code dealing with
ints has a
On 8/15/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
That penalty is already paid today. Much code dealing with
ints has a type test whether it's an int or a long. If
int and long become subtypes of each other or of some abstract
type, performance will decrease even more because a subtype
test
On 8/15/06, Neil Schemenauer [EMAIL PROTECTED] wrote:
It would be nice if someone could bytecompile Lib using
Tools/compiler/compile.py and then run the test suite. I'd do it
myself but can't spare the time at the moment (I started but ran
into what seems to be a gcc bug along the way).
Has
Patch / Bug Summary
___
Patches : 404 open ( +2) / 3376 closed (+16) / 3780 total (+18)
Bugs: 860 open ( -1) / 6131 closed (+17) / 6991 total (+16)
RFE : 229 open ( +1) / 235 closed ( +1) / 464 total ( +2)
New / Reopened Patches
__
option
Can I suggest making 'python -t' the default, in 2.6? It makes python warn about mixing tabs and spaces in indentation. In Py3k, '-tt' (the error-raising version) will be the default, instead. I see too many newsbies with problems they can't figure out because they mix tabs and spaces (usually not
Thomas Wouters wrote:
Can I suggest making 'python -t' the default, in 2.6? It makes python
warn about mixing tabs and spaces in indentation.
+1.
In Py3k, '-tt' (the
error-raising version) will be the default, instead.
Or disallow tabs altogether.
I see too many
newsbies with
On Tue, Aug 15, 2006 at 10:44:40PM -0400, Kurt B. Kaiser wrote:
It would be nice if the key IDLE changes could make it to the What's New
in Python X.X. If Andrew is interested, I could draft something for him.
Sure! I can try to look through the IDLE NEWS file, but you'd
certainly have a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 16, 2006, at 7:37 AM, Thomas Wouters wrote:
Can I suggest making 'python -t' the default, in 2.6? It makes
python warn about mixing tabs and spaces in indentation. In Py3k, '-
tt' (the error-raising version) will be the default,
+1.
Guido I worry that dropping the special allocator will be too slow.
Greg Surely there's some compromise that would allow recently-used ints
Greg to be kept around, but reclaimed if memory becomes low?
Martin Hardly. The efficiency of the special-case allocator also comes
On 8/15/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Greg Ewing schrieb:
Martin v. Löwis wrote:
We had this discussion before; if you use ob_size==0 to indicate
that it's an int, this space isn't needed in a long int.
What about int subclasses?
It's what Guido proposes.
It would
Neal Norwitz wrote:
On 8/15/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
That penalty is already paid today. Much code dealing with
ints has a type test whether it's an int or a long. If
int and long become subtypes of each other or of some abstract
type, performance will decrease even more
[EMAIL PROTECTED] schrieb:
Guido I worry that dropping the special allocator will be too slow.
Greg Surely there's some compromise that would allow recently-used ints
Greg to be kept around, but reclaimed if memory becomes low?
Martin Hardly. The efficiency of the
Guido van Rossum schrieb:
I'm not sure that subclassing ints gives us much. We could make int
and long final types, and then all we have to do is tweak type() and
__class__ so that they always return the 'int' type.
I don't think this can work - there would be too many ways for the
real types
We've been working on fixing some exception handling bugs in IronPython where
we differ from CPython. Along the way we ran into this issue which causes
CPython to crash when the code below is run. It crashes on both 2.4 and 2.5
beta 3. The code's technically illegal, but it probably
[EMAIL PROTECTED] schrieb:
Wouldn't use of obmalloc offset much of that? Before obmalloc was
available, the int free list was a huge win. Is it likely to be such a huge
win today?
I have now some numbers. For the attached t.py, the unmodified svn
python gives
Test 1 3.25420880318
Test 2
python.org/sf/1540874 -- broken shortcut keys. On windows, only one
entry per menu can be reached with the same shortcut letter, so
advertising others is just an attractive nuisance. I'm not sure that
other systems wouldn't be able to use the hidden shortcuts.
On 8/15/06, Anthony Baxter
Neal Norwitz [EMAIL PROTECTED] wrote:
On 8/15/06, Neil Schemenauer [EMAIL PROTECTED] wrote:
It would be nice if someone could bytecompile Lib using
Tools/compiler/compile.py and then run the test suite.
Has this been done before?
Obviously not. :-)
# This code causes python to segfault
On 8/16/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
I have now some numbers. For the attached t.py, the unmodified svn
python gives
Test 1 3.25420880318
Test 2 1.86433696747
and the one with the attached patch gives
Test 1 3.45080399513
Test 2 2.09729003906
So there apparently is a
Dino Viehland [EMAIL PROTECTED] wrote:
We've been working on fixing some exception handling bugs in
IronPython where we differ from CPython. Along the way we ran into
this issue which causes CPython to crash when the code below is run.
It crashes on both 2.4 and 2.5 beta 3. The code's
Josiah Carlson wrote:
Dino Viehland [EMAIL PROTECTED] wrote:
We've been working on fixing some exception handling bugs in
IronPython where we differ from CPython. Along the way we ran into
this issue which causes CPython to crash when the code below is run.
It crashes on both 2.4 and 2.5
On 8/15/06, Neal Norwitz [EMAIL PROTECTED] wrote:
I was playing around with a little patch to avoid that penalty. It
doesn't take any additional memory, just a handful of bits we aren't
using. :-)
For the more common builtin types, it stores whether it's a subclass
in tp_flags, so there's
At 11:46 PM 8/15/2006 -0700, Neal Norwitz wrote:
On 8/15/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
That penalty is already paid today. Much code dealing with
ints has a type test whether it's an int or a long. If
int and long become subtypes of each other or of some abstract
type, performance
Guido van Rossum schrieb:
I think the test isn't hardly focused enough on int allocation. I
wonder if you could come up with a benchmark that repeatedly allocates
100s of 1000s of ints and then deletes them?
The question is: where to store them? In a pre-allocated list, or in a
growing list?
def test():
for abc in range(10):
try: pass
finally:
try:
pass
except:
pass
test()
does not raise a segmentation fault.
On Wed, 16 Aug 2006, Josiah Carlson wrote:
Dino Viehland [EMAIL PROTECTED] wrote:
We've been working
Neal Norwitz schrieb:
I was playing around with a little patch to avoid that penalty. It
doesn't take any additional memory, just a handful of bits we aren't
using. :-)
There are common schemes that allow constant-time issubclass tests,
although they do require more memory:
1. give each base
Yeah, continue inside the finally block is illegal. If you don't have the
extra try/except nesting then continue is detected as a syntax error.
-Original Message-
From: Dennis Allison [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 16, 2006 10:22 AM
To: Josiah Carlson
Cc: Dino
IronPython actually enables / disables stack overflow checking through either a
command line option or by calling sys.setrecursionlimit. By default we have no
recursion limit.
Without those command line options we'll end up having the CLR throw an
unrecoverable stack overflow exception (and
Martin v. Löwis wrote:
Neal Norwitz schrieb:
I was playing around with a little patch to avoid that penalty. It
doesn't take any additional memory, just a handful of bits we aren't
using. :-)
There are common schemes that allow constant-time issubclass tests,
although they do require more
A.M. Kuchling [EMAIL PROTECTED] writes:
On Tue, Aug 15, 2006 at 10:44:40PM -0400, Kurt B. Kaiser wrote:
It would be nice if the key IDLE changes could make it to the What's New
in Python X.X. If Andrew is interested, I could draft something for him.
Sure! I can try to look through the IDLE
Martin v. Löwis wrote:
Greg Ewing schrieb:
Also it means you'd pay a penalty every time you
access it
That penalty is already paid today.
You'd still have that penalty, *plus* the
overhead of bit masking to get at the value.
Maybe that wouldn't be noticeable among all
the other overheads,
Georg Brandl wrote:
Or disallow tabs altogether.
-1. I'd be annoyed if Python started telling me I wasn't
allowed to write my source the way my preferred editor
(BBEdit) works best. Very annoyed.
--
Greg
___
Python-Dev mailing list
Looks like revision 47154 introduced a regexp that hangs Python (Ctrl-C
won't kill the process, CPU usage sits near 100%) under some
circumstances. There's a test case here:
http://python.org/sf/1541697
The problem isn't seen if you read the whole file at once (or almost the
whole file at
On Thu, 17 Aug 2006, John J Lee wrote:
[...]
If nobody has time to fix this, perhaps rev 47154 should be reverted?
I should have put it more strongly: I think it *should* in fact be
reverted if nobody has time to fix it before the release candidate / final
release of 2.5. The revision in
Thanks Dino.
The attached patch should fix the problem. Once RC1 is cut, I'll
check this in unless someone beats me to it. Since the compiler
changed, I can't backport this. If someone wants to make a similar
fix for 2.4 go for it.
n
--
On 8/16/06, Dino Viehland [EMAIL PROTECTED] wrote:
On Aug 17, 2006, at 1:26 AM, Neal Norwitz wrote:
Thanks Dino.
The attached patch should fix the problem. Once RC1 is cut, I'll
check this in unless someone beats me to it. Since the compiler
changed, I can't backport this. If someone wants to make a similar
fix for 2.4 go for it.
The
On 8/16/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
It seems to me that you could drop the FAST_SUBCLASS bit, since none of the
other bits will be set if it is not a subclass of a builtin. That would
free up one flag bit -- perhaps usable for that BaseException flag Guido
wants. :)
:-)
38 matches
Mail list logo
