>In article <CVALE.95Apr17161219@netcom20.netcom.com> cvale@netcom20.netcom.com (Chris Vale) writes:
> Dan> e.g, also. Try something like:
> Dan> a = {} for i in [0..1000]: a['indx' + `i`] = 'value' +
> Dan> `i`
> Dan> and watch the heap grow!)
> Hmm, don't you mean something like
> a = {}
> for i in range(0,1000):
> a['indx'+str(i)] = 'value'+str(i)
> ?
> this seems to take less than a second to generate, and less than 15k
> of heap ( 486DX2 66mz running windows/NT 3.5). So what is the problem?
> I think you need to learn a little about the language since your code
> isn't correct anyway. The problem is you seem to be assuming something
> based on your understanding of the underlying architecture rather than
> from practial experience. Try it, you might actually like it.
>No... this was from real experience. It has been a little while, so
>I'm a little rusty. But we were building a CD-ROM index of the web:
>50,000 documents. Just keeping a list of URLs that big made the python
>heap exhaust virtual memory. We were forced to switch to perl.
>I looked at the source to the runtime, and it does 2 mallocs per
>string object: one for the header, and one for the char array.
>Considering that strings are immutable, there's an obvious optimization
>that's not being exploited (or wasn't in 1.0.3 or 1.1 or so.)
Just because a particular implementation of a language has problems (and this
is an implementation issue (btw, several nasty memory leaks were fixed in
v1.2) and not a language design issue) doesn't mean that the language is
without merit. When the Python implementation has gone through as many
iterations as the Perl implementation, it may be as fast and memory efficient
as Perl is.
It's almost like people were rejecting C because GCC had a few bugs...
Personally, I like Python because it feels designed, not accumulated.
-- Jeffrey C. Ollie Iowa Network Services System Administrator