Robert Dailey wrote:
When I do:
for key in stuff.keys():
It works! I wonder why .keys() makes a difference. It is using a
'view', which is a new concept in Python 3.0 that I'm not totally
familiar with yet.
Because stuff.keys() is evaluated *once* and the result is a separate
object from s
aliased as stuff. Stuff changes.
>
> > >> > print( key, '--', stuff[key] )
>
> > >> > I get the following error message:
> > >> > ('CopyEmotionFX', '--', )
> > >> > Traceback (most recent call last):
> > >>
or message:
> >> > ('CopyEmotionFX', '--', )
> >> > Traceback (most recent call last):
> >> > File "C:\IT\work\jewett\depends.py", line 12, in
> >> > for key in stuff:
> >> > RuntimeError: dictionary cha
:
>>
>> You just changed globals, which is aliased as stuff. Stuff changes.
>>
>> > print( key, '--', stuff[key] )
>>
>> > I get the following error message:
>> > ('CopyEmotionFX', '--', )
>> > Traceback (m
> > print( key, '--', stuff[key] )
>
> > I get the following error message:
> > ('CopyEmotionFX', '--', )
> > Traceback (most recent call last):
> > File "C:\IT\work\jewett\depends.py", line 12, in
> > for key in
27;, )
Traceback (most recent call last):
File "C:\IT\work\jewett\depends.py", line 12, in
for key in stuff:
RuntimeError: dictionary changed size during iteration
Why is this happening?
--
http://mail.python.org/mailman/listinfo/python-list
', '--', )
Traceback (most recent call last):
File "C:\IT\work\jewett\depends.py", line 12, in
for key in stuff:
RuntimeError: dictionary changed size during iteration
Why is this happening?
--
http://mail.python.org/mailman/listinfo/python-list
t;>>> cPickle.dump(obj, f)
>
> "RuntimeError: dictionary changed size during iteration" is raised by
> .dump ( or a similar "..list changed ..." )
>
> What can I do about this to get a stable pickle-dump without risiking
> execution erro
[robert]
> That queue/passing-through-only-an-extra-global-var communication is
> acceptable for thin thread interaction.
> ( hope this extra global var is thread-safe in future Python's :-) )
>
> But "real" thread-programming should also be possible in Python - and it
> is with the usual disciplin
> robert wrote:
> Meanwhile I think this is a bug of cPickle.dump: It should use .keys()
> instead of free iteration internally, when pickling elementary dicts.
> I'd file a bug if no objection.
What should happen if there's a delete between the time the .keys()
runs and the time that the deleted
Raymond Hettinger wrote:
>>Is a copy.deepcopy ( -> "cPickle.dump(copy.deepcopy(obj),f)" ) an
>>atomic opertion with a guarantee to not fail?
>
> No. It is non-atomic.
>
> It seems that your application design intrinsically incorporates a race
> condition -- even if deepcopying and pickling were
You can also *almost* do it with a tracehook that blocks until released
by another thread. See http://projects.amor.org/misc/wiki/PyConquer for
the tool I'm sporadically working on that does that (in an effort to
test all possible execution paths). The only limitation is that trace
functions aren't
Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
...
> This is vaguely possible using sys.setcheckinterval() now, although one
> has to pick a ridiculously large number and hope that the atomic operation
> takes fewer than that many opcodes.
>
> Spelling "do not switch threads" as sys.setcheckint
On 12 Mar 2006 17:56:37 -0800, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
>Thinking about future directions for Python threading, I wonder if
>there is a way to expose the GIL (or simply impose a temporary
>moratorium on thread switches) so that it becomes easy to introduce
>atomicity when need
t;>>> cPickle.dump(obj, f)
>
> "RuntimeError: dictionary changed size during iteration" is raised by
> .dump ( or a similar "..list changed ..." )
>
> What can I do about this to get a stable pickle-dump without risiking
> execution error or even wo
robert si è profuso/a a scrivere su comp.lang.python tutte queste
elucubrazioni:
> Yes, a "backup" / autosave while all threads are running. It doesn't
> matter if 'before' of 'after' another item has been added/deleted
> atomically.
But it does matter if the autosave happens *while* an item i
Tim Peters wrote:
> [robert]
>
>>...
>>PS: how does ZODB work with this kind of problem? I thought is uses cPickle?
>
>
> It does. Each thread in a ZODB application typically uses its own
> connection to a database. As a result, each thread gets its own
> consistent view of database objects,
EleSSaR^ wrote:
> robert si è profuso/a a scrivere su comp.lang.python tutte queste
> elucubrazioni:
>
>
>>own deepcopy: thus, do you already know if the existing deepcopy has the
>>same problem as cPickle.dump ?(as the problem araises rarely, it is
>>difficult for me to test it out)
>
>
[robert]
> ...
> PS: how does ZODB work with this kind of problem? I thought is uses cPickle?
It does. Each thread in a ZODB application typically uses its own
connection to a database. As a result, each thread gets its own
consistent view of database objects, which can (and routinely does)
vary
robert si è profuso/a a scrivere su comp.lang.python tutte queste
elucubrazioni:
[cut]
P.S.
I'm very bad at threaded programming. Please verify any of my suggestions
^_^
--
EleSSaR^ <[EMAIL PROTECTED]>
--
Togli .xyz dalla mia email per contattarmi.
--
http://mail.python.org/mailman/listinfo/
robert si è profuso/a a scrivere su comp.lang.python tutte queste
elucubrazioni:
> own deepcopy: thus, do you already know if the existing deepcopy has the
> same problem as cPickle.dump ?(as the problem araises rarely, it is
> difficult for me to test it out)
I don't know the exact specs
robert <[EMAIL PROTECTED]> wrote:
...
> 99.99% no. I would have to use a lock everywhere, where I add or remove
> something into a dict or list of the struct. Thats not the purpose of
> big thread locks. Such simple operations are already atomic by the
> definition of Python - and thanks to the
EleSSaR^ wrote:
> robert si è profuso/a a scrivere su comp.lang.python tutte queste
> elucubrazioni:
>
> [cut]
>
> I don't know what's your code like, but a similar error occurred in some of
> my software and it was my fault indeed. I think you should either use a
> lock, or implement a deepcop
Felipe Almeida Lessa wrote:
> Em Sáb, 2006-03-11 às 12:49 +0100, robert escreveu:
>
>>Meanwhile I think this is a bug of cPickle.dump: It should use .keys()
>>instead of free iteration internally, when pickling elementary dicts.
>>I'd file a bug if no objection.
>
>
> AFAICS, it's a problem w
robert si è profuso/a a scrivere su comp.lang.python tutte queste
elucubrazioni:
[cut]
I don't know what's your code like, but a similar error occurred in some of
my software and it was my fault indeed. I think you should either use a
lock, or implement a deepcopy method of your own.
--
EleSSa
Em Sáb, 2006-03-11 às 12:49 +0100, robert escreveu:
> Meanwhile I think this is a bug of cPickle.dump: It should use .keys()
> instead of free iteration internally, when pickling elementary dicts.
> I'd file a bug if no objection.
AFAICS, it's a problem with your code. You should lock your objec
robert wrote:
>
>> Is a copy.deepcopy ( -> "cPickle.dump(copy.deepcopy(obj),f)" ) an
>> atomic opertion with a guarantee to not fail?
>>
>> Or can I only retry several times in case of RuntimeError? (which
>> would apears to me as odd gambling; retry how often?)
>
>
> For an intermediate so
> Is a copy.deepcopy ( -> "cPickle.dump(copy.deepcopy(obj),f)" ) an
> atomic opertion with a guarantee to not fail?
>
> Or can I only retry several times in case of RuntimeError? (which would
> apears to me as odd gambling; retry how often?)
For an intermediate solution, I'm playing roulette
ations, so that the data structure is always consistent regarding
the application. Only the change-operations on the dicts and lists
itself seem to cause problems on a Python level ..
* one thread periodically pickle-dumps the tree to a file:
>>> cPickle.dump(obj, f)
"RuntimeE
Title: RE: RuntimeError: dictionary changed size during iteration
[Terry Reedy]
#- You must be having a bad day ;-). From Lib Ref 2.1 Built-in
Well, that's actually true, :(
#- corresponding to the object's symbol table. The returned
#- dictionary should
#- not be mod
RE: RuntimeError: dictionary changed size during iteration
"Batista, Facundo" <[EMAIL PROTECTED]> wrote
[Robert Brewer]
#- But not unexpected, since vars() returns a dictionary, and
#- binding 'e'
#- changes that dictionary while you are iterating over it.
>For me,
On Thu, 20 Jan 2005, Batista, Facundo wrote:
>For me, the point is: vars() returns the local variables as a list or is a
>generator?
>
>In the docs don't say nothing about this.
>
>If it returns a list, it should NOT raise an error; if it's a generator, the
>error is fine.
>
>.Facundo
>
Prob
Title: RE: RuntimeError: dictionary changed size during iteration
[Robert Brewer]
#- > >>> [e for e in vars()]
#- > Traceback (most recent call last):
#- > File "", line 1, in ?
#- > RuntimeError: dictionary changed size during iteration
#- > >
Roman Suzi wrote:
> I think, the behaviour below is misfeature:
>
> >>> [e for e in vars()]
> Traceback (most recent call last):
> File "", line 1, in ?
> RuntimeError: dictionary changed size during iteration
> >>> e = None
> >>
On Wed, Jan 19, 2005 at 11:45:15PM +0300, Roman Suzi wrote:
>
> I think, the behaviour below is misfeature:
>
> >>> [e for e in vars()]
> Traceback (most recent call last):
> File "", line 1, in ?
> RuntimeError: dictionary changed size during iterati
I think, the behaviour below is misfeature:
>>> [e for e in vars()]
Traceback (most recent call last):
File "", line 1, in ?
RuntimeError: dictionary changed size during iteration
>>> e = None
>>> [e for e in vars()]
['e', '__builtins__'
36 matches
Mail list logo
