[Tutor] Fwd: Testing a string to see if it contains a substring

[Danny Yoo]

---------- Forwarded message ----------
From: dw <bw_dw at fastmail.fm>
Date: Thu, Jan 22, 2015 at 7:49 AM
Subject: Re: [Tutor] Testing a string to see if it contains a substring
To: Danny Yoo <dyoo at hashcollision.org>


Hi Danny.
Thanks for your email.
The number of elements could start out as up to 500.
But since they are short string elements, even that amount won't be a
problem for in-ram memory.
The eventual module is designed to ensure that the max elements count
will be kept at 53.
I'm playing with a module that will remove files that are created as
archives weekly.
Right now we have about 3 years and they are starting to eat up
hard-drive.
So I'm playing with a module that will remove the oldest files based on
their creation date.
And keep the max count of them to 52....(1 years worth of archives)

Thanks for the additional explanation of the search() returning a match
or None.

Many thanks my friend!!
Duane



On Wed, Jan 21, 2015, at 05:13 PM, Danny Yoo wrote:
> How large will your array be in production?
>
> If it going to be very large, you may want to consider a database.
> You're simulating a collection of records as an in-memory sequence of
> flat strings.  This design won't scale, so if you are working with a
> lot of data, you may want to look into a dedicated database.
>
>
>
> > This method works really well when the regex date characters are found.
> > It returns the value 0 to misc_int1 because the date regex starts at 0
> > position.
> > I was hoping the .start() method would return a -1 value for the
> > instance in which the regex search string is not found.
> > That way I could iterate through the elements and retain only the valid
> > ones.
>
> With regards to your original question: the return type of a search()
> is either a match object, or a None.  So your program's control-flow
> logic should be accounting for these two possibilities.  At the
> moment, the code assumes that it always gets a match object, but that
> assumption doesn't hold and explains why you're seeing run-time error
> messages.
--
 Bw_dw at fastmail.net