I would also like to point out that I submitted a patch related to
that a couple of months ago in:
http://bugs.python.org/issue839159
But it never got any attention :( I'm not sure if it is still relevant.
Virgil
On 13-Sep-08, at 10:20 PM, Armin Ronacher wrote:
Hi everybody,
In Python
Armin Ronacher wrote:
Hi,
Benjamin Peterson musiccomposition at gmail.com writes:
Yes, according to PEP 11, support was removed in 2.4. I suppose this
also means we could killed macpath in py3k...
Pleaes don't do that. The OS 9 path handling is still present in OS X GUI
applications.
Hi,
Josiah Carlson josiah.carlson at gmail.com writes:
i = list(d.keys())
Obviously that doesn't solve the problem. list() consumes the generator
one after another, objects can still die when the list is created. Imagine
the following example which uses threads::
from time import sleep
Hi,
Adam Olsen rhamph at gmail.com writes:
IMO, this is a deeper problem than suggested. As far as I know,
python does not (and should not) make promises as to when it'll
collect object. We should expect weakrefs to be cleared at random
points, and code defensively.
It doesn't promise when
Armin Ronacher wrote:
Speaking of atom keys() / values() / items() operations: I guess we will
see more of those problems in threaded situations when people start to
convert code over to Python. I've seen quite a few situations where code
relays on keys() holding the interpreter lock.
On Sun, Sep 14, 2008 at 4:07 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
Neal Norwitz wrote:
test_epoll skipped -- kernel doesn't support epoll()
...
test_ioctl skipped -- Unable to open /dev/tty
...
test_multiprocessing skipped -- OSError raises on RLock creation, see
issue 3111!
...
test
Nick Coghlan schrieb:
Armin Ronacher wrote:
Speaking of atom keys() / values() / items() operations: I guess we will
see more of those problems in threaded situations when people start to
convert code over to Python. I've seen quite a few situations where code
relays on keys() holding the
Georg Brandl wrote:
Nick Coghlan schrieb:
Armin Ronacher wrote:
Speaking of atom keys() / values() / items() operations: I guess we will
see more of those problems in threaded situations when people start to
convert code over to Python. I've seen quite a few situations where code
relays on
On Sun, Sep 14, 2008 at 5:24 AM, Benjamin Peterson
[EMAIL PROTECTED] wrote:
On Sun, Sep 14, 2008 at 4:07 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
Neal Norwitz wrote:
test_epoll skipped -- kernel doesn't support epoll()
...
test_ioctl skipped -- Unable to open /dev/tty
...
C. Titus Brown wrote:
over on the pygr list, we were recently discussing a mildly confusing
edit I made:
assert 'seq1' in self.db, self.db.keys()
This was interpreted by someone as being
assert 'seq1' in (self.db, self.db.keys())
which is very different from the actual meaning,
On Sun, Sep 14, 2008 at 12:47 PM, Fredrik Lundh [EMAIL PROTECTED] wrote:
C. Titus Brown wrote:
over on the pygr list, we were recently discussing a mildly confusing
edit I made:
assert 'seq1' in self.db, self.db.keys()
This was interpreted by someone as being
assert 'seq1' in
On Sun, Sep 14, 2008 at 3:00 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
I think in general Python has erred on the side of having too many
different syntactical uses for commas. We killed a few in 3.0 with the
introduction of except E as v and the demotion of print to a
function call.
12 matches
Mail list logo
