Jay Tee [EMAIL PROTECTED] writes:
for j in jobs:
if (j.get('user') == 'jeff' and j.get('state')=='running') :
do_something()
Sounds like you need some backing data structures, like indexes
in a database, e.g. (untested, uses the cool new defaultdicts of 2.5):
index =
On Feb 20, 9:12 am, Paul Rubin http://[EMAIL PROTECTED] wrote:
do_something()
you'd just write:
for j in (index['user']['jeff'] index['state']['running']):
do_something()
Hi,
it looks very cool, except that one of the constraints mentioned is
that the solution has to
Jay Tee [EMAIL PROTECTED] writes:
it looks very cool, except that one of the constraints mentioned is
that the solution has to work properly on pythons 2.2 and 2.3.
That thing doesn't really deeply depend on defaultdict, it's just
convenient. You can add a few more lines of code in the
Hi
your post had the following construct:
for j in (index['user']['jeff'] index['state']['running']):
do_something()
but
Python 2.3.4 (#1, Oct 11 2006, 06:18:43)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2
Type help, copyright, credits or license for more information.
l1=
Jay Tee [EMAIL PROTECTED] writes:
l1= [3, 4, 7, 2]
l2 = [2, 3]
l2 = [2, 3, 99]
l1 l2
Traceback (most recent call last):
File stdin, line 1, in ?
TypeError: unsupported operand type(s) for : 'list' and 'list'
what am I missing?
They are sets, not lists.
from sets import Set as
On Feb 20, 6:44 pm, Paul Rubin http://[EMAIL PROTECTED] wrote:
They are sets, not lists.
from sets import Set as set # use in 2.3 and earlier
l1= set([3, 4, 7, 2])
l2 = set([2, 3])
l2 = set([2, 3, 99])
print l1 l2
Thanks Paul, but:
bosui:~ python
Python 2.2.3 (#1, Oct 26
Jay Tee [EMAIL PROTECTED] writes:
Python 2.2.3 (#1, Oct 26 2003, 11:49:53)
ImportError: No module named sets
Hmm, well I think the sets module in 2.3 is written in Python, so you
could drop it into your application for use in 2.2. Better would be
to use the C version from 2.4 if you can. Or
Hi,
thanks! the code lift from 2.3 to 2.2 worked (thank Guido et al for
BACKWARDS COMPATIBILITY ;-)) ... unfortunately I was in a hurry to get
the release out since a colleague's cluster was croaking under the
load of the old, non-indexed version. Your solution is nicer looking
than mine, and
Hi,
I have some code that does, essentially, the following:
- gather information on tens of thousands of items (in this case, jobs
running on a
compute cluster)
- store the information as a list (one per job) of Job items
(essentially wrapped
dictionaries mapping attribute names to
Jay Tee schrieb:
Hi,
I have some code that does, essentially, the following:
- gather information on tens of thousands of items (in this case, jobs
running on a
compute cluster)
- store the information as a list (one per job) of Job items
(essentially wrapped
dictionaries
Jay Tee wrote:
Hi,
I have some code that does, essentially, the following:
- gather information on tens of thousands of items (in this case, jobs
running on a
compute cluster)
- store the information as a list (one per job) of Job items
(essentially wrapped
dictionaries
On Feb 19, 11:07 am, Peter Otten [EMAIL PROTECTED] wrote:
Use a RDBMS (a database), they tend to be good at this kind of operations.
yeah, one of the options is metakit ... sqlite and buzhug both looked
promising but the constraint of pythons 2.2 and 2.3 ruled that out.
disadvantage of metakit
Jay Tee wrote:
On Feb 19, 11:07 am, Peter Otten [EMAIL PROTECTED] wrote:
Use a RDBMS (a database), they tend to be good at this kind of
operations.
yeah, one of the options is metakit ... sqlite and buzhug both looked
promising but the constraint of pythons 2.2 and 2.3 ruled that out.
Jay Tee [EMAIL PROTECTED] wrote:
Hi,
I have some code that does, essentially, the following:
- gather information on tens of thousands of items (in this case, jobs
running on a
compute cluster)
- store the information as a list (one per job) of Job items
(essentially wrapped
14 matches
Mail list logo
