[ANN] Elasticluster 1.0.1, a tool for cluster provisioning in the cloud
The Grid Computing Competence Center (GC3) is pleased to announce release 1.0.1 of Elasticluster. Elasticluster is a Python tool to automate the creation, configuration and management of clusters of virtual machines hosted on a cloud. It can provision clusters on Amazon's Elastic Compute Cloud EC2 and compatible ones, like OpenStack. Elasticluster leverages the Ansible automation framework to deploy and configure software on the virtual cluster. Any Ansible playbook can in principle be used with Elasticluster; the default distribution contains recipes for: * Hadoop clusters with HDFS * HPC clusters based on SLURM, SGE, or PBS * storage clusters running Ceph, GlusterFS or PVFS A video demoes the basic features of Elasticluster setting up a SLURM compute cluster: http://youtu.be/cR3C7XCSMmA The code is available from PyPI and GitHub. If you are interested, please visit http://gc3-uzh-ch.github.io/elasticluster/ or get in touch with us at elasticlus...@googlegroups.com. Kind regards, (for the Grid Computing Competence Center) Riccardo Murri -- Riccardo Murri http://www.gc3.uzh.ch/people/rm Grid Computing Competence Centre University of Zurich Winterthurerstrasse 190, CH-8057 Zürich (Switzerland) Tel: +41 44 635 4222 Fax: +41 44 635 6888 -- http://mail.python.org/mailman/listinfo/python-list
difference between `x in list` and `list.index(x)` for instances of a new-style class
Hello, I have some code that stops when trying to find a graph in a list of similar graphs:: (Pydb) list 110try: 111canonical = self.base[self.base.index(graph)] 112except ValueError: 113raise ValueError, \ 114 "Cannot find canonical representative for graph `%s`." \ 115 -> % (repr(graph),) 116 The list `self.base` contains "canonical" forms of the graphs and the `graph` object must compare equal to some item of the list, which indeed it does:: (Pydb) p graph == self.base[27] True (Pydb) p graph in self.base True However, I cannot directly get the index of the canonical graph (the number "27" above was found by manual inspection):: (Pydb) self.base.index(graph) *** ValueError: list.index(x): x not in list All graphs are instances of a `Graph` new-style class that implements comparison operators `__eq__` and `__ne__`, but no other rich-compare stuff. I'm using Python 2.5:: Python 2.5 (release25-maint, Dec 9 2006, 16:17:58) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)] on linux2 So my question is: what are the implementation differences between `x in list` and `list.index(x)` and why can one report that an item is in the list while the other cannot find its index? Should I add something to the `Graph` class so that `index` works? Thanks for any hint! -- Riccardo Murri, via Galeazzo Alessi 61, 00176 Roma -- http://mail.python.org/mailman/listinfo/python-list
Re: difference between `x in list` and `list.index(x)` for instances of a new-style class
[EMAIL PROTECTED] writes: > On 28 dic, 20:12, Riccardo Murri <[EMAIL PROTECTED]> wrote: > >> The list `self.base` contains "canonical" forms of the graphs and the >> `graph` object must compare equal to some item of the list, which >> indeed it does:: >> >> (Pydb) p graph == self.base[27] >> True >> >> (Pydb) p graph in self.base >> True >> >> However, I cannot directly get the index of the canonical graph (the >> number "27" above was found by manual inspection):: >> >> (Pydb) self.base.index(graph) >> *** ValueError: list.index(x): x not in list >> >> All graphs are instances of a `Graph` new-style class that implements >> comparison operators `__eq__` and `__ne__`, but no other rich-compare >> stuff. >> >> I'm using Python 2.5:: >> >> Python 2.5 (release25-maint, Dec 9 2006, 16:17:58) >> [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)] on linux2 >> >> So my question is: what are the implementation differences between `x >> in list` and `list.index(x)` and why can one report that an item is in >> the list while the other cannot find its index? Should I add >> something to the `Graph` class so that `index` works? > > (I've checked on 2.5.1 but I don't see any relevant differences with > the 2.5 version). Looking at the source for both methods, they only > use the __eq__ operator, but there is a slight difference: while one > evaluates list[i]==x, the other reverses the operands. If your __eq__ > is not reflexive, that could explain the difference. > That was indeed the reason: a bug in Graph.__eq__ broke reflexivity in certain cases. Thank you very much!! -- Riccardo Murri, via Galeazzo Alessi 61, 00176 Roma -- http://mail.python.org/mailman/listinfo/python-list
