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)
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 to
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 b
-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
M
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 propos
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 decre
[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"
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 shouldn't
[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 1
> > 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
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 t
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 app
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
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
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 th
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
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 w
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 ba
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 Viehland
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 th
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 req
"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 thro
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 overhea
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
Python-Dev@python
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
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 ques
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:
W
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.
Th
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. :)
:
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.
No, the penalty gets smaller if there is only a single type.
For example, abst
Neal Norwitz schrieb:
> It would change the CheckExact()s from: op->ob_type ==
> global-variable, to: op->ob_type & CONSTANT == CONSTANT. Check would
> be the same as the CheckExact, just with different constants. The
> Check version would then drop the || condition.
Hmm. I don't see the for the
36 matches
Mail list logo
