[issue1193577] add server.shutdown() method to SocketServer

2008-03-02 Thread Jeffrey Yasskin

Jeffrey Yasskin added the comment:

It seems that .await_request() was only added a month ago to fix issue
742598, so it's no great hardship to refactor it again now. Timeouts
never worked for .serve_forever() because the try/except in
.handle_request() turned their exception into a plain return, which
didn't stop .server_forever() from looping. Timeouts also seem to be
unnecessary in a situation in which shutdown works. Shutdown can only be
called from a separate thread, and when you have more threads you can
also do periodic tasks in them.

So I've made that explicit: the .serve_forever/shutdown combination
doesn't handle timeouts. [This has nothing to do with the fact that it
takes three times as much code to handle them. Don't look at the excuse
behind the curtain. ;)]

This patch needs some more documentation and a NEWS entry before it gets
submitted, but I want to check that everyone would be happy with the
concept.

--
nosy: +akuchling, pilcrow
versions: +Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9581/polling_shutdown.patch

_
Tracker <[EMAIL PROTECTED]>

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



[issue2176] Undocumented lastrowid attribute i sqlite3 cursor class

2008-03-02 Thread Pavel Vinogradov

Pavel Vinogradov added the comment:

This patch include brief lastrowid description based on my experience and 
Python DB API 2.0 PEP.

--
keywords: +patch
nosy: +pavel.vinogradov
Added file: http://bugs.python.org/file9582/lastrowid_rst_desctiption.diff

__
Tracker <[EMAIL PROTECTED]>

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



[issue2216] Problems using logging module with idle

2008-03-02 Thread Andrea Griffini

New submission from Andrea Griffini:

I'm not a user of idle, but when asked about a strange behaviour of the
logging module I digged a bit and found what I think is indeed a problem
in the module itself.
The problem is visible if the module is used from idle (or any other IDE
that keeps the same python instance running for multiple execution of
user code); if you call basicConfig(filename="foo.txt"), do some logging
and call shutdown() the handler is closed (correctly closing the file)
but remains attached to the root logger, and gets called again at next
run (giving an error for invalid I/O on a closed file).
This can also be reproduced in a single run with

import logging
logging.basicConfig(filename="logtest.txt")
logging.warning("This is a test")
logging.shutdown()
logging.basicConfig(filename="logtest2.txt")
logging.warning("This is a test (2)")
logging.shutdown()

I think that it is not correct to close the handler but leave it in
place, so I tried patching the module so that every handler keeps a list
of all loggers it is attached to, and removes itself from loggers at
close() time. This way the above code runs correctly (creating two
files) and the logging module still passes the test suite.
I must however admit that logging logic is a bit beyond my grasp
(including a close() call commented out, some uses of lock/release I
don't understand) so may be the attached patch is not correct even if
passes the test.

--
components: Library (Lib)
files: logging.patch
keywords: patch
messages: 63179
nosy: ag6502
severity: normal
status: open
title: Problems using logging module with idle
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9583/logging.patch

__
Tracker <[EMAIL PROTECTED]>

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



[issue2200] find_executable fails to find .bat files on win32

2008-03-02 Thread Lev Shamardin

Lev Shamardin added the comment:

Here is my vision of this patch. I don't think that it is necessary to
fall back to 'com/exe/bat' if PATHEXT is not set, since it must be set
on any correctly configured Win32 platform.

--
keywords: +patch
Added file: http://bugs.python.org/file9584/spawn.patch

__
Tracker <[EMAIL PROTECTED]>

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



[issue687648] classic division in demos/ directory

2008-03-02 Thread Robert Schuppenies

Robert Schuppenies added the comment:

The attached patch applies floor division to all classic divisions where
only integer input was used, and true division where at least on input
parameter was of non-integral type. 
In cmptree.py I replaced "int(size/dt)" with "size//dt" as it has the
same semantic but I thought it to be more explicit.

--
keywords: +patch
nosy: +okkoto
Added file: http://bugs.python.org/file9585/demo_classicdivision.diff


Tracker <[EMAIL PROTECTED]>


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



[issue2217] Problem with if clause in generator expression on class level

2008-03-02 Thread Christoph Zwerschke

New submission from Christoph Zwerschke:

The following code throws a NameError which seems to be a bug existing
since Python 2.4 up to the current 2.5.2.

class A:
a = 'test'
[c for c in a]
(c for c in a)
tuple(c for c in a)
[c for c in a if c in a]
(c for c in a if c in a)
tuple(c for c in a if c in a) # --> NameError

--
components: Interpreter Core, Library (Lib), Macintosh, Regular Expressions, 
Tests, Tkinter, Unicode, Windows, XML
messages: 63182
nosy: cito
severity: normal
status: open
title: Problem with if clause in generator expression on class level
type: behavior
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



[issue2217] Problem with if clause in generator expression on class level

2008-03-02 Thread Georg Brandl

Georg Brandl added the comment:

This may seem odd, but is correct as per spec.

The "if c in a" part is executed in a scope of its own, and class scopes
don't contribute to nested scoping.

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



[issue2217] Problem with if clause in generator expression on class level

2008-03-02 Thread Christoph Zwerschke

Christoph Zwerschke added the comment:

Thanks for the quick explanation. I understand that class scopes don't
extend and this is documented behavior.

However, the question is why the if clause is executed in a scope of its
own and where this is documented.

You would expect that the problematic generator expression is equivalent
to the following code which works fine:

class A:
a = 'test'
def __g(a):
for c in a:
if c in a:
yield c
tuple(__g(a))

__
Tracker <[EMAIL PROTECTED]>

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



[issue1193577] add server.shutdown() method to SocketServer

2008-03-02 Thread Jeffrey Yasskin

Jeffrey Yasskin added the comment:

I'll submit the attached patch in a couple days unless I get comments.

Added file: http://bugs.python.org/file9586/polling_shutdown.patch

_
Tracker <[EMAIL PROTECTED]>

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



[issue1672853] Error reading files larger than 4GB

2008-03-02 Thread Joseph Armbruster

Joseph Armbruster added the comment:

Just got in from New Smyrna beach... and the verdict is:

URL:  http://svn.python.org/projects/python/branches/release25-maint
Revision: 61182

python bigfiletest1.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150

_
Tracker <[EMAIL PROTECTED]>

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



[issue2217] Problem with if clause in generator expression on class level

2008-03-02 Thread Georg Brandl

Georg Brandl added the comment:

The actual equivalent would be

class A:
a = 'test'
def __g(_x):
for c in _x:
if c in a:
yield c
tuple(__g(a))

i.e. the outmost iterator is evaluated in the enclosing scope; not the
if clause is in its own scope, but the whole genexp.

__
Tracker <[EMAIL PROTECTED]>

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



[issue2215] test_sqlite fails in 2.6a1 on MacOS X

2008-03-02 Thread Mark Dickinson

Mark Dickinson added the comment:

I don't think this is Mac specific---one of the linux buildbots has also 
been having this problem, it seems.  I think it's a result of having
an older version of sqlite3 installed.

My OS X 10.4 box has sqlite3 version 3.1.3 installed, and that
version doesn't support the 'if not exists ...' syntax.

The test works fine on OS X 10.5, with sqlite3 version 3.4.0.

I don't know what Python should be doing for older versions of sqlite3.

--
nosy: +marketdickinson

__
Tracker <[EMAIL PROTECTED]>

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



[issue2217] Problem with if clause in generator expression on class level

2008-03-02 Thread Christoph Zwerschke

Christoph Zwerschke added the comment:

Thanks, this now makes sense to me. You're right, it's rather an ugly
wart than a bug.

But I think the Python reference needs to be improved to make this clear
enough.

How about the following proposed addtions (in square brackets) to
section 5.2.5 (http://docs.python.org/ref/genexpr.html):

"Variables used in the generator expression are evaluated lazily [in the
scope of the generator function] when the next() method is called for
[the] generator object (in the same fashion as normal generators).
However, the leftmost for clause is immediately evaluated [in the
current scope] so that [an] error produced by it can be seen before any
other possible error in the code that handles the generator expression.
Subsequent for [and if] clauses cannot be evaluated immediately since
they may depend on the previous for loop."

__
Tracker <[EMAIL PROTECTED]>

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



[issue2215] test_sqlite fails in 2.6a1 on MacOS X

2008-03-02 Thread Jean Brouwers

Jean Brouwers added the comment:

Just for the record, the test continues to fail if rerun with 2.6a1.  

However, the (same?) test does *not* fail with 3.0a3 built on the same 
MacOS X system.

__
Tracker <[EMAIL PROTECTED]>

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



[issue2215] test_sqlite fails in 2.6a1 on MacOS X

2008-03-02 Thread Christian Heimes

Christian Heimes added the comment:

Some modifications to the 2.6 code base didn't make it into 3.0 in time.
See r61141

--
nosy: +tiran

__
Tracker <[EMAIL PROTECTED]>

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



[issue2215] test_sqlite fails in 2.6a1 on MacOS X

2008-03-02 Thread Jean Brouwers

Jean Brouwers added the comment:

In addition, the sqlite test did *not* fail with 2.5.2 and 2.5.1 built on 
the same MacOS X machine, about one week resp. several months ago.

__
Tracker <[EMAIL PROTECTED]>

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



[issue1736190] asyncore/asynchat patches

2008-03-02 Thread Giampaolo Rodola'

Giampaolo Rodola' added the comment:

I've discussed a lot with Josiah via e-mail and this is the updated
version of the patch including a fix for the two issues raised before.
This update has been needed also because the original patch has been
out-dated by some commits after r53734 involving the test suite
and the documentation, which I both took off this patch.
I also re-added simple_producer and fifo classes in asynchat.py since it
seems they are needed for passing tests.

The test suite has passed on Windows XP using Python 2.6 alpha 1.
I have also successfully run the test suite of a project of mine based
on asynchat which includes over 40 tests.

Added file: http://bugs.python.org/file9587/patch.diff

_
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

2008-03-02 Thread Jean Brouwers

New submission from Jean Brouwers:

The _hotshot module uses the gettimeofday function to profile the run 
time.

I enhanced the hotshot module in Python 2.5.2 to use a high resolution 
timer where available (RDTSC on x86/_64, MFTB/U on PowerPC and gethrtime 
on Solaris).

The improved hotshot module has been tested on 32-bit MacOS X 10.4.11 
Tiger (Intel) and 10.3.9 Panther (PPC), on 64-bit RHEL 3u7 (Opteron) and 
on 64-bit Solaris 10.

The 3 modified files are Modules/_hotshot.c, Lib/hotshot/log.py and 
Lib/hotshot/stats.py are attached.

--
components: Extension Modules
files: hires_hotshot.tgz
messages: 63194
nosy: MrJean1
severity: normal
status: open
title: Enhanced hotshot profiler with high-resolution timer
type: feature request
versions: Python 2.5
Added file: http://bugs.python.org/file9588/hires_hotshot.tgz

__
Tracker <[EMAIL PROTECTED]>

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



[issue2215] test_sqlite fails in 2.6a1 on MacOS X

2008-03-02 Thread Gerhard Häring

Gerhard Häring added the comment:

Revision 61141 made the test work with old SQLite versions.

__
Tracker <[EMAIL PROTECTED]>

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



[issue2215] test_sqlite fails in 2.6a1 on MacOS X

2008-03-02 Thread Gerhard Häring

Changes by Gerhard Häring:


__
Tracker <[EMAIL PROTECTED]>

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



[issue2215] test_sqlite fails in 2.6a1 on MacOS X

2008-03-02 Thread Gerhard Häring

Gerhard Häring added the comment:

r61174 made the tests work with old SQLite versions.

__
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

2008-03-02 Thread Jeffrey Yasskin

Jeffrey Yasskin added the comment:

Here's a proof-of-concept patch that keeps the __exit__ method on the
stack. It uses ROT_TWO to stuff it under the context object instead of
storing it into a temporary. (Thanks Nick for pointing out that problem
before I had to waste time on it.) test_with passes, although I need to
update several more things and maybe fix a refleak.

The patch changes the compilation of:

def with_(l):
with l:
pass

from

  4   0 LOAD_FAST0 (l)
  3 DUP_TOP 
  4 LOAD_ATTR0 (__exit__)
  7 STORE_FAST   1 (_[1])
 10 LOAD_ATTR1 (__enter__)
 13 CALL_FUNCTION0
 16 POP_TOP 
 17 SETUP_FINALLY4 (to 24)

  5  20 POP_BLOCK   
 21 LOAD_CONST   0 (None)
>>   24 LOAD_FAST1 (_[1])
 27 DELETE_FAST  1 (_[1])
 30 WITH_CLEANUP
 31 END_FINALLY 
 32 LOAD_CONST   0 (None)
 35 RETURN_VALUE

to

  4   0 LOAD_FAST0 (l)
  3 DUP_TOP 
  4 LOAD_ATTR0 (__exit__)
  7 ROT_TWO 
  8 LOAD_ATTR1 (__enter__)
 11 CALL_FUNCTION0
 14 POP_TOP 
 15 SETUP_FINALLY4 (to 22)

  5  18 POP_BLOCK   
 19 LOAD_CONST   0 (None)
>>   22 WITH_CLEANUP
 23 END_FINALLY 
 24 LOAD_CONST   0 (None)
 27 RETURN_VALUE


And speeds it up from:

$ ./python.exe -m timeit -s 'import thread; lock =
thread.allocate_lock()' 'with lock: pass'
100 loops, best of 3: 0.832 usec per loop

to:

$ ./python.exe -m timeit -s 'import thread; lock =
thread.allocate_lock()' 'with lock: pass'
100 loops, best of 3: 0.762 usec per loop


That's only half of the way to parity with try/finally:

$ ./python.exe -m timeit -s 'import thread; lock =
thread.allocate_lock()' 'lock.acquire()' 'try: pass' 'finally:
lock.release()'
100 loops, best of 3: 0.638 usec per loop

What's strange is that calling __enter__ and __exit__ in a try/finally
block brings the speed back to the faster 'with' speed, even though they
call the same C functions:

$ ./python.exe -m timeit -s 'import thread; lock =
thread.allocate_lock()' 'lock.__enter__()' 'try: pass' 'finally:
lock.__exit__()'
100 loops, best of 3: 0.754 usec per loop

Any ideas?

--
keywords: +patch
Added file: http://bugs.python.org/file9589/faster_with.patch

__
Tracker <[EMAIL PROTECTED]>

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



[issue1740] use unittest for test_logging

2008-03-02 Thread Brett Cannon

Brett Cannon added the comment:

Committed in r61189 on the trunk. Thanks, Antoine!

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



[issue1740] use unittest for test_logging

2008-03-02 Thread Brett Cannon

Brett Cannon added the comment:

Oh, and thanks Thomas for the port change. I made sure to keep it.

__
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

2008-03-02 Thread Jeffrey Yasskin

Jeffrey Yasskin added the comment:

Now with documentation, a working test_compile, and one less refleak.

Added file: http://bugs.python.org/file9590/faster_with.patch

__
Tracker <[EMAIL PROTECTED]>

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



[issue795081] email.Message param parsing problem II

2008-03-02 Thread Tony Nelson

Tony Nelson added the comment:

If I understand RFC2822 3.2.2. Quoted characters (heh), unquoting must
be done in one pass, so the current replace().replace() is wrong.  It
will change '\\"' to '"', but it should become '\"' when unquoted.

This seems to work:

re.sub(r'\\(.)',r'\1',s)

I haven't encountered a problem with this; I just came across it while
looking at the file Utils.py (Python 2.4, but unchanged in trunk).  I
will submit a new bug if desired.

--
nosy: +tony_nelson


Tracker <[EMAIL PROTECTED]>


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



[issue1107887] Speed up function calls/can add more introspection info

2008-03-02 Thread Jeffrey Yasskin

Changes by Jeffrey Yasskin:


--
nosy: +jyasskin

_
Tracker <[EMAIL PROTECTED]>

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