[issue2119] Empty test

[Martin v. Löwis]

New submission from Martin v. Löwis <[EMAIL PROTECTED]>:

Follow-up

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2249] To document "assertTrue" in unittest

[Jesús Cea Avión]

Jesús Cea Avión <[EMAIL PROTECTED]> added the comment:

I noted the issue while working in bsddb3 module. If failed in python2.3
because some tests were using "assertTrue". I had to dig where that
method came from (time lost!) and found that a) it was added in python
2.4 and b) it is not documented.

Since "assertTrue" use is "in the wild", being undocumented is a
inconvenience. Moreover, I think "assertTrue" is far more intuitive and
cleaner than "assert_" or "failUnless". A personal impression, of
course. Symmetric with "assertEqual" and so, would be nice.

I won't insist, in any case :-)

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2258] Update command line docs for issue 1739468

[Nick Coghlan]

New submission from Nick Coghlan <[EMAIL PROTECTED]>:

The ability to execute zip files and directories containing a
__main__.py file needs to be covered in the documentation of the command
line options.

--
assignee: ncoghlan
components: Documentation
keywords: easy
messages: 63412
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Update command line docs for issue 1739468
versions: Python 2.6

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1617161] Instance methods compare equal when their self's are equal

[Armin Rigo]

Armin Rigo <[EMAIL PROTECTED]> added the comment:

My mistake, you are right.  I forgot about one of the many types that
CPython uses internally for built-in methods.  Indeed:

>>> [].index == [].index
False
>>> [].__add__ == [].__add__
True

I can fix this so that the answer is True in all cases; alternatively,
considering Frank Niessink's original issue, we could bring this
discussion to python-dev and decide what the correct behavior should be
and implement it consistently for all method types.

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1617161] Instance methods compare equal when their self's are equal

[Frank Niessink]

Frank Niessink <[EMAIL PROTECTED]> added the comment:

Just to reiterate the original bug report: the issue (for me) is that
currently (python 2.5):
>>> [].__add__  == [].__add__
True
>>> [].__add__  == [1].__add__
False

Or, using a non-builtin class:
>>> class C(object):
...   def __eq__(self, other):
... return False
...   def foo(self):
...  pass
...
>>> C().foo == C().foo
False
>>> class C(object):
...   def __eq__(self, other):
... return True
...   def foo(self):
... pass
...
>>> C().foo == C().foo
True

I think it makes little sense that the equality test for the instance
methods takes the equality of the instances into account. Imho, this
behaviour is inconsistent with the principle of no surprises. The
correct behaviour (again imho of course) is that instance methods only
compare equal to the same instance method of the same instance, where 
'same instance' is based on 'is' not on '=='.  

Cheers, Frank

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1617161] Instance methods compare equal when their self's are equal

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

Armin,

I think this should be discussed on python-dev.  I don't understand your 
motivation for comparing methods of distinct but equal objects as equal.  
The callback argument on the other hand, is compelling.

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2249] To document "assertTrue" in unittest

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

FWIW, grepping through Lib/test reveals the following statistics:

assertFalse: 83
assertTrue: 97
failUnless: 684
assert_: 1977

Not having assertTrue/assertFalse methods in the Library Reference does 
not discourage people from using them given that they show up without 
any warning in help().  (Moreover, assertTrue shows up before assert_.)

I would say it should be documented.  After all it would only take a two 
line patch (see attached). 

(I agree with OP that assertTrue is clearer than assert_ . Although I 
know that '_' is only there to avoid a conflict with the assert keyword,   
assert_ always stand out as different from the other TestCase methods.)

--
keywords: +patch
nosy: +belopolsky
Added file: http://bugs.python.org/file9639/doc-unittest.diff

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2249] To document "assertTrue" in unittest

[Steve Purcell]

Steve Purcell <[EMAIL PROTECTED]> added the comment:

+1 for applying Alexander's patch, then; I'll leave the decision to a 
current committer.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2249] To document "assertTrue" in unittest

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

Just to make the story complete, it should be mentioned that 
assertFalse/True were added because these are the names used by JUnit:


r34209 | purcell | 2003-09-22 07:08:12 -0400 (Mon, 22 Sep 2003) | 11 
lines
..
- New assertTrue and assertFalse aliases for comfort of JUnit users

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2259] Poor support other than 44.1khz, 16bit audio files?

[Oki Mikito]

New submission from Oki Mikito <[EMAIL PROTECTED]>:

It appears that aifc, as well as wave, does not support audio files other 
than 44100 hz 16-bit format.

--
>>> f = aifc.open('Track 06')
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/aifc.py", 
line 928, in open
return Aifc_read(f)
  File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/aifc.py", 
line 341, in __init__
self.initfp(f)
  File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/aifc.py", 
line 321, in initfp
chunk.skip()
  File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/chunk.py", 
line 158, in skip
self.file.seek(n, 1)
  File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/chunk.py", 
line 111, in seek
raise RuntimeError
RuntimeError
--

Could it be that the 'Chunk' class in chunk module may be returning improper 
values...? In any case, aifc refuses to open a 24bit 44100hz audio file. 
Does anyone have insights on this?

--
components: Library (Lib)
messages: 63419
nosy: loki_dePlume
severity: major
status: open
title: Poor support other than 44.1khz, 16bit audio files?
type: feature request
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2249] To document "assertTrue" in unittest

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Okay, I give in :) Committed as r61329.

--
resolution: wont fix -> fixed
status: pending -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1617161] Instance methods compare equal when their self's are equal

[Paul Pogonyshev]

Paul Pogonyshev <[EMAIL PROTECTED]> added the comment:

Since I'm not on python-dev, I'll mention here that the new behavior
makes no sense to me at all.  Which is best highlighted by Frank in
msg63414.

--
nosy: +_doublep

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2260] conditional jump to a POP_TOP optimization

[Paul Pogonyshev]

New submission from Paul Pogonyshev <[EMAIL PROTECTED]>:

This optimization targets a common case of functions like this:

def foo(a, b):
if a:
if b:
return 'true'

Before the optimization:
  6   0 LOAD_FAST0 (a)
  3 JUMP_IF_FALSE   16 (to 22)
  6 POP_TOP

  7   7 LOAD_FAST1 (b)
 10 JUMP_IF_FALSE5 (to 18)
 13 POP_TOP

  8  14 LOAD_CONST   1 ('true')
 17 RETURN_VALUE
>>   18 POP_TOP
 19 JUMP_FORWARD 1 (to 23)
>>   22 POP_TOP
>>   23 LOAD_CONST   0 (None)
 26 RETURN_VALUE

After:
  6   0 LOAD_FAST0 (a)
  3 JUMP_IF_FALSE   16 (to 22)
  6 POP_TOP

  7   7 LOAD_FAST1 (b)
 10 JUMP_IF_FALSE9 (to 22)
 13 POP_TOP

  8  14 LOAD_CONST   1 ('true')
 17 RETURN_VALUE
 18 POP_TOP
 19 JUMP_FORWARD 1 (to 23)
>>   22 POP_TOP
>>   23 LOAD_CONST   0 (None)
 26 RETURN_VALUE

Note that size of bytecode doesn't become smaller, however one execution
branch (jump from offset 10) becomes shorter by one JUMP_FORWARD.  

Additionally, two commands at offset 18 become unreachable.  However,
they will not be removed by the patch in issue1394 currently, because
there is a basic-block change at 18, where JUMP_IF_FALSE previously had
its target.  If we want unreachable code be removed in such cases, we
need to make peepholer make two passes with recomputing blocks[] in
between.  This would enable more optimizations.

--
components: Interpreter Core
files: jump-to-pop-optimization.diff
keywords: patch
messages: 63422
nosy: _doublep
severity: minor
status: open
title: conditional jump to a POP_TOP optimization
Added file: http://bugs.python.org/file9640/jump-to-pop-optimization.diff

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2261] Warning: could not send message for past 4 hours

[Paul Molodowitch]

New submission from Paul Molodowitch <[EMAIL PROTECTED]>:

**
**  THIS IS A WARNING MESSAGE ONLY  **
**  YOU DO NOT NEED TO RESEND YOUR MESSAGE  **
**

The original message was received at Sun, 9 Mar 2008 05:01:30 GMT
from [EMAIL PROTECTED]

   - Transcript of session follows -
451 spamgourmet.com: Name server timeout
451 spamgourmet.com: Name server timeout
451 gmail.com: Name server timeout
Warning: message still undelivered after 4 hours
Will keep trying until message is 5 days old
451 spamgourmet.com: Name server timeout

--
files: unnamed, unnamed
messages: 63423
nosy: barnabas79
severity: normal
status: open
title: Warning: could not send message for past 4 hours
Added file: http://bugs.python.org/file9641/unnamed
Added file: http://bugs.python.org/file9642/unnamed

__
Tracker <[EMAIL PROTECTED]>

__--- Begin Message ---

Paul Molodowitch added the comment:

Patch for sgmllib.py (and test_sgmllib.py)

Correctly parses quoted attribute - allowing for brackets, newlines, etc
within attributes - implemented by altering the loop which finds
attributes within parse_starttag so it checks for open-ended quotes, and
makes sure any closing brackets it finds are not within quotes

In test_sgmllib, added the test case from the original patch, as well as
re-enabling two other test cases, which both work now

--
keywords: +patch
nosy: +barnabas79
Added file: http://bugs.python.org/file9638/sgmllib_2008-03-08.patch

_
Tracker <[EMAIL PROTECTED]>

_

--- End Message ---
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2260] conditional jump to a POP_TOP optimization

[Paul Pogonyshev]

Paul Pogonyshev <[EMAIL PROTECTED]> added the comment:

Also, this is the reason for while() in the patch.  Consider this function:

def bar(a, b, c):
if a:
if b:
if c:
return 'true'

Before the patch:
 11   0 LOAD_FAST0 (a)
  3 JUMP_IF_FALSE   27 (to 33)
  6 POP_TOP

 12   7 LOAD_FAST1 (b)
 10 JUMP_IF_FALSE   16 (to 29)
 13 POP_TOP

 13  14 LOAD_FAST2 (c)
 17 JUMP_IF_FALSE5 (to 25)
 20 POP_TOP

 14  21 LOAD_CONST   1 ('true')
 24 RETURN_VALUE
>>   25 POP_TOP
 26 JUMP_ABSOLUTE   34
>>   29 POP_TOP
 30 JUMP_FORWARD 1 (to 34)
>>   33 POP_TOP
>>   34 LOAD_CONST   0 (None)
 37 RETURN_VALUE

After:
 11   0 LOAD_FAST0 (a)
  3 JUMP_IF_FALSE   27 (to 33)
  6 POP_TOP

 12   7 LOAD_FAST1 (b)
 10 JUMP_IF_FALSE   20 (to 33)
 13 POP_TOP

 13  14 LOAD_FAST2 (c)
 17 JUMP_IF_FALSE   13 (to 33)
 20 POP_TOP

 14  21 LOAD_CONST   1 ('true')
 24 RETURN_VALUE
 25 POP_TOP
 26 JUMP_ABSOLUTE   34
 29 POP_TOP
 30 JUMP_FORWARD 1 (to 34)
>>   33 POP_TOP
>>   34 LOAD_CONST   0 (None)
 37 RETURN_VALUE

Without the while(), target for jump at offset 17 wouldn't be optimized,
because "jump to unconditional jump" optimization hasn't been done yet:
it is farther in the code.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2179] with should be as fast as try/finally

[Jeffrey Yasskin]

Jeffrey Yasskin <[EMAIL PROTECTED]> added the comment:

Thanks Nick and Amaury!

Amaury, what times are you seeing? It could be a just-gcc speedup, but I
wouldn't have thought so since the patch eliminates 2 times around the
eval loop. It could be that the overhead of WITH_CLEANUP is high enough
to drown out those iterations. You had mentioned optimizing the
PyObject_CallFunctionObjArgs() call before. If you're still seeing with
significantly slower than try, that's probably the right place to look.

Here are my current timings. To avoid the lock issues, I wrote
simple_cm.py containing:

class CM(object):
def __enter__(self):
pass
def __exit__(self, *args):
pass

$ ./python.exe -m timeit -s 'import simple_cm; cm = simple_cm.CM()'
'with cm: pass'
100 loops, best of 3: 0.885 usec per loop
$ ./python.exe -m timeit -s 'import simple_cm; cm = simple_cm.CM()'
'cm.__enter__()' 'try: pass' 'finally: cm.__exit__()'
100 loops, best of 3: 0.858 usec per loop

If __exit__ doesn't contain *args (making it not a context manager), the
try/finally time goes down to:
$ ./python.exe -m timeit -s 'import simple_cm; cm = simple_cm.CM()'
'cm.__enter__()' 'try: pass' 'finally: cm.__exit__()'
100 loops, best of 3: 0.619 usec per loop

I think in theory, with could be slightly faster than finally with the
same argument list, but it's pretty close now.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

[Jeffrey Yasskin]

New submission from Jeffrey Yasskin <[EMAIL PROTECTED]>:

I'm using Apple's gcc-4.0.1 on a 2.33GHz Intel Core 2 Duo to test this.
Measurements from other compilers or other chips would be cool.

Specifically, this patch:
 1) Moves the declarations of most of the local variables inside the
for(;;) loop. That shortens their lifetimes so that the compiler can
skip spilling them to memory in some cases. Pushing them further down
into the individual case statements didn't change the generated assembly
in most cases, although there are probably a few opcodes where it would.
 2) Eliminates the initialization of w, and fixes the "possibly used
uninitialized" warning by changing how the PRINT opcodes initialize it
from stream. That lets my compiler avoid using its stack entry most of
the time.
 3) In two hot opcodes, LOAD_FAST and LOAD_CONST, changes the 'x' to a
'w'. 'x' is always written to memory because it's used for error
detection, while 'w' can stay on the stack.
 4) Changes --_Py_Ticker in the periodic things check to _Py_Ticker--.
Because _Py_Ticker is volatile, predecrement (at least on my compiler)
needs 3 memory accesses, while postdecrement gets away with 2.

Together, these changes are worth about 3% on pybench on my machine.

--
components: Interpreter Core
files: elim_mem_refs.patch
keywords: patch, patch
messages: 63426
nosy: jyasskin
severity: normal
status: open
title: Helping the compiler avoid memory references in PyEval_EvalFrameEx
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9643/elim_mem_refs.patch

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

[Neal Norwitz]

Neal Norwitz <[EMAIL PROTECTED]> added the comment:

I bet with just a little more work, you could get rid of t and stream. 
t is only used for a single set of opcodes (STORE_SLICE+n).  stream is
only used for the PRINT opcodes.  The code in print could be moved to a
function which might allow the compiler to do a better job.  I'll
benchmark this later on amd64 and amd x86 linux boxes.  Maybe mac ppc g4
if I'm adventurous. :-)

--
nosy: +nnorwitz

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

[Neal Norwitz]

Neal Norwitz <[EMAIL PROTECTED]> added the comment:

Can't next_instr and stack_pointer move inside the for loop too?

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2261] Warning: could not send message for past 4 hours

[Martin v. Löwis]

Changes by Martin v. Löwis <[EMAIL PROTECTED]>:


--
resolution:  -> invalid
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2218] Enhanced hotshot profiler with high-resolution timer

[Jean Brouwers]

Jean Brouwers <[EMAIL PROTECTED]> added the comment:

Attached is the latest, hopefully final version of the enhanced and 
improved hotshot profiler files.  In addition to fixes for the 7 issues 
mentioned previously, type Py_ssize_t is used instead of size_t.  Use 
this verion 4 and discard all previous ones.

Please review this code in file _hotshot.c and let me know of any rule 
or guideline violations.  I am more than happy to correct any mistakes.

Added file: http://bugs.python.org/file9644/hires_hotshot4.tgz

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1600] str.format() produces different output on different platforms (Py30a2)

[Eric Smith]

Eric Smith <[EMAIL PROTECTED]> added the comment:

Issue closed with commit r60909.  Fixed as suggested by Mark Dickinson:
"The exponent always contains at least two digits, and only as many more
digits as necessary to represent the exponent."

--
resolution:  -> fixed
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

[Skip Montanaro]

Skip Montanaro <[EMAIL PROTECTED]> added the comment:

I've yet to run pybench, but I came get these warnings from
the compiler after applying the patch:

  ../Python/ceval.c: In function 'PyEval_EvalFrameEx':
  ../Python/ceval.c:772: warning: 'x' may be used uninitialized in this
function
  ../Python/ceval.c:770: warning: 'err' may be used uninitialized in
this function

Platform is Mac OS X 10.5.2 MacBook Pro, gcc version 4.0.1 (Apple Inc.
build 5465)

--
nosy: +skip.montanaro

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

[Skip Montanaro]

Skip Montanaro <[EMAIL PROTECTED]> added the comment:

Pybench doesn't show much difference for me, about 0.1% better on minimum
times.  A few tests are quite a bit worse (> 10%) with the patch
(Recursion, SimpleFloatArithmetic, StringPredicates, TryFinally).  A few
are quite a bit better (CompareFloatsIntegers, CompareIntegers,
DictWithFloatKeys).

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString.

[Alexandre Vassalotti]

Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment:

Thanks for the review!

> Your description of the patch is a bit misleading.  As far as I can
> tell only the first chunk (Python/import.c changes) addresses a
> potential buffer overflow.

Yes, you are right. It seems only the bug in import.c could easily be
exploited.

> 1. It will really help if you produce a test case that crashes the
> interpretor.  I am sure that will get noticed.

   % cat pkg/__init__.py
   __package__ = "\U000c9c9c9" * 900
   from . import f
   % ./python
   Python 3.0a3+ (py3k:61164, Mar  1 2008, 19:55:42)
   >>> import pkg
   *** stack smashing detected ***: ./python terminated
   [1]9503 abort (core dumped)  ./python

> 2. If any of buffer overflows apply to the current production
> versions (2.4 or 2.5) or even the alpha release (2.6a1), it would
> make sense to backport it to the trunk.

I don't think the trunk is affected in any way by the issues
mentioned here.

> The existing __doc__ processing code is correct.  Proposed code may be
> marginally faster, but will allow docstrings with embedded null
> characters, which may or may not be desirable (and may break other code
> that uses tp_doc)

Good call! I will check out if null-characters may pose a problem for
tp_doc and update the patch consequently.

> I don't think a repr of a python object can contain embedded null
> characters, but even if that were the case, the patched code would not
> support it because the resulting buffer is returned with
> PyUnicode_FromString(buf).

Oh, that is true. I will remove that part from the patch, then.

> Modules/datetimemodule.c
>
> Existing code compensates for an error in initial estimate of totalnew
> when it checks for overflow, but the proposed change will make code more
> efficient.

Right again.

> Modules/zipimport.c
[...]
> Modules/timemodule.c
[...]
> Modules/parsermodule.c
[...]

I need to check again the code for these three modules, before
commenting.

I will clean up the patch with your recommendation and post it
again. Thanks for taking the time to review my patch. It's greatly
appreciated.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

[Jeffrey Yasskin]

Jeffrey Yasskin <[EMAIL PROTECTED]> added the comment:

Neal, t and stream aren't likely to have much effect since they're used
so little. next_instr and stack_pointer are used to communicate between
loops, so they can't move inside. I eagerly await your benchmark runs. :)

Skip, I managed to reproduce the warnings with gcc-4.2.1, and while
they're wrong, I see why they're happening. The if (throwflag) block
skips to on_error, which misses the initializations of x and err. The
right way to fix it is either to eliminate the error-reporting behavior
of x and err or to extract on_error into a function, but for this patch
I would probably just keep x and err out of the loop.

Your numbers made me look closer at my results for individual tests, and
I'm now confused about how reliable pybench is. My gcc-4.0 was build
#5367 on OS X 10.4.11, and MacPorts' gcc-4.2.1 (with a necessary
configure.in tweak) still shows a 1-2% gain overall. But contrary to
your numbers, it gives me a 10% speedup in Recursion and a 1% slowdown
in CompareFloatsIntegers. My big losers are SimpleListManipulation with
an 18% loss on 4.2 and CompareInternedStrings with a 20% loss on 4.0,
but those are both small winners (~5%) on the opposite compiler! I
wouldn't be surprised if the overall numbers were different between even
slightly different machines and compilers, but I'm really surprised to
see the same tests affected in opposite directions. Is that common with
pybench and compiler changes?

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com