Tony Nelson wrote:
> >Can I get over this performance problem without reimplementing the
> >whole thing using a barebones list object? I though I was being "smart"
> >by avoiding editing the long list, but then it struck me that I am
> >creating a second object of the same size when I put the modi
Thank you all for your great help. One of the few things better than
python is the knowledgeable community around it. : )
Regards,
Mack
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
"MackS" <[EMAIL PROTECTED]> wrote:
> Hello everyone
>
> I am faced with the following problem. For the first time I've asked
> myself "might this actually be easier to code in C rather than in
> python?", and I am not looking at device drivers. : )
>
> This progr
On 13 Nov 2005 22:57:50 -0800, "MackS" <[EMAIL PROTECTED]> wrote:
>Hello everyone
>
>I am faced with the following problem. For the first time I've asked
>myself "might this actually be easier to code in C rather than in
>python?", and I am not looking at device drivers. : )
>
>This program is mea
Replying to myself... the first sign of madness *wink*
Steven D'Aprano wrote:
> size = 1024*1024*20 # 20 MB
> original = "A" * size
> copy = [None] * size
> for i in range(size):
> copy[i] = original[i].lower()
> copy = ''.join(copy)
Do you notice the premature optimization? Rather than
MackS wrote:
> This program is meant to process relatively long strings (10-20 MB) by
> selectively modifying small chunks one at a time.
...
> Can I get over this performance problem without reimplementing the
> whole thing using a barebones list object?
Is that a problem? Are you using stri
Hello everyone
I am faced with the following problem. For the first time I've asked
myself "might this actually be easier to code in C rather than in
python?", and I am not looking at device drivers. : )
This program is meant to process relatively long strings (10-20 MB) by
selectively modifying
