Optimizations and readability improvements

[LazaroHurtado]

This PR introduces several small optimizations and changes as described below:

• added some helper methods to llm_needle_haystack_tester to increase readability
• switched from asyncio.gather(*tasks) to using async with asyncio.TaskGroup() as tg as suggested here
• small optimizations when it comes to determining if a result exists, find the most recent '.' token from an insertion point, and loading context files

This PR also targets this issue: #20

cc: @pavelkraleu , @kedarchandrayan
sorry for the tag but I can't assign reviewers so just trying to increase visibility :)

[LazaroHurtado]

We know the exact format of the filename, so instead of looping over every file lets see if the specific file exists, if it does then check the version number else return false.

[kedarchandrayan]

Hi @LazaroHurtado, We'll address the points here separately and raise individual issues for each relevant one. We'll send these issues to you, allowing you to select the changes and create separate pull requests (PRs) accordingly. This approach ensures that each PR serves a single purpose.

[LazaroHurtado]

@kedarchandrayan I have created issues and broken this PR up. This PR now only includes work for optimizations and readability (readability doesn't deserve an issue ticket)

[kedarchandrayan]

@LazaroHurtado , I said we will raise the issues and let you know 😄

I like the enthusiasm but I am strongly opposed to suggesting opinionated changes. Every dev will have their own opinion and if we allow such changes, they will keep coming endlessly. For example, there is not much difference between following versions of code:

Version 1:

context += f.read()

Version 2:

file_content = f.read()

context += file_content

I would suggest that you go through your proposed changes again and remove such proposals. Let the changes be ones which add definite value. Please let me know if you agree with the point.

[LazaroHurtado]

@LazaroHurtado , I said we will raise the issues and let you know 😄

I like the enthusiasm but I am strongly opposed to suggesting opinionated changes. Every dev will have their own opinion and if we allow such changes, they will keep coming endlessly. For example, there is not much difference between following versions of code:

Version 1:

context += f.read()

Version 2:

file_content = f.read()

context += file_content

I would suggest that you go through your proposed changes again and remove such proposals. Let the changes be ones which add definite value. Please let me know if you agree with the point.

Issues are normally opened by users of the open source project so that didnt seem too far fetched. Some changes in this PR do include readability improves which is subjective but im always open to discuss them and the value they bring. Most changes include optimizations for speed or updating how a library is used to follow the recommended docs, both provide definite and measurable value. For the example you pointed out, file_content was used to not have to call f.read() twice. I understand somethings might come as opinionated but code cleanliness and removing code smells must be taken into account to obtain a code base that is maintainable in the long run

[kedarchandrayan]

Sure @LazaroHurtado! I never meant that all the changes are opinionated. I am sorry if my comment meant that in anyways.

And I am also 100% up for code cleanliness.

Also, I missed the way you have used file_content. I will go through the PR in detail again.

[kedarchandrayan]

Hi @LazaroHurtado, a big change was made today (#33) that has made this pull request outdated. I apologize for the inconvenience. If it is easier, please feel free to open a new pull request with the changes using the latest code.

[LazaroHurtado]

Hi @LazaroHurtado, a big change was made today (#33) that has made this pull request outdated. I apologize for the inconvenience. If it is easier, please feel free to open a new pull request with the changes using the latest code.

No worries, I have update this PR to have no conflicts with the recent changes. Awesome work on #33 btw!