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
On Dec 8, 10:27 pm, John Machin <[EMAIL PROTECTED]> wrote:
> On Dec 9, 3:00 pm, Steven D'Aprano
>
>
>
> <[EMAIL PROTECTED]> wrote:
> > On Mon, 08 Dec 2008 19:10:00 -0800, Robert Dailey wrote:
> > > On Dec 8, 6:26 pm, Terry Reedy <[EMAIL PROTECTED]> wrote:
> > >> Robert Dailey wrote:
> > >> > stuff
On Dec 9, 3:00 pm, Steven D'Aprano
<[EMAIL PROTECTED]> wrote:
> On Mon, 08 Dec 2008 19:10:00 -0800, Robert Dailey wrote:
> > On Dec 8, 6:26 pm, Terry Reedy <[EMAIL PROTECTED]> wrote:
> >> Robert Dailey wrote:
> >> > stuff = vars()
>
> >> >>> vars() is globals()
> >> True
>
> >> > for key in stuff:
On Mon, 08 Dec 2008 19:10:00 -0800, Robert Dailey wrote:
> On Dec 8, 6:26 pm, Terry Reedy <[EMAIL PROTECTED]> wrote:
>> Robert Dailey wrote:
>> > stuff = vars()
>>
>> >>> vars() is globals()
>> True
>>
>> > for key in stuff:
>>
>> You just changed globals, which is aliased as stuff. Stuff changes
On Dec 8, 6:26 pm, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Robert Dailey wrote:
> > stuff = vars()
>
> >>> vars() is globals()
> True
>
> > for key in stuff:
>
> You just changed globals, which is aliased as stuff.
> Stuff changes.
>
> > print( key, '--', stuff[key] )
>
> > I get the followin
Robert Dailey wrote:
stuff = vars()
>>> vars() is globals()
True
for key in stuff:
You just changed globals, which is aliased as stuff.
Stuff changes.
print( key, '--', stuff[key] )
I get the following error message:
('CopyEmotionFX', '--', )
Traceback (most recent call last):
F
[robert]
> In very rare cases a program crashes (hard to reproduce) :
>
> * several threads work on an object tree with dict's etc. in it. Items
> are added, deleted, iteration over .keys() ... ). The threads are "good"
> in such terms, that this core data structure is changed only by atomic
> oper
[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
[robert]
> In very rare cases a program crashes (hard to reproduce) :
>
> * several threads work on an object tree with dict's etc. in it. Items
> are added, deleted, iteration over .keys() ... ). The threads are "good"
> in such terms, that this core data structure is changed only by atomic
> oper
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
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
> >>> [e for e in vars()]
> ['e', '__builtins__', 'rlcompleter', '__fil
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 iteration
> >>> e = None
> >>> [e for e in vars()]
33 matches
Mail list logo
