got rid of problematic function

[rheophile10]

resolves #528

and passes tests.

[rheophile10]

also resovles #488

[rheophile10]

note that the google trends library in node js doesn't support functions beyond what the api directly supports.

I think this is wise

[emlazzarin]

@Terseus what do you think of this?

[Terseus]

I'm going to admit, after reading the issue discussion and the method code I see it is... really, really bad; returns incorrect results basically always as @rheophile10 explained in the issue, in case of an error it just prints the error and call it a day, the way it concatenates the pd.DataFrame have terrible performance... there's absolutely no reason for it to exists here.

On the other hand, completely removing already existing functionality without even a warning will only serve to angry our users and deal with issues about why it was removed.

I think the best would be, instead of fully remove it, replace the whole method code with a raise NotImplementedError explaining that the method returned incorrect results and it will be completely removed in v5.x, advising users to implement themselves if they want.

Anyhow, I also think we must revisit this feature in the future because it's really good to have it.
@rheophile10 You're right, it would be easier if we limit ourselves to the API calls of the backend but the feature is so good and makes so much sense it's a shame to not have it.

[emlazzarin]

I added a stub function with a NotImplementedError. Does that work for you @rheophile10?

[rheophile10]

Yeah I think probably it probably makes sense to show in an article/tutorial how we could use the rest of pytrends to implement something similar to a function like this or to demonstrate how pytrends could be used to warehouse data with some Google Cloud Functions in like Google BigQuery or something but I don't think we want to support a function that is basically pytrends.create_data_warehouse_for_me_with_enough_api_calls_to_get_my_ip_address_blacklisted_by_google

[jmz1996]

I'm going to admit, after reading the issue discussion and the method code I see it is... really, really bad; returns incorrect results basically always as @rheophile10 explained in the issue, in case of an error it just prints the error and call it a day, the way it concatenates the pd.DataFrame have terrible performance... there's absolutely no reason for it to exists here.

On the other hand, completely removing already existing functionality without even a warning will only serve to angry our users and deal with issues about why it was removed.

I think the best would be, instead of fully remove it, replace the whole method code with a raise NotImplementedError explaining that the method returned incorrect results and it will be completely removed in v5.x, advising users to implement themselves if they want.

Anyhow, I also think we must revisit this feature in the future because it's really good to have it. @rheophile10 You're right, it would be easier if we limit ourselves to the API calls of the backend but the feature is so good and makes so much sense it's a shame to not have it.

Can this problem be solved? Or is this method considered to be permanently removed?

[rheophile10]

it can be solved. I'll show you an example this week

[rheophile10]

I don't think it should be supported as part of the core functionality though but thats just my personal opinion

[jamesmarchetti]

Hi @rheophile10, I see the hourly feature was removed and see your note on how it can be solved. I'm needing to build a history of data on specific stocks, from stock exchanges in various countries for a some academic research. Ideally, this would go back years, but I think we could get blocked pretty easily.
I was wondering if you could assist in how we could optimism the requests to return as much hourly data as possible?
An example of the stocks could be:
[('SVW.AX', 'Seven Group Holdings Ltd'), ('HCH.AX', 'Hot Chili Ltd'), ('MYE.AX', 'Metarock Group Ltd'), ('VKA.AX', 'Viking Mines Ltd'), ('WAF.AX', 'West African Resources Ltd'), ('CAY.AX', 'Canyon Resources Ltd'), ('ASN.AX', 'Anson Resources Ltd'), ('TER.AX', 'Terracom Ltd'), ('TLG.AX', 'Talga Group Ltd'), ('RAS.AX', 'Ragusa Minerals Ltd'), ('HOR.AX', 'Horseshoe Metals Ltd'), ('ODM.AX', 'Odin Metals Ltd'), ('IFT.AX', 'Infratil Ltd'), ('LRS.AX', 'Latin Resources Ltd'), ...]
For which we would search in the AU, region.
Regads

[rheophile10]

I never did get around to writing that blog entry - pretty busy. I guess I'll put up a repo for this and show how I'd do it.

[jamesmarchetti]

That’s great, looking forward to seeing it. Thanks so much

On Mon, 6 Mar 2023 at 12:53 am, rheophile10 ***@***.***> wrote: I never did get around to writing that blog entry - pretty busy. I guess I'll put up a repo for this and show how I'd do it. — Reply to this email directly, view it on GitHub <#542 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACDQQXYNHCW2EKFT5ZRMLODW2SLA3ANCNFSM6AAAAAARTINKNA> . You are receiving this because you commented.Message ID: ***@***.***>

-- Regards, James Marchetti 0422 213 890

[techblogger5]

Dear Pytrends Contributors,

I hope you are doing well. I am writing to let you know about my concerns regarding the current state of Pytrends. Recently, I have been experiencing issues with the software while trying to gather data using different IP addresses, software, and proxies. Unfortunately, I received the error message "The request failed: Google returned a response with code 429."

I understand that Pytrends relies heavily on Google's API to collect data, and I appreciate the effort put in by the development team to make this possible. However, Pytrends needs an update to resolve this issue.

I want the development team to take a closer look at this issue and provide a solution as soon as possible. As a member of this community, I rely on Pytrends for my professional work, and such errors affect my productivity and workflow.

I would also like to encourage other community members to share their experiences with Pytrends and any issues they might have faced while using the software. It would be helpful to collaborate and come up with solutions together.

Thank you for your attention, and I look forward to hearing from the development team soon.

[Terseus]

Hi @techblogger5

This library provides a Python interface to consume the Google Trends unofficial API, we doesn't have any control about how the API behaves.

Taken from the README:

Rate Limit is not publicly known, let me know if you have a consistent estimate

• One user reports that 1,400 sequential requests of a 4 hours timeframe got them to the limit. (Replicated on 2 networks)
• It has been tested, and 60 seconds of sleep between requests (successful or not) appears to be the correct amount once you reach the limit.

You have to manage the errors yourself and retry the requests as needed.

Cheers.

[simonlim334]

Hi @rheophile10

Did you by any chance manage to repo a workaround to get_historical_interest?

Thanks!

[RiegelGestr]

Hi @rheophile10

Did you by any chance manage to repo a workaround to get_historical_interest?

Thanks!

Following.

[kmousaa]

Hello, I am using pytrends to get hourly trends data using your API, but I get this message.

"""
This method has been removed for incorrectness. It will be removed completely in v5.
If you'd like similar functionality, please try implementing it yourself and consider submitting a pull request to add it to pytrends.

There is discussion at:
#542
"""

Has there been any fixes for this yet? Is there any alternative methods to get the hourly trends? I understand that the team does not have control on how google works, but please let me know if there is something I can do? I looked at this discussion, and from I understood, your Houry features was removed?

I appreciate any help I can get!