First of, its my first time writing anything on GitHub, sorry if I don't make sense, you can just give a dislike and i'll remove the issue, just hoping to help.

I think a small txt or json file could be generated for the first run of grabbing all video IDs and then cache it in order to skip the next page token thing that happens when you request for video IDs. And in order to check if a new video is uploaded you can just check against the top ID of cached file vs first returned ID from API. (assuming video ID is static)

I am really sorry if i got the whole process wrong, if it's a real issue, i'll go read up the all the youtube API docs and excitedly contribute a solution, I did not go through it as of posting the issue as I am studying for my exams. Thanks,

OT.

I really like your idea and execution, so wanted to share your GH Repo with other people but found that it lacks README so I wrote one.

I won't mind if you don't merge this PR, just wanna tell you to create a README file :)

btw, I too dislike what YT did.

I was using the script on my channel's videos, and there was a video causing the ZeroDivisionError, so upon looking at the details for the video, I found that it had no likes and dislikes, and so, it was getting the error, and causing a Traceback. This can be prevented by writing a testcase that checks such a thing.

https://github.com/Anarios/return-youtube-dislike

The comments in their README detail why you shouldn't put any more effort into this; it's practice, it's something to show your viewers, but Youtube's working against you man. I was about to write a JS userscript which would revert the old behavior of the dislike button in-browser, and comment a link to it in your video, but I was lucky to find that project before I got too deep.

While reading your code, and reflecting on the hate-bombing that Youtube is trying to combat for good reason, I came up with an idea. Why not force users to watch like 5-10 videos from a specific channel all the way through, before being allowed to create a review of that channel or piece of content? This would probably require an overhaul of youtube's existing rating infrastructure to something like the five star system, but my thought is that it could help humanize targets of hate-bombing, while also ensuring that people are actually exposed to content before leaving bogus ratings.

IDK, lmk what you think. I'm not a YT creator or anything so I have literally no way to suggest this idea @youtube for consideration. Good review systems serve a utility to viewers, what Youtube is doing now isn't doing anything to really help the problem at hand.

Issue

Having all the logic bundled within a single main method is difficult to understand and test, so I broke up the code as much as I could in a way that could address both these problems.

Changes

• Code hygiene:
  • Added wrapper class (YoutubeClientAdapter) to interface functions from the youtube api client and implement helper methods for the main method
    • If this approach is accepted, we can mock the api client using mockito and start writing YoutubeClientAdapter tests
  • Added placeholders (views, likes, etc..) to the statistics comment (stat_comment) to simplify generating new comment strings using the String.format method (perhaps we should think about localizing this string in the future?)
• Other improvements:
  • Get video statistics in one batch fetch in YoutubeClientAdapter#get_channel_videos rather than invoking a fetch operation for each video
  • Set ratio to 0 in main method if there are 0 likes to avoid division by 0 error
  • Added new requirement API_KEY for the .env file
    • Note: I was not able to get a successful response from the comment insert/update api operations without this
  • Added __pycache__, .vscode to .gitignore

This is a task that can be elaborated on in the future, but when other Youtubers start using this tool, we may want to have a strategy to ensure the number of likes and dislikes cannot be fudged by the user. This is so that we don't have people abusing and ruining this tool.

Since about 2015 apparently, Python has had this concept of "f" strings, whereby you don't have to concatinate expression results/values manually between string elements. If you include a "list" of strings on newlines between ( )'s without commas, apparently they'll become auto concatinated.

This will not be worked on because each individual's search terms will be different. I only created this issue to inform everyone of this bug. However, once I have more information on how to avoid this, I'll draw out some guidelines.

• Converted camelCase to snake_case, since that's the recommended naming convention for Python.
• Removed redundant float casts on L64 (since / in Python always returns a float and doesn't need casting like Java)
• Refactored text_original to look a bit cleaner