I made a terminal based weather application with python. What do you think about the code, is it good enough? I mean is it professional enough and how can I make the same functions with more less code?

Here's the main file (I also added it as url to post): https://raw.githubusercontent.com/TheCitizenOne/openweather/refs/heads/main/openweather.py
Here's the config.json file: https://raw.githubusercontent.com/TheCitizenOne/openweather/refs/heads/main/config.json

top 20 comments

sorted by: hot top controversial new old

[–] solrize@lemmy.world 9 points 2 days ago (1 children)

It's mostly ok, my immediate reaction is that it's unnecessary to put the whole program into a class. Python isn't Java. It's fine to write procedures at the top level.

Also as someone said, consider using enums, and also the new case statement as of Python 3.10. Type annotations also can make things clearer. I've been using mypy to check mine but there are some alternatives now that might be better.

There is not much error checking but that can be ok if you are the only user.

If the config file might be crafted maliciously, it can use escape codes for a terminal playback attack: https://www.cyberark.com/resources/threat-research-blog/dont-trust-this-title-abusing-terminal-emulators-with-ansi-escape-characters

Be careful of that.

[–] the_citizen@lemmy.world 1 points 2 days ago (1 children)

Yes I realized that I put everything to two classes. It's too much. I'll make more classes for more attributes.

I didn't know enums until now and it's awesome. I will do some exercises about it.

Last thing is interesting. I need to read that. Thank you for suggestions.

[–] solrize@lemmy.world 2 points 2 days ago

There's no need to make more classes. You can move some of the code so it's not in any class.

[–] KindaABigDyl@programming.dev 11 points 3 days ago (2 children)

You appear to be afraid of spaces. Everything is cramped together.

Just bc you don't have to put a space after colons or after equals and commas and whatnot doesn't mean you shouldn't

Don't be afraid of spaces.

They make it easier for you to read your code when you come back later

[–] the_citizen@lemmy.world 3 points 3 days ago (2 children)

Oops, sorry. I will revise the code and place spaces. Thanks for suggestion <3

[–] taaz@biglemmowski.win 6 points 3 days ago* (last edited 3 days ago) (1 children)

Usually, you would use a formatter anyway - it's good to know the standard way but for day to day coding I just have a shortcut bound that runs ruff format (you can even have it done automatically on file save).

[–] the_citizen@lemmy.world 1 points 2 days ago (1 children)

I need to search formatters. Thank you for suggestion.

[–] beeng@discuss.tchncs.de 0 points 2 days ago

Ruff

[–] Derp@lemmy.ml 5 points 2 days ago (1 children)

Not the original commenter, but no need to apologise my friend. Nice work. Learning tip from me: give PEP 8 a read and save it for reference somewhere. It's the standard for how to format Python code, and future you will thank you for internalising it early on in your Python journey

[–] the_citizen@lemmy.world 1 points 2 days ago

Thank you I will read it.

[–] the_citizen@lemmy.world 1 points 2 days ago (1 children)

I revised the code. Added some spaces and comments for better readability. Hope it's better now.

[–] FizzyOrange@programming.dev 2 points 2 days ago

Instead you should just use an autoformatter. Black is good. Ruff is probably good too but I don't have a lot of experience with it. YAPF is not good; don't use it.

[–] cypherpunks@lemmy.ml 7 points 2 days ago (1 children)

I started to python one and half week ago. So I’m still beginner.

Nice work! Here are a few notes:

The WeatherApp object has a mix of attributes with long-term (eg self.LOCATIONS) and short-term (eg self.city) relevance. Instance attributes introduced in places other than __init__, which makes it non-trivial for a reader to quickly understand what the object contains. And, actually, self.{city,lat,lon} are all only used from the add_city method so they could/should be local variables instead of instance attributes (just remove the self. from them).

There seem to maybe be some bugs around when things are lowercase and when not; for example checking if self.city.lower() in self.LOCATIONS but then when writing there the non-lower self.ctiy is used as the key to self.LOCATIONS.

The code under if rep == "1" and elif rep == "2" is mostly duplicated, and there is no else branch to cover if rep is something other than 1 or 2.

It looks like the config only persists favorites so far (and not non-favorite cities which the user can add) which isn't obvious from the user interface.

Passing both location and locations into WeatherAPI so that it can look up locations[location] is unnecessary; it would be clearer to pass in the dict for the specific location. It would also be possible to avoid the need for LOWLOCATIONS by adding a non-lowercase name key to the per-location dictionaries that just have lat and lon right now, and then keeping LOCATIONS keyed by the lowercase names.

HTH! happy hacking :)

[–] the_citizen@lemmy.world 2 points 2 days ago

That's very informative, I will rewrite the code with your suggestions. Thank you!

[–] FizzyOrange@programming.dev 1 points 2 days ago

Pretty good for a week and a half! I would recommend setting up a project using uv and also adding type hints and check them with Pyright (NOT Mypy).

[–] Arkouda@lemmy.ca 1 points 2 days ago (1 children)

I am pretty new myself, but if you didn't know, here are some great free resources to help you.

https://inventwithpython.com/

[–] the_citizen@lemmy.world 2 points 2 days ago (1 children)

These are looking awesome. Thank you for sharing this <3

[–] Arkouda@lemmy.ca 2 points 2 days ago

No problem at all! I hope it helps :)

[–] Endmaker@ani.social 1 points 3 days ago* (last edited 3 days ago) (1 children)

Too lazy to check the logic but if possible, consider using enums.

[–] the_citizen@lemmy.world 2 points 2 days ago

Yes I need to use enums. I realized it now.