[issue1691411] Duplicate "preferences" menu item/Tk Aqua 8.4.14

[Georg Brandl]

Changes by Georg Brandl <[EMAIL PROTECTED]>:


--
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

[issue2343] Raise a Py3K warning when using a float where an int is expected

[Brett Cannon]

Changes by Brett Cannon <[EMAIL PROTECTED]>:


--
assignee:  -> brett.cannon

__
Tracker <[EMAIL PROTECTED]>

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

[issue2013] Long object free list optimization

[Gregory P. Smith]

Gregory P. Smith <[EMAIL PROTECTED]> added the comment:

And the benchmarks of gps02... see the attached file.

At the end I had it run pybench rather than these microbenchmarks that
obviously show the speedup, the -gps02 patch ran 1.3% faster best case a
0.5% faster on average (32-bit; my mac's toolchain can't build enough of
py3k 64-bit to run pybench).

Things left for someone to do?  Determine what a good size for the
PyLong free list is.  4096 was a magic number chosen by tiran.

Added file: http://bugs.python.org/file9825/issue2013-benchmarks-gps02.txt

__
Tracker <[EMAIL PROTECTED]>

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

[issue2013] Long object free list optimization

[Gregory P. Smith]

Gregory P. Smith <[EMAIL PROTECTED]> added the comment:

Looking at how much memory was actually used by PyLongObjects the way
our code allocates them... we can use this freelist for 2 digit PyLongs
on 32-bit systems and for 4 digit PyLongs on 64-bit systems.  Doing this
speeds things up even more as numbers > 32767 are still quite common.

why?  sizeof(PyVarObject) == 12, sizeof(digit) == 2.  Objects/obmalloc.c
allocates on 8, 16 and 32 byte boundaries.  Theres no such thing as a 14
byte allocation, its 16 byte aligned.  The same applies for 64-bit
platforms where the sizeof(PyVarObject) == 24, our allocation size is 32
 bytes there.

patch attached as -gps02.

Added file: http://bugs.python.org/file9824/py3k_longfreelist2-gps02.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2460] Ellipsis not copyable

[Raymond Hettinger]

Changes by Raymond Hettinger <[EMAIL PROTECTED]>:


--
assignee:  -> rhettinger
nosy: +rhettinger
type: behavior -> 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

[issue2343] Raise a Py3K warning when using a float where an int is expected

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
type:  -> behavior

__
Tracker <[EMAIL PROTECTED]>

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

[issue2343] Raise a Py3K warning when using a float where an int is expected

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

I think so. The warning is implemented in getargs.c, so any conversion
from a float to int will result in a warning.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1038909] pydoc method documentation lookup enhancement

[Andy Harrington]

Andy Harrington <[EMAIL PROTECTED]> added the comment:

Several points:

Additional note in pydoc output:

I thought that 'inherited' docs should be marked, so I chose to add to
the note for any function that gets docs displayed from an inherited
function:
   ', docs from inherited '
Alternate verbiage could certainly be used, but I strongly believe that
the substitution should be marked and its source indicated.  This
addition occurs in HTMLDoc.docroutine and TextDoc.docroutine.


Elaboration?

If a user just calls help() or help(), this patch is certainly appropriate.  On the other hand, if
the call is help(), and the module includes the
definitions of the inherited classes from which documentation is
'inherited', then there is duplication within the output, which the user
might or might not desire.  To allow a choice would require a change in
parameters or a global flag in pydoc.  A global flag like
allow_doc_redundancy could be set to False to block inherited
documentation when the ancestor function is already putting a copy of
the documentation in the output.  I would be happy to add this change if
requested, but I thought it would be presumptuous of me to just add it
to the requested patch.  

Testing

I added a test specifically for the inherited docs,
test.test_pydoc_inheritance, generating documentaton on 
test.test_pydoc_sample and comparing results to previously generated
results files test/test_pydoc.txt and test/test_pydoc.html.  If further
changes to pydoc cause outward change to the documentation format, run
test_pydoc_inheritance.regenerateData() to replace the result files.

Nothing in the patch in 2.6 dependent.  Users could choose to upgrade
pydoc for 2.5.x

Added file: http://bugs.python.org/file9823/pydoc.PATCH

_
Tracker <[EMAIL PROTECTED]>

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

[issue2459] speedup loops with better bytecode

[Antoine Pitrou]

Changes by Antoine Pitrou <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file9820/loops.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2459] speedup loops with better bytecode

[Antoine Pitrou]

Changes by Antoine Pitrou <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file9822/loops2.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2343] Raise a Py3K warning when using a float where an int is expected

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

Is there any other place where this might be an issue? That's the real 
question; are all reasonable cases covered.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2460] Ellipsis not copyable

[Armin Ronacher]

New submission from Armin Ronacher <[EMAIL PROTECTED]>:

Currently python raises an exception if one tries to copy or deepcopy
Ellpisis.  The former is usually no problem but if an ellipsis ends up
on an object and becomes deepcopied this is pretty annoying.

The patch provided adds Ellipsis to the copy.py registry with the same
treatment None and other immutable types get.

--
components: Library (Lib)
files: ellipsis.diff
keywords: patch
messages: 64347
nosy: aronacher
severity: normal
status: open
title: Ellipsis not copyable
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9821/ellipsis.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue1616] compiler warnings

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

While we're at it, see 2388.

--
nosy: +benjamin.peterson

__
Tracker <[EMAIL PROTECTED]>

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

[issue2402] get rid of warnings in regrtest with -3

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
components: +Tests

__
Tracker <[EMAIL PROTECTED]>

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

[issue2402] get rid of warnings in regrtest with -3

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
type:  -> behavior

__
Tracker <[EMAIL PROTECTED]>

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

[issue2343] Raise a Py3K warning when using a float where an int is expected

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

This is already implemented:
>>> [].insert(.5, 0)
__main__:1: DeprecationWarning: integer argument expected, got float

--
nosy: +benjamin.peterson

__
Tracker <[EMAIL PROTECTED]>

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

[issue1810] AST compile() patch

[Armin Ronacher]

Changes by Armin Ronacher <[EMAIL PROTECTED]>:


--
nosy: +aronacher

__
Tracker <[EMAIL PROTECTED]>

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

[issue2459] speedup loops with better bytecode

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Sorry for the double post, the second message contains fixed benchmark
numbers.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2459] speedup loops with better bytecode

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

This is a preliminary patch to speedup for and while loops (it will also
be able to speedup list comps and gen comps, if I get to do it).
The patch works by putting the loop condition test at the end of loop,
which allows removing one JUMP_ABSOLUTE byte code out of the critical path.

For this two new opcodes are introduced:
- FOR_ITER2 is the same as FOR_ITER except that it does an /absolute/
jump if the iterator is /not/ exhausted (when other uses of FOR_ITER are
replaced with FOR_ITER2, we can of course restore the original naming)
- JUMP_ABS_IF_TRUE /pops/ the top of the stack and does an absolute jump
if its value is true

Some micro-benchmarks:

./python -m timeit "for x in xrange(1): pass"
Before: 1000 loops, best of 3: 782 usec per loop
After: 1000 loops, best of 3: 412 usec per loop

./python -m timeit "x=100" "while x: x -= 1"
Before: 1 loops, best of 3: 22.1 usec per loop
After: 10 loops, best of 3: 16.6 usec per loop

./python Tools/pybench/pybench.py -t ForLoops
Before: 365ms per round
After: 234ms per round

Also, pystone gets 5% faster (from 43300 to 45800).

Now for the less shiny things:

1. I'm having problems modifying the pure Python compiler module. For
some reasons it seems to have stricter requirements than compile.c
itself does (!); I get some assertion error in
compiler.pyassem.FlowGraph.fixupOrderHonorNext as soon as a loop gets
non-trivial.

2. Line numbers probably need to be fixed. The lnotab format may even
have to be adapted in order to accomodate non-monotonically increasing
line numbers.

Is there some interest in this patch? If yes, I'd like to have your
input on the two bullet points above :)

__
Tracker <[EMAIL PROTECTED]>

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

[issue2459] speedup loops with better bytecode

[Antoine Pitrou]

New submission from Antoine Pitrou <[EMAIL PROTECTED]>:

This is a preliminary patch to speedup for and while loops (it will also
be able to speedup list comps and gen comps, if I get to do it).
The patch works by putting the loop condition test at the end of loop,
which allows removing one JUMP_ABSOLUTE byte code out of the critical path.

For this two new opcodes are introduced:
- FOR_ITER2 is the same as FOR_ITER except that it does an /absolute/
jump if the iterator is /not/ exhausted (when other uses of FOR_ITER are
replaced with FOR_ITER2, we can of course restore the original naming)
- JUMP_ABS_IF_TRUE /pops/ the top of the stack and does an absolute jump
if its value is true

Some micro-benchmarks:

./python -m timeit "for x in xrange(1): pass"
Before: 1000 loops, best of 3: 782 usec per loop
After: 1000 loops, best of 3: 412 usec per loop

./python -m timeit -s "x=1" "while x: x -= 1"
Before: 100 loops, best of 3: 0.237 usec per loop
After: 1000 loops, best of 3: 0.176 usec per loop

./python Tools/pybench/pybench.py -t ForLoops
Before: 365ms per round
After: 234ms per round

Also, pystone gets 5% faster (from 43300 to 45800).

Now for the less shiny things:
1. I'm having problems modifying the pure Python compiler module. For
some reasons it seems to have stricter requirements than compile.c
itself does (!); I get some assertion error in
compiler.pyassem.FlowGraph.fixupOrderHonorNext as soon as a loop gets
non-trivial.
2. Line numbers probably need to be fixed. The lnotab format may even
have to be adapted in order to accomodate non-monotonically increasing
line numbers.

Is there some interest in this patch? If yes, I'd like to have your
input on the two bullet points above :)

--
components: Interpreter Core
files: loops.patch
keywords: patch
messages: 64342
nosy: pitrou
severity: normal
status: open
title: speedup loops with better bytecode
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file9820/loops.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1691411] Duplicate "preferences" menu item/Tk Aqua 8.4.14

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

Someone should close this as it has been fixed already.

--
nosy: +gpolo

_
Tracker <[EMAIL PROTECTED]>

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

[issue964437] idle help is modal

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

Hi,

This patch makes Help dialog executes as nonmodal. I added a new button
at textView.py to demonstrate the behavior, also, I created a decorator
called _singledialog at EditorWindow so just one Help window executes at
a time, trying to start a new brings the current one to the front.

I hope this issue is not totally dead, so someone could review and
possible apply.

--
keywords: +patch
nosy: +gpolo
Added file: http://bugs.python.org/file9819/help_nonmodal.diff


Tracker <[EMAIL PROTECTED]>


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

[issue1081824] Rewrite of docs for compiler.visitor

[Georg Brandl]

Changes by Georg Brandl <[EMAIL PROTECTED]>:


--
assignee: jhylton -> georg.brandl
nosy: +georg.brandl

_
Tracker <[EMAIL PROTECTED]>

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

[issue2458] Allow Python code to change Py3k warning flag

[Benjamin Peterson]

New submission from Benjamin Peterson <[EMAIL PROTECTED]>:

This patch removed sys.py3kwarning and adds sys.getpy3kwarn,
sys.enablepy3kwarn, and sys.disablepy3kwarn with docs. I also changed
the places in the Lib which used sys.py3kwarning.

--
files: change_py3kwarning.patch
keywords: patch
messages: 64339
nosy: benjamin.peterson
severity: normal
status: open
title: Allow Python code to change Py3k warning flag
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file9818/change_py3kwarning.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2446] 2to3 translates "import foobar" to "import .foobar" rather than "from . import foobar"

[David Wolever]

David Wolever <[EMAIL PROTECTED]> added the comment:

Ok, I've fixed this in r61755.

I _think_ it does the right thing, but it might be good if someone else 
checks out the test cases to make sure.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2013] Long object free list optimization

[Gregory P. Smith]

Gregory P. Smith <[EMAIL PROTECTED]> added the comment:

I'm attaching a slightly improved version of the longfreelist2 patch. 
It moves the important test to be first and removes the unneeded ? :
conditional.


Here are some more benchmarks:


--- issue2013-without-patch.txt 2008-03-22 12:18:37.0 -0700
+++ issue2013-longfreelist2-gps01-size-first.txt2008-03-22
12:34:44.0 -0700
@@ -1,43 +1,43 @@
-3.0a3+ (py3k:61746M, Mar 22 2008, 12:12:29) 
+3.0a3+ (py3k:61746M, Mar 22 2008, 12:33:47) 
 [GCC 4.0.1 (Apple Computer, Inc. build 5367)]
 
 ./python.exe -m timeit min(range(255))
 
-10 loops, best of 3: 17.2 usec per loop
+10 loops, best of 3: 15.8 usec per loop
 
 ./python.exe -m timeit -s n=100 sum(range(n,n+1))
 
-1000 loops, best of 3: 1.21 msec per loop
+1000 loops, best of 3: 1.22 msec per loop
 
 ./python.exe -m timeit sum(range(-32768,32768))
 
-100 loops, best of 3: 3.98 msec per loop
+100 loops, best of 3: 2.63 msec per loop
 
 ./python.exe -m timeit sum(range(-100,100))
 
-10 loops, best of 3: 296 msec per loop
+10 loops, best of 3: 273 msec per loop
 
 ./python.exe -m timeit sum(range(4000))
 
-1000 loops, best of 3: 239 usec per loop
+1 loops, best of 3: 151 usec per loop
 
 ./python.exe -m timeit sum(list(range(4000)))
 
-1000 loops, best of 3: 360 usec per loop
+1000 loops, best of 3: 274 usec per loop
 
 ./python.exe -m timeit sum(range(1))
 
-1000 loops, best of 3: 615 usec per loop
+1000 loops, best of 3: 382 usec per loop
 
 ./python.exe -m timeit sum(list(range(1)))
 
-1000 loops, best of 3: 887 usec per loop
+1000 loops, best of 3: 802 usec per loop
 
 ./python.exe -m timeit sum(range(4))
 
-100 loops, best of 3: 2.55 msec per loop
+100 loops, best of 3: 1.79 msec per loop
 
 ./python.exe -m timeit sum(range(8))
 
-100 loops, best of 3: 6.4 msec per loop
+100 loops, best of 3: 5.77 msec per loop
 


And a benchmarks of the longfreelist2 patch before my improvement:


--- issue2013-without-patch.txt 2008-03-22 12:18:37.0 -0700
+++ issue2013-longfreelist2.txt 2008-03-22 12:19:46.0 -0700
@@ -1,43 +1,43 @@
-3.0a3+ (py3k:61746M, Mar 22 2008, 12:12:29) 
+3.0a3+ (py3k:61746M, Mar 22 2008, 12:18:57) 
 [GCC 4.0.1 (Apple Computer, Inc. build 5367)]
 
 ./python.exe -m timeit min(range(255))
 
-10 loops, best of 3: 17.2 usec per loop
+10 loops, best of 3: 16.1 usec per loop
 
 ./python.exe -m timeit -s n=100 sum(range(n,n+1))
 
-1000 loops, best of 3: 1.21 msec per loop
+1000 loops, best of 3: 1.25 msec per loop
 
 ./python.exe -m timeit sum(range(-32768,32768))
 
-100 loops, best of 3: 3.98 msec per loop
+100 loops, best of 3: 2.95 msec per loop
 
 ./python.exe -m timeit sum(range(-100,100))
 
-10 loops, best of 3: 296 msec per loop
+10 loops, best of 3: 283 msec per loop
 
 ./python.exe -m timeit sum(range(4000))
 
-1000 loops, best of 3: 239 usec per loop
+1000 loops, best of 3: 177 usec per loop
 
 ./python.exe -m timeit sum(list(range(4000)))
 
-1000 loops, best of 3: 360 usec per loop
+1000 loops, best of 3: 276 usec per loop
 
 ./python.exe -m timeit sum(range(1))
 
-1000 loops, best of 3: 615 usec per loop
+1000 loops, best of 3: 453 usec per loop
 
 ./python.exe -m timeit sum(list(range(1)))
 
-1000 loops, best of 3: 887 usec per loop
+1000 loops, best of 3: 792 usec per loop
 
 ./python.exe -m timeit sum(range(4))
 
-100 loops, best of 3: 2.55 msec per loop
+100 loops, best of 3: 2.03 msec per loop
 
 ./python.exe -m timeit sum(range(8))
 
-100 loops, best of 3: 6.4 msec per loop
+100 loops, best of 3: 6.01 msec per loop
 


And diffs of longfreelist2 vs longfreelist2-gps01:

--- issue2013-longfreelist2.txt 2008-03-22 12:19:46.0 -0700
+++ issue2013-longfreelist2-gps01-size-first.txt2008-03-22
12:34:44.0 -0700
@@ -1,43 +1,43 @@
-3.0a3+ (py3k:61746M, Mar 22 2008, 12:18:57) 
+3.0a3+ (py3k:61746M, Mar 22 2008, 12:33:47) 
 [GCC 4.0.1 (Apple Computer, Inc. build 5367)]
 
 ./python.exe -m timeit min(range(255))
 
-10 loops, best of 3: 16.1 usec per loop
+10 loops, best of 3: 15.8 usec per loop
 
 ./python.exe -m timeit -s n=100 sum(range(n,n+1))
 
-1000 loops, best of 3: 1.25 msec per loop
+1000 loops, best of 3: 1.22 msec per loop
 
 ./python.exe -m timeit sum(range(-32768,32768))
 
-100 loops, best of 3: 2.95 msec per loop
+100 loops, best of 3: 2.63 msec per loop
 
 ./python.exe -m timeit sum(range(-100,100))
 
-10 loops, best of 3: 283 msec per loop
+10 loops, best of 3: 273 msec per loop
 
 ./python.exe -m timeit sum(range(4000))
 
-1000 loops, best of 3: 177 usec per loop
+1 loops, best of 3: 151 usec per loop
 
 ./python.exe -m timeit sum(list(range(4000)))
 
-1000 loops, best of 3: 276 usec per loop
+1000 loops, best of 3: 274 usec per loop
 
 ./python.exe -m timeit sum(range(10

[issue2457] add --help and -h options to pdb

[Benjamin Peterson]

New submission from Benjamin Peterson <[EMAIL PROTECTED]>:

If --help or -h are used as options for pdb, pdb unhelpfully exits with
"file -h cannot be found." This makes it more user friendly and prints
the usage if those options are passed.

--
components: Demos and Tools, Library (Lib)
files: pdb_help.patch
keywords: patch
messages: 64336
nosy: benjamin.peterson
severity: normal
status: open
title: add --help and -h options to pdb
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file9816/pdb_help.patch

__
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:

Here are the forward diffs of the 3 files against the version in the 
trunk.

--
versions: +Python 2.6 -Python 2.5
Added file: http://bugs.python.org/file9815/hires_hotshot_2.6.diffs.tgz

__
Tracker <[EMAIL PROTECTED]>

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

[issue1081824] Rewrite of docs for compiler.visitor

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

I have done some changes and did a patch against python-trunk

--
nosy: +gpolo
Added file: http://bugs.python.org/file9814/compiler.visitor_doc_update.diff

_
Tracker <[EMAIL PROTECTED]>

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

[issue1762940] struni: test_urllib2, test_cookielib

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

I think the patch was wrong. I question whether urllib *should* work on
str at all, given that URLs are byte strings.

In any case, the quoting is incorrect for str; it should implement rfc
3987, but currently does a mixture of Latin-1 and UTF-8.

--
nosy: +loewis

_
Tracker <[EMAIL PROTECTED]>

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

[issue2281] Enhanced cPython profiler with high-resolution timer

[Jean Brouwers]

Changes by Jean Brouwers <[EMAIL PROTECTED]>:


--
versions: +Python 3.0 -Python 2.5
Added file: http://bugs.python.org/file9813/_lsprof3.0.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2281] Enhanced cPython profiler with high-resolution timer

[Jean Brouwers]

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

Here are 2 forward diff files against _lspprof.c rev 59564.  One 
_lsprof2.6.diff for Python 2.6a1 and _lsprof3.0.diff for 3.0.

Added file: http://bugs.python.org/file9812/_lsprof2.6.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2456] Make sysmodule.c compatible with Bazaar

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
nosy: +benjamin.peterson

__
Tracker <[EMAIL PROTECTED]>

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

[issue2013] Long object free list optimization

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Here are some updated timings against the current py3k branch:

$ ./python -m timeit "sum(range(1))"

Without patch:
1000 loops, best of 3: 675 usec per loop
With patch:
1000 loops, best of 3: 462 usec per loop

$ ./python -m timeit -s "n=100" "sum(range(n, n+1))"

Without patch:
1000 loops, best of 3: 1.36 msec per loop
With patch:
1000 loops, best of 3: 1.38 msec per loop

$ ./python -m timeit "min(range(255))"

Without patch:
1 loops, best of 3: 18.7 usec per loop
With patch:
1 loops, best of 3: 19.4 usec per loop

As you can see the patch makes things quite a bit better for 1-digit
long objects, and there is only a small slowdown for longer or tiny
ints. Given that 1-digit long objects should be prevalent in most code I
think it's probably a winner overall.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1613573] xmlrpclib ServerProxy uses old httplib interface

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

There is another patch regarding the use of HTTP/1.1 for xmlrpclib at
http://bugs.python.org/issue1767370. The other issue could be update
with some comments from this issue and then this issue could be closed,
I believe.

--
nosy: +gpolo

_
Tracker <[EMAIL PROTECTED]>

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

[issue1858] Make .pypirc handle multiple servers

[Tarek Ziadé]

Changes by Tarek Ziadé <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file9614/distutils.2008-03-05.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1858] Make .pypirc handle multiple servers

[Tarek Ziadé]

Changes by Tarek Ziadé <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file9653/distutils.2008.03.11.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1858] Make .pypirc handle multiple servers

[Tarek Ziadé]

Changes by Tarek Ziadé <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file9652/distutils.2008.03.11.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1858] Make .pypirc handle multiple servers

[Tarek Ziadé]

Changes by Tarek Ziadé <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file9500/bugday-distutils.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1858] Make .pypirc handle multiple servers

[Tarek Ziadé]

Changes by Tarek Ziadé <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file9503/bugday.distutils.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1858] Make .pypirc handle multiple servers

[Tarek Ziadé]

Changes by Tarek Ziadé <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file9489/distutils.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2385] run_setup can fail if the setup script uses __file__

[Tarek Ziadé]

Changes by Tarek Ziadé <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file9724/distutils.core.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2385] run_setup can fail if the setup script uses __file__

[Tarek Ziadé]

Tarek Ziadé <[EMAIL PROTECTED]> added the comment:

new patch that adds __main__ and __file__, and make a chdir, so the
function is called in a realistic way.

this patch also adds test_core.py for this change.

Added file: http://bugs.python.org/file9811/2008-03-28-distutils.core.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2456] Make sysmodule.c compatible with Bazaar

[Barry A. Warsaw]

New submission from Barry A. Warsaw <[EMAIL PROTECTED]>:

For the Bazaar experiment ,
sysmodule.c needs to be made compatible with Bazaar, for build number
display.

--
assignee: barry
components: Interpreter Core
messages: 64327
nosy: barry
priority: normal
severity: normal
status: open
title: Make sysmodule.c compatible with Bazaar
type: crash
versions: Python 2.5, Python 2.6, Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue1054434] automatic XMLRPC boxcarring via multicall for xmlrpclib

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

I see these multicall classes (including tests) in python-trunk, except
for the threaded one. So, should this remain open ? If yes, what has to
be done here ?

--
nosy: +gpolo

_
Tracker <[EMAIL PROTECTED]>

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

[issue1328] Force BOM option in UTF output.

[Walter Dörwald]

Walter Dörwald <[EMAIL PROTECTED]> added the comment:

Oops, that code was supposed to read:

import codecs

def search_function(name):
if name == "myutf8":
utf8 = codecs.lookup("utf-8")
utf8_sig = codecs.lookup("utf-8-sig")
return codecs.CodecInfo(
name='myutf8',
encode=utf8.encode,
decode=utf8_sig.decode,
incrementalencoder=utf8.incrementalencoder,
incrementaldecoder=utf8_sig.incrementaldecoder,
streamreader=utf8_sig.streamreader,
streamwriter=utf8.streamwriter,
)


codecs.register(search_function)

__
Tracker <[EMAIL PROTECTED]>

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

[issue1328] Force BOM option in UTF output.

[Walter Dörwald]

Walter Dörwald <[EMAIL PROTECTED]> added the comment:

If you want to use UTF-8-sig for decoding and UTF-8 for encoding and
have this available as one codec you can define your owen codec for this:

import codecs

def search_function(name):
if name == "myutf8":
utf8 = codecs.lookup("utf-8")
utf8_sig = codecs.lookup("utf-8-sig")
return codecs.CodecInfo(
name='myutf8',
encode=utf8.encode,
decode=utf8_sig.decode,
incrementalencoder=utf8.IncrementalEncoder,
incrementaldecoder=utf8_sig.IncrementalDecoder,
streamreader=utf8_sig.StreamReader,
streamwriter=utf8.StreamWriter,
)


codecs.register(search_function)

Closing the issue as "wont fix"

--
resolution:  -> wont fix
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

[issue1477] UnicodeDecodeError that cannot be caught in narrow unicode builds

[Walter Dörwald]

Walter Dörwald <[EMAIL PROTECTED]> added the comment:

The patch looks goog to me now. Go ahead and check it in.

--
assignee: doerwalter -> amaury.forgeotdarc

__
Tracker <[EMAIL PROTECTED]>

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

[issue1605] Semi autogenerated _types module

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

On Fri, Mar 21, 2008 at 11:06 PM, Guido van Rossum <[EMAIL PROTECTED]>
wrote:

>
> Guido van Rossum <[EMAIL PROTECTED]> added the comment:
>
> >  Well, okay. I still think we should expose these core interpreter types
> >  somehow, so people can identify types easily. I don't want to be forced
> >  to finding the type of sys._getframe to tell if I have a frame object
> on
> >  my hands. Where would you put them?
>
> Perhaps that one belongs together with sys._getframe?
>
> You don't seem to be getting my point (or you are purposely ignoring
> it), and this is frustrating for me. If these types must be exposed
> they should be each be exposed in a a module (new or existing) that
> defines other objects (types, functions, constants, what have you)
> with a related purpose. So maybe dict views etc. can be in
> collections. And maybe module, function, class, properties, some
> standard decorators (classmethod, staticmethod) and various types of
> methods and method wrappers can be in a module that packages code
> structures. OTOH code, frame, traceback may be more suitable for a
> low-level module (although I'm not sure about traceback, perhaps it is
> closer exceptions). Many types of iterators may best be placed in
> itertools (which defines them in the first place, many operations
> there already *are* their own type). But the iterators over the
> built-in collection types (list, dict etc.) should probably live in
> collections again.

I understand your point; I just didn't understand the extent that you want
to go to.

>
>
> You see, coming up with a meaningful grouping is not all that easy --
> but that's no reason to lump them all together in a "built-in-types"
> module. Another criterion for grouping is whether the types make sense
> for other implementations like Jython, IronPython or PyPy, or not.

It is indeed hard.

>
>
> I'm all for exposing these. But I'm 100% against just collecting all
> those types and putting them in a single grab-bag module.
>
> __
> Tracker <[EMAIL PROTECTED]>
> 
> __
>

Added file: http://bugs.python.org/file9810/unnamed

__
Tracker <[EMAIL PROTECTED]>

__On Fri, Mar 21, 2008 at 11:06 PM, Guido van 
Rossum [EMAIL PROTECTED]> 
wrote:

Guido van Rossum [EMAIL 
PROTECTED]> added the comment:

>  Well, okay. I still think we should expose these core interpreter 
types
>  somehow, so people can identify types easily. I don't want to be 
forced
>  to finding the type of sys._getframe to tell if I have a frame 
object on
>  my hands. Where would you put them?

Perhaps that one belongs together with sys._getframe?

You don't seem to be getting my point (or you are purposely ignoring
it), and this is frustrating for me. If these types must be exposed
they should be each be exposed in a a module (new or existing) that
defines other objects (types, functions, constants, what have you)
with a related purpose. So maybe dict views etc. can be in
collections. And maybe module, function, class, properties, some
standard decorators (classmethod, staticmethod) and various types of
methods and method wrappers can be in a module that packages code
structures. OTOH code, frame, traceback may be more suitable for a
low-level module (although I'm not sure about traceback, perhaps it is
closer exceptions). Many types of iterators may best be placed in
itertools (which defines them in the first place, many operations
there already *are* their own type). But the iterators over the
built-in collection types (list, dict etc.) should probably live in
collections again.I understand your point; I just didn't 
understand the extent that you want to go to.


You see, coming up with a meaningful grouping is not all that easy --
but that's no reason to lump them all together in a 
"built-in-types"
module. Another criterion for grouping is whether the types make sense
for other implementations like Jython, IronPython or PyPy, or 
not.It is indeed hard.


I'm all for exposing these. But I'm 100% against just collecting all
those types and putting them in a single grab-bag module.

__
Tracker [EMAIL PROTECTED]>
http://bugs.python.org/issue1605>
__

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

[issue1943] improved allocation of PyUnicode objects

[Marc-Andre Lemburg]

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:

I wasn't clear enough: my point was that your free list patch would
probably benefit from some tuning of the cut-off parameters. 15
characters appears to be too small (see the HISTORY file histogram). 

You'll likely get better results for 32 and 256 as cut-off values and by
increasing the max list sizes to higher values, e.g. 1024 for the 32
character slots and 146 for the 256 character slots (see the counts in
the histograms).

__
Tracker <[EMAIL PROTECTED]>

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

[issue1721812] A subclass of set doesn't always have __init__ called.

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

Attaching a possible fix (untested).

--
keywords: +patch
Added file: http://bugs.python.org/file9809/set.diff

_
Tracker <[EMAIL PROTECTED]>

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

[issue2349] Py3K warn against assigning to True/False

[Raymond Hettinger]

Raymond Hettinger <[EMAIL PROTECTED]> added the comment:

Keep what you've got but don't lose sleep if some offbeat case is not 
covered.

--
assignee: rhettinger -> brett.cannon

__
Tracker <[EMAIL PROTECTED]>

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

[issue1918] weak references are removed before __del__ is called.

[Georg Brandl]

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

Done in r61733.

--
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

[issue908441] default index for __getslice__ is not sys.maxint

[Georg Brandl]

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

Closing as Fixed.

--
nosy: +georg.brandl
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