Re: pyvm source code
stelios xanthakis si è profuso/a a scrivere su comp.lang.python tutte queste elucubrazioni: > What's good about it is that it's small and easier to > hack and write large scale programs using pyvm as the > base runtime. On the other hand, pyvm is not compatible > with python and AFAIC there is no plan doing this as > a hobby. I'm sorry I don't get it. Could you please explain it better? What are the advantages of this pyvm compared to the 'original' Python? Python is available on x86-linux, so it's not an additional platform. Maybe it's faster? Has it got a smaller memory footprint? Or what? -- Alan Franzoni <[EMAIL PROTECTED]> - Togli .xyz dalla mia email per contattarmi. Rremove .xyz from my address in order to contact me. - GPG Key Fingerprint: 5C77 9DC3 BD5B 3A28 E7BC 921A 0255 42AA FE06 8F3E -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonic wrappers for SQL?
Kenneth McDonald si è profuso/a a scrivere su comp.lang.python tutte queste elucubrazioni: > there any good libraries out there that let one write (basic) queries > in a Pythonic syntax, rather than directly in SQL? You need an ORM. Beyond SQLAlchemy (I don't have experience with it) i would suggest you try out SQLObject and PyDO. Just a clue: although they prevent you from writing SQL, you'll have to learn SQL basics anyway, or you won't understand the docs. If you simply want to forget SQL, you can try out Axiom: http://divmod.org/trac/wiki/DivmodAxiom It's a native object database; it uses sqlite as backend, but that's totally transparent to the user, you'll never be asked to enter a single sql statement. -- EleSSaR^ <[EMAIL PROTECTED]> -- Togli .xyz dalla mia email per contattarmi. -- http://mail.python.org/mailman/listinfo/python-list
Re: SQLObject connection pooling
[EMAIL PROTECTED] si è profuso/a a scrivere su comp.lang.python tutte queste elucubrazioni: > Hello. Does SQLObject provide connection pooling? If so, is it > automatic or do I have to do something to manage it? If not, how do > people generally solve this problem? I think you will have better luck on gmane.comp.python.sqlobject this group is a bit too generic for such fine-tuned questions. -- EleSSaR^ <[EMAIL PROTECTED]> -- Togli .xyz dalla mia email per contattarmi. -- http://mail.python.org/mailman/listinfo/python-list
Re: looping over more than one list
Iain King si è profuso/a a scrivere su comp.lang.python tutte queste elucubrazioni: [cut] I think you should take a look at the zip() function. You can use for with it like this: for elem1, elem2, elem3 in zip(list1, list2, list3): -- Alan Franzoni <[EMAIL PROTECTED]> - Togli .xyz dalla mia email per contattarmi. Rremove .xyz from my address in order to contact me. - GPG Key Fingerprint: 5C77 9DC3 BD5B 3A28 E7BC 921A 0255 42AA FE06 8F3E -- http://mail.python.org/mailman/listinfo/python-list
Re: "RuntimeError: dictionary changed size during iteration" ; Good atomic copy operations?
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. -- EleSSaR^ <[EMAIL PROTECTED]> -- Togli .xyz dalla mia email per contattarmi. -- http://mail.python.org/mailman/listinfo/python-list
Re: "RuntimeError: dictionary changed size during iteration" ; Good atomic copy operations?
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 of your object, and I don't know what operations are you performing on that object, nor the way they're atomic. It seems like you're trying to save periodically the state of such object while it is being modified (a sort of backup?), and Python complains about that. A self-implemented deepcopy might raise anomalies (i.e. your dumped object may be partly a 'before' object and partly an 'after' object ) as well. By the way, you could try employing locks from other threads to dump the object as well... this would prevent additional locking. > PS: how does ZODB work with this kind of problem? I thought is uses cPickle? I have no idea about this. -- EleSSaR^ <[EMAIL PROTECTED]> -- Togli .xyz dalla mia email per contattarmi. -- http://mail.python.org/mailman/listinfo/python-list
Re: "RuntimeError: dictionary changed size during iteration" ; Good atomic copy operations?
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/python-list
Re: "RuntimeError: dictionary changed size during iteration" ; Good atomic copy operations?
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 is being
updated, I suppose. E.g. if a single 'atomic' operation would change two
dictionaries, and an autosave triggers after the first has been changed and
the second hasn't, this would be an unwanted autosave, right?
>> By the way, you could try employing locks from other threads to dump the
>> object as well... this would prevent additional locking.
>
> Don't understand.
> The threads work all simulatniously on the object tree, add and detach
> atomically only valid sub-trees.
You're never using any lock, then? Isn't it possible that two threads try
changing the very same dict/list at the same time? Just one more question:
are you running your software on a single-cpu machine?
> change "subobj.x='y'" is a dictionary operation. That would make
> threaded programming very arduous.
Well... threaded programming usually is a hard task. No surprise so many
people prefer async programming nowadays. It makes many things simpler.
> def rt_save_dict_copy()
>tod={}
>for k in fromd.keys():
> try: tod[k]=fromd[k]
> except: pass
>return tod
>
> without true iteration over the original dict whould copy without
> RuntimeError.
But with no warranty of data consistency. It will prevent new values to be
computed, but if one value from the dict is modified during iteration, the
dict may be left in a never-existed state:
import random
random.seed()
fromd = {1:1, 2:2, 3:3, 4:4, 5:5}
print "dict before iteration:", fromd
def rt_save_dict_copy():
tod={}
for k in fromd.keys():
try:
tod[k]=fromd[k]
except:
pass
fromd[random.choice(xrange(1,6))] = random.choice(xrange(1,10))
return tod
print "copied dict:", rt_save_dict_copy()
print "dict after copy:", fromd
--
EleSSaR^ <[EMAIL PROTECTED]>
--
Togli .xyz dalla mia email per contattarmi.
--
http://mail.python.org/mailman/listinfo/python-list
