magical expanding hash
I need a magical expanding hash with the following properties: * it creates all intermediate keys meh['foo']['bar] = 1 -- works even if meh['foo'] didn't exist before * allows pushing new elements to leaves which are arrays meh['foo']['list] << elem1 meh['foo']['list] << elem2 * allows incrementing numeric leaves meh['foo']['count'] += 7 * serializable I have such a class in ruby. Can python do that? -- http://mail.python.org/mailman/listinfo/python-list
Re: magical expanding hash
Nice. What about pushing to leaves which are arrays, or incrementing
leaves which are numbers? If the array leaf didn't exist, or a number
wasn't set yet, << must create an empty array and push the element from
the RHS into it, and += must init the leaf to 0 and add the RHS to it.
Here's the corresponding ruby:
# ruby!
class MagicalExpandingHash < Hash
def initialize(*params)
if params.first.is_a? MagicalExpandingHash
@parentObj, @parentKey = params[0..1]
params = params[2..-1]
end
super(*params) { |h,k|
h[k] = MagicalExpandingHash.new(self,k)
}
end
def <<(elem)
if @[EMAIL PROTECTED]
@[EMAIL PROTECTED] = [ elem ]
else
raise ArgumentError, "Can't push onto populated index", caller
end
end
def +(elem)
unless elem.is_a? Numeric
raise ArgumentError, "Can't add a non-Numeric value", caller
end
if @[EMAIL PROTECTED]
@[EMAIL PROTECTED] = elem
else
raise ArgumentError, "Can't add to populated index", caller
end
end
def to_hash
h = Hash.new
self.each_pair {|k,v| h[k]=(v.class==self.class)? v.to_hash : v }
return h
end
def from_hash(h)
h.each_pair {|k,v| self[k]=(v.is_a? Hash) ?
self.class.new.from_hash(v) : v}
end
def marshal_dump
self.to_hash
end
def marshal_load(h)
from_hash(h)
end
end
# examples
if $0 == __FILE__
meh = MagicalExpandingHash.new
meh['usa']['france'] << 'tocqueville'
meh['usa']['france'] << 'freedom fries'
meh['life']['meaning'] += 42
puts meh.inspect
# => {"usa"=>{"france"=>["tocqueville", "freedom fries"]},
"life"=>{"meaning"=>42}}
end
--
http://mail.python.org/mailman/listinfo/python-list
Re: magical expanding hash
Actually, the behavior is important to translate perl into ruby. Can it be implemented in python looking similarly? -- http://mail.python.org/mailman/listinfo/python-list
Re: magical expanding hash
Exactly, << as in C++/ruby streams. But notice the extra checks needed to see whether we want a new leaf which is an array or a number, or we create an intermediate hash level. Would the checks look the same in python? -- http://mail.python.org/mailman/listinfo/python-list
Re: magical expanding hash
The point of this exercise is to compare how either ruby or python can implement perl's default behavior when dealing with hashes. Since these are bread and butter of scripting, having a MEH class handy can enable fast semantically equivalent translation. This can be beneficial for demonstrating feasibility of migrating to python. Instead of debating philosophical justifications, I rather wonder what's the most appropriate pythonic way to solve the problem as stated. -- http://mail.python.org/mailman/listinfo/python-list
Re: magical expanding hash
Can assigning to hash without intermediate levels, possibly adding to a numeric leaf or adding an element to a leaf array, be python code? h['a']['b']['c'] += 42 If it can, I'd like to have a class which supports it. Is keeping a list at the leaf of a hash python code? h['a']['b']['c'].push(7) # or override push as an operator of your choosing Hashes with accumulating lists or counters at the leaves are universal data structures used in python as much as anywhere else. Python is used for scripting purposes at least as much as for some abstract ones. Having a useful data structure is handy. The multi-level hashes with default or accumulation come up naturally in text parsing. Designing a dedicated class structure may or may not be a better choice, depending on expediency. -- http://mail.python.org/mailman/listinfo/python-list
Re: magical expanding hash
Well, I know some python, but since there are powerful and magical features in it, I just wonder whether there're some which address this issue better than others. -- http://mail.python.org/mailman/listinfo/python-list
Re: magical expanding hash
Thanks, James! This is really helpful.
: It would take a lot of coding to make that << work right. Better is
the pythonic
:
: m[key] = [value]
:
: Its really only one more keystroke than
:
: m[key] << value
But it's only for the first element, right? I'd have to say
meh[key1]...[keyN].append(elem2) after that, while I want an operator
to look the same.
Also, what's the shortest python idiom for get_or_set in expression?
E.g., when creating a numeric leaf, I'd say
if meh.has_key('a'): meh['a'] += 7
else: meh['a'] = 7
-- but I'd have to do it everywhere! That's why I'd like to override
+= to do the check/init for me.
--
http://mail.python.org/mailman/listinfo/python-list
Re: magical expanding hash
Giovanni Bajo wrote, > dict.setdefault, as I already explained to you. I wonder about numerics too. Say we have a = None somewhere. I want to increment it, so I'd say a += 8. Now if this is a parsing app, the increment may happen everywhere -- so I'd write a function to do it if I worry about it being initialized before. Is there any operator/expression level support for what in ruby looks like a ||= 0 -- http://mail.python.org/mailman/listinfo/python-list
Syntax coloring in Python interpreter
Greetings -- as a long time user of both Python and Ruby interpreters, I got used to the latter's syntax-coloring gem, wirble, which colorizes Ruby syntax on the fly. Is there anything similar for Python? -- http://mail.python.org/mailman/listinfo/python-list
Showing native 8-bit strings in Python interpreter
I'm storing 8-bit characters from the 128-256 range in Python strings. They are Windows CP1251 Russian characters. When looking at those strings in the Python interpreter, they come up as codes inside the string. How can I teach Python to show those 8-bit characters in the native encoding of the terminal -- in the current locale -- where the interpreter was started? Cheers, Alexy -- http://mail.python.org/mailman/listinfo/python-list
optional arguments with compact reporting in optparse
Posted to the Optik list, but it seems defunct. Optik is now Python's
optparse.
I wonder how do you implement optional arguments to Optik. I.e., you
can have an option
-P [file]
-- the filename is optional, with a default "data,pikl". It works as
follows:
-- if no -P is given, no pickle is written
-- if -P is given without the filename following, a pickle file is
written with the default name data.pikl
-- if -P filename is given, the pickle is written to filename
How do we do optional values in Optik, with nargs <= 1?
Another question I have it how can I output a docstring right from the
parser.add_option() block? I prefer to define all option-related
things in the same block once. I'd like to output the help value from
the block, or append it to a report.
Here's example from my Ruby wrapper for Ruby's optparse:
name = :divisor
help = "show divisor"
short = "-m"
opt.on(short, "--#{name} [STR]", help) do |val|
hash[:show_divisor] = true
hash[:divisor] = val if val
end
report << [name,short,help]
-- notice that my report list is built with the exact values of all
options, regardless of whether they're encountered or not. The I
simply walk through the report list to print a report for this run:
report.each do |name,short,help|
val = opts.name || ""
STDERR.printf "--%s (%s)\t\%s\t%s\n", o, short, val, help
end if verbose
How can I group such reporting together with add_option in Optik?
Cheers,
Alexy
--
http://mail.python.org/mailman/listinfo/python-list
Re: optional arguments with compact reporting in optparse
Steve -- thanks for your pointer to argparse, awesome progress -- optional arguments. However, I still wonder how I do reporting. The idea is that there should be a list with tuples of the form: (short, long, value, help) -- for all options, regardless of whether they were specified on the command line or not. Moreover, a way to create such list should be incremental -- in ruby I define things around each option definition and add a new tuple to the reporting list right after the block defining the option. The idea is, -- help should report on all options with their actual or default values, and everything pertaining to one option -- its definition, callbacks, and adding it to the reporting list -- must be in vicinity of each other, so I don't forget to output some stuff about an option ten options below... The snippet I've shown pretty much does it in Ruby. Ah, yeah, and another thing -- I want to define a module with about 10 options common for a project. Then I'd import it in scripts, and there should be three things doable with the preexisting default options: -- turn off any of them -- supply new defaults to any of them -- add new options in the same way Wonder how brave pythonistas do that! Cheers, Alexy -- http://mail.python.org/mailman/listinfo/python-list
referencing a subhash for generalized ngram counting
Greetings: I wonder how does one uses single-name variables to refer
to nested sunhashes (subdictionaries). Here's an example:
In [41]: orig = { 'abra':{'foo':7, 'bar':9}, 'ca':{}, 'dabra':{'baz':
4} }
In [42]: orig
Out[42]: {'abra': {'bar': 9, 'foo': 7}, 'ca': {}, 'dabra': {'baz': 4}}
In [43]: h = orig['ca']
In [44]: h = { 'adanac':69 }
In [45]: h
Out[45]: {'adanac': 69}
In [46]: orig
Out[46]: {'abra': {'bar': 9, 'foo': 7}, 'ca': {}, 'dabra': {'baz': 4}}
I want to change orig['ca'], which is determined somewhere else in a
program's logic, where subhashes are referred to as h -- e.g., for x
in orig: ... . But assigning to h doesn't change orig.
The real-life motivation for this is n-gram counting. Say you want to
maintain a hash for bigrams. For each two subsequent words a, b in a
text, you do
bigram_count[a][b] += 1
-- notice you do want to have nested subhashes as it decreases memory
usage dramatically.
In order to generalize this to N-grammity, you want to do something
like,
h = bigram_count
# iterating over i, not word, to notice the last i
for i in range(len(ngram):
word = ngram[i]
if word not in h:
if i < N:
h[word] = {}
else:
h[word] = 0
h = h[word]
h += 1
-- doesn't work and is just a sketch; also, if at any level we get an
empty subhash, we can short-circuit vivify all remaining levels and
add 1 in the lowest, count, level.
Yet since names are not exactly references, something else is needed
for generalized ngram multi-level counting hash -- what?
Cheers,
Alexy
--
http://mail.python.org/mailman/listinfo/python-list
Re: referencing a subhash for generalized ngram counting
Here's a working version of the ngram counter with nested dict, wonder
how it can be improved!
lines = ["abra ca dabra",
"abra ca shvabra",
"abra movich roman",
"abra ca dabra",
"a bra cadadra"]
ngrams = [x.split() for x in lines]
N = 3
N1 = N-1
orig = {}
for ngram in ngrams:
h = orig
# iterating over i, not word, to notice the last i
for i in range(N):
word = ngram[i]
if word not in h:
if i < N1: # (*)
h[word] = {}
else:
h[word] = 0
if i < N1:
h = h[word]
print i, h
h[word] += 1
print orig
-- e.g., perhaps we could do short-circuit vivification to the end in
(*)?
Cheers,
Alexy
--
http://mail.python.org/mailman/listinfo/python-list
eof
I'd like to check, for a filehandle f, that EOF has been reached on
it. What's the way to do it? I don't want to try/except on EOF, I
want to check, after I read a line, that now we're in the EOF state.
In Ruby it's f.eof:
In Ruby:
>> f = File.open("jopa")
=> #
>> f.read()
=> "jopa\n"
>> f.eof
=> true
Is there a Python analog?
Cheers,
Alexy
--
http://mail.python.org/mailman/listinfo/python-list
the annoying, verbose self
Is there any trick to get rid of having to type the annoying, character-eating "self." prefix everywhere in a class? Sometimes I avoid OO just not to deal with its verbosity. In fact, I try to use Ruby anywhere speed is not crucial especially for @ prefix is better- looking than self. But things grow -- is there any metaprogramming tricks or whatnot we can throw on the self? Cheers, Alexy -- http://mail.python.org/mailman/listinfo/python-list
Re: eof
On Nov 22, 3:41 am, Wayne Brehaut <[EMAIL PROTECTED]> wrote:
> If you have PythonWin 2.5.1 (r251:54863, May 1 2007, 17:47:05) [MSC v.1310
> 32 bit (Intel)] on win32.for example, using Help, Index, eof gives:
>
> eof
> Token used to determine end of file. This will be set to the empty
> string (''), in non-POSIX mode, and to None in POSIX mode. New in
> version 2.3.
>
> If you don't use Active State Python--and even of you do--it helps to
> have these three "official" references handy:
> If the end of the file has been reached, f.read() will return an empty
> string ("").
>
> 3.9 File Objects
>
> There, and checking for "EOF" you'll note that both read( [size]) and
> readline( [size]) include:
>
> "An empty string is returned only when EOF is encountered
> immediately."
>
> HTH?
Nope! I don't want to buffer input myself, and don't want to store
look-ahead and push it back. f.read()/readline() is not a non-
destructive check, and thus won't do.
> >In Ruby it's f.eof:
>
> It also is not nice to talk Ruby here--nor Perl. Refer to C/C++ if
> necessary.
Well folks compare scripting languages all the time, and surely Ruby
is closer to Python than C++. Since Ruby can do f.eof, which is
easily found in its references, and Python can't, or its EOF can't
easily be found -- the one *equivalent* to a semantically clear
Ruby's, or Pascal's IIRC, f.eof -- something's missing here...
Why do I have to count sizes of lines read and compare it to some
filesize or do other weird tricks just to see, in a way not changing
my input stream, whether it's at the, well, EOF?
Cheers,
Alexy
--
http://mail.python.org/mailman/listinfo/python-list
Re: eof
On Nov 22, 10:37 am, Wayne Brehaut <[EMAIL PROTECTED]> wrote: > As others have already pointed out, "because it's seldom necessary in Python". You know what? I've read this many times, and it's a lot of self- congratulation. There's lot of things which can be useful in Python. This lack of EOF is inconvenient, there's nothing "Python way" about it, as a simple search on "EOF" or "eof" in this group demonstrates. Just a few threads: http://groups.google.com/group/comp.lang.python/browse_thread/thread/ed25388487b3ac7b Here folks fight the same problem in one way uglier than another. Iterators and whatnot are thrown at a poor li'l EOF: http://groups.google.com/group/comp.lang.python/browse_thread/thread/b09d612e99f67561 The recurrence of the question simply shows Python lacks an f.eof() method. That's all! Why do we may need it? The last thread shows clearly -- because the last line processing is often a special case. After I couldn't find the f.eof() in Python docs, I've quickly changed the logic to this (extracts): filesize = os.stat(filename)[6] cur_size = 0 def eof(): return cur_size == filesize def add_line(line): self.cur_size += len(line) ... if eof(): print >>sys.stderr, "* * * eof * * *" Basically, it allows me to write what I want, and it's natural to ask for eof() in this case -- and for a language to provide it. Ruby has all iterators-schmiterators you want and a kitchen sink, yet provides the said eof() without much fuss and 100 threads on c.l.*. :) > "Python is not Ruby." Both Python and Ruby happily agree here: >> "Python" == "Ruby" => false In [11]: "Python" == "Ruby" Out[11]: False There's nothing special about Python except indentation, which gets screwed up between editors all the time. (It's much easier to flip- flop between TextMate and Emacs with Ruby than with Python, without setting your tabs and spaces pedantically.) It's faster than Ruby, otherwise they're similar. When Ruby X.Y gets faster, it'll be a tough call to between 'em. I use Python to accomplish things I know how, with algorithms which work and proven control logic, so this is reasonable to ask about certain control flow equivalents. And comparisons will always be good. :) Cheers, Alexy -- http://mail.python.org/mailman/listinfo/python-list
Re: eof
On Nov 22, 5:08 am, I V <[EMAIL PROTECTED]> wrote: > On Wed, 21 Nov 2007 17:06:15 -0800, braver wrote: > It looks like ruby internally buffers the stream itself, which is how > come it can support this. According to the docs: > > "Note that IO#eof? reads data to a input buffer." > > http://www.ruby-doc.org/core/classes/IO.html#M002309 > > I'd imagine that's inefficient in a lot of cases; and I don't think it > provides much benefit. What's the hardship in checking the return values > of your IO calls? Or iterating over the file, which is a more elegant > solution in many cases. Exactly. But in many cases, built-in look-ahead is convenient. The threads I cite in reply to Wayne are essentially trying to reimplement the look-ahead with iterators -- and boy, it doesn't look pretty. In many cases, you want to do this: for line in f: if line % 1000 == 0 or f.eof(): # eof() doesn't exist in Python yet! My control logic summarizes every 1000 lines of a file. I have to issue the summary after each 1000 lines, or whatever incomplete tail chunk remains. If I do it after the for loop, I have to refactor my logic into a procedure to call it twice. Now I want to avoid the overhead of the procedure call, and generally for a script to keep it simple. (Well I guess f.eof() is an overhead itself if it's inefficiently done in Python due to Python's impleentation of IO -- see below.) Having eof() in this case is natural, and there's no legitimate reason for Python not to provide it -- except if its IO is implemented so that it's hard to provide such an eof()! So in that case, instead of ideological arguments about ways Python and not Python, it's interesting to look at why Python implements its IO so that giving eof() is hard, while Ruby gladly and cheerfully does it! Cheers, Alexy -- http://mail.python.org/mailman/listinfo/python-list
Re: eof
On Nov 22, 3:26 pm, Duncan Booth <[EMAIL PROTECTED]> wrote: > This sounds like a case for writing a generator. Try this one: [...] Thanks, Duncan! Really cool & useful. And yield is the Ruby way, too! (Wayne -- :P). Cheers, Alexy -- http://mail.python.org/mailman/listinfo/python-list
Re: the annoying, verbose self
On Nov 22, 4:34 pm, Kay Schluehr <[EMAIL PROTECTED]> wrote: > On 22 Nov., 00:51, braver <[EMAIL PROTECTED]> wrote: > > But things grow -- is there any metaprogramming tricks or whatnot we > > can throw on the self? > > http://docs.python.org/lib/compiler.html Indeed. Well, my current solution is to bow to the collective wisdom and retain the self, but type it with just one symbol .-> ... in TextMate, with the Python bundle! (If only TextMate Python bundle woulldn't indent everything it pastes And that's how Ruby helps Python -- at the code's very inception TextMate!) Cheers, Alexy -- http://mail.python.org/mailman/listinfo/python-list
Re: eof
On Nov 22, 5:32 pm, Neil Cerutti <[EMAIL PROTECTED]> wrote: > > There's nothing special about Python except indentation, which > > gets screwed up between editors all the time. (It's much > > easier to flip- flop between TextMate and Emacs with Ruby than > > with Python, without setting your tabs and spaces > > pedantically.) > > That horse is dead, buried, decayed, and there's a fig tree > growing out of the gravesight. Have a fig. (Well, TextMate is pretty new, and I've just got a brand new Carbon Emacs-devel from ports. And tabs don't match in a Python bundle and the Python mode. Have to fix'em tabs. Chews a fig, mumbles to himself... :) > Language comparisons are sometimes good. They are best when > they are free of FUD. So why Python's IO cannot yield f.eof() as easily as Ruby's can? :) -- http://mail.python.org/mailman/listinfo/python-list
Re: eof
On Nov 22, 6:08 pm, "J. Clifford Dyer" <[EMAIL PROTECTED]> wrote: > > So why Python's IO cannot yield f.eof() as easily as Ruby's can? :) > Because that's not how you compare languages. You compare languages by > stating what you are actually trying to do, and figuring out the most natural > solution in each language. Not "I can do this in x--how come I can't do it > in y?" Python doesn't have f.eof() because it doesn't compare to Ruby? Or because I'm trying to compare them? :) That's giving up to Ruby too early! Ruby has iterators and generators too, but it also has my good ol' f.eof(). I challenge the assumption here of some majectically Python- wayist spirit forbidding Python to have f.eof(), while Ruby, which has all the same features, has it. Saying "it's not the Python way" is not a valid argument. The suspicion lurking in the thread above was that that has to do with Python IO buffering, that it somehow can't tell the f.eof() with automatic look-ahead/push-back/simulate read, as transparently an effectively as (in practice) Ruby does without much fuss. The reason why such a useful feature -- useful not in Ruby or Perl or Pascal, but algorithmically -- is not present in Python is a recurrent mystery, evidenced in this group recurrently. Cheers, Alexy -- http://mail.python.org/mailman/listinfo/python-list
Re: eof
On Nov 22, 6:10 pm, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > Granted, they aren't part of the stdlib - but then, lots > of things aren't. As Hendrik noticed, I can't even add my own f.eof() if I want to have buffering -- is that right? The tradeoff between speed and convenience is something I'd rather determine and enable myself, if I have the right tools. Cheers, Alexy -- http://mail.python.org/mailman/listinfo/python-list
Re: eof
On Nov 22, 6:40 pm, "J. Clifford Dyer" <[EMAIL PROTECTED]> wrote: > You yourself said that performance is a complaint of yours regarding Ruby, so > why claim that Ruby's way is clearly better in a case where it causes a known > performance hit? See Hrvoje's remark above -- we can have EOF and eat it too! Perhaps it was just somehow omitted from the standard Python library because it disliked by some folks or just forgotten. Is there a history of the eof()'s fall from grace? Was it ever considered for inclusion? Cheers, Alexy -- http://mail.python.org/mailman/listinfo/python-list
Re: the annoying, verbose self
On Nov 23, 1:15 am, Paul Boddie <[EMAIL PROTECTED]> wrote: One wonders whether the people complaining so vehemently > about self have ever encountered coding style guides. Dude, I'm also programming in Ada, 83 to 95 to 2005. Beautiful language, a living style guide. I love typing names dozens of charactares long -- in Ada. Ada has scope control, separate compilation, renames, overloading, types, etc... However, in scripting languages, it's not cool, and I'd just love to see self hide for a bit of a change -- it's a nuisance after Ruby, 's all. Nothing eternal or worth assembling a NASA panel or Python foundation meeting, just a li'l respite to make a tiny script more lucid, OK? Peace, Alexy -- http://mail.python.org/mailman/listinfo/python-list
Re: eof
On Nov 22, 8:04 pm, Neil Cerutti <[EMAIL PROTECTED]> wrote: > I think Python is well rid of such a seldomly useful source of > confusion. So all that code folks wrote in Algol-like languages, -- e.g. this works in Ada, -- while not End_of_File(f) loop -- end if; -- are confusing? Why not interpret it as reading until ^D on a pipe? And plain files work fine. (What would Ruby do?:) Historically, is it possible to trace the eof-related design decision in stdlib? Most languages have the look-ahead eof, so when Python was codified, there should gave been some decisions made. Can we say that f.eof() in fact can check for EOF right after we've read all characters from a file, but before a failed attempt to read beyond? In Python's idiom, for line lin file: # look at a line # we can tell eof occurs right here after the last line After the last line, we've read all bytes but didn't try a new line yet -- is it the semantics of the for line in file:? I assume it'll do the right thing if our file ends in \n. What if the last line is not \n-terminated? Cheers, Alexy -- http://mail.python.org/mailman/listinfo/python-list
Re: the annoying, verbose self
On Nov 24, 2:38 am, "BJörn Lindqvist" <[EMAIL PROTECTED]> wrote:
> The big deal is that "self." occupies important horizontal screen real
> estate. That is, it is usually not self in itself that is problematic,
Exactly. I understand and appreciate all the scoping qualification
and explicit"ation" needs, but I still want my code to look good and
uncluttered after all is said and done. Using indentation saves us
from all those end's or {}, no less annoying than self, -- then the
self comes along and defeats the purpose of conciseness.
> but the overflowing lines is. Take this silly vector class for
> > suppose that the syntax were
> > expanded so that, in a method, a dot
> > ".", as a precursor to an identifier,
> > was treated as "self." is currently treated?
>
> I like that a lot. This saves 12 characters for the original example
> and removes the need to wrap it.
>
> 7return math.sqrt(.x * .x + .y * .y + .z * .z)
>
> +1 Readability counts, even on small screens.
Hear, hear! Dear G-ds of Python, pls give us a --dotself option!
Cheers,
Alexy
--
http://mail.python.org/mailman/listinfo/python-list
with statement for two files
Can open two files in a with statement: with open(src) as readin, open(dst,"w") as writin: # WRONG: comma doesn't work ... -- so that you have transactional safety for two file descriptors? The comma syntax doesn't work, but is there a way, except for with open(src) as readin: with open(dst,"w) as writin: ... Cheers, Alexy -- http://mail.python.org/mailman/listinfo/python-list
sampling without replacement
Greetings -- I am doing a sampling without replacement, taking out random elements from an array. The picked element is then removed from the array. When my arrays were on the order of 10,000 elements long, everything was fast. But when I increased them to 1,000,000 it suddenly was hours. I tracked it down to the line I first threw in to cut out the element i: a = a[:i] + a[i+1:] It was indeed the weakest link. But when I replace it with e.g. a.pop(i) it is still slow. I wonder what approach can be taken to speed it up? Basically, the algorithm picks an element from the array at random and checks its size in a different hashtable i=>size. If the size fits into an existing accumulator, i.e. is below a threshold, we take it and delete it from the array as above. Thus just random.sample is not enough as we may not use an element we pick until we find the right one, element by element, running a cumulative statistics. Using an array is natural here as it represents "without replacement" -- we take an element by removing it from the array. But in Python it's very slow... What approaches are there to implement a shrinking array with random deletions with the magnitude of millions of elements? Cheers, Alexy -- http://mail.python.org/mailman/listinfo/python-list
