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 ca
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 '
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,
a
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
>> ...
>>
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
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() holdin
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!
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.
lis
Hi,
Adam Olsen 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 obje
Hi,
Josiah Carlson 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
from weakref
10 matches
Mail list logo
