I’m usually disappointed by the vote compass. Lately it has been putting me between the Liberals and Cons because I am ambivalent about social issues and left leaning on economic issues. If you think it is non of the government’s business which race/gender you are, that is putting you on the right these days.
They've introduced a feature at the end where you can choose to weight your answers, so the social issues you don't really care about can be weighted 0 and get a more accurate result.
I live firmly in the #FuckCars camp, but I honestly think this is fantastic. Standards and conformity breed massive changes within an industry if they're permitted to take root, and this is already bucking the "monster truck" trend that's killing people and ruining cities.
Imagine the potential of a city buying a few thousand of these to serve as work vehicles: interchangeable parts would drastically reduce costs as you could canibalise one vehicle to service many, and you could easily re-task vehicles with minor, off-the-shelf (or even custom) modifications.
The real test though will be whether (a) the establishment car companies will allow it to survive, and (b) whether its US origins will make it radioactive to the rest of the world given their current fall toward fascism.
I never said that they should make promises about Palestine's future. I only ask that anyone claiming to want to lead our country have the integrity to at least recognise that a genocide is being conducted, and that we are facilitating it.
I actually really like doing code reviews, so I'm happy to dig into this one. I have a lot of comments, but please don't take this as a criticism of your skills, or even of the code itself. I'm just... really thorough ;-) Hopefully, you'll find some of this helpful.
The first suggestion I have is to install a code formatter like ruff or black. The Python community develops our code to a standard called pep8 which you're violating all over the place here, making it harder to read your code. Rather than having to go through it all and manually conforming it though, tools like ruff or black will do it with one command. A lot of developers will even plug them into their IDE to run against their code on-save, so you don't even have to think about running it.
Pep8 says that constants should be in ALL_CAPS while attributes should be in snake_case, and for the most part, it looks like you're trying to conform to that, but some of your constants aren't... well constant. You define self.API_URL for example as the result of a variable passed to __init__. This would mean that the value could conceivably be different in two instances of the same class. There's nothing wrong with that, but labelling it as if it were a constant is bad form.
While not necessary for running your program, they're still super helpful both for readability and ensuring you haven't introduced any bugs accidentally. If you're using a proper IDE like PyCharm for example, it will warn you if you've passed an int to a method that's expecting a string for example. As your project gets more complicated, and you start passing around complex objects with varying abilities, type hints can be a big help.
Don't listen to the haters on classes. This is great. It's a good clean way to maintain state inside a component, rather than having to pass objects around to disparate functions.
elseThis is just a pet peeve of mine, but else should be used sparingly. There's nothing wrong with it per se, but it's often unnecessary. Consider the following two toy examples:
def my_func() -> None:
if something:
return 4
else:
return 5
That else is useless. the above could be:
def my_func() -> None:
if something:
return 4
return 5
Similarly, this:
def my_func() -> None:
if something:
x = 1
y = 2
else:
raise SomeException(...)
This would be a lot clearer if you invert the test:
def my_func() -> None:
if not something:
raise SomeException(...)
x = 1
y = 2
This comes up all the time, and it just bugs me. I'm not throwing shade, just trying to reduce the number of superfluous else's in the world :-)
The big offender here is WeatherApp.LOCATIONS. You define it first as a constant that you later change (see above), and you reference parts of it all over the place, meaning you've got to ensure that every part of your app (a) is familiar with its internals and (b) won't modify it, thereby breaking other parts of your app accidentally. There's also this LOWLOCATIONS business, which reads like a crutch you added to work around other limitations.
Instead, I suggest delegating this sort of thing to a separate class. Consider something like this:
from typing import Self
class Location:
def __init__(self, name: str, lat: float, lng: float) -> None:
self.name = name
self.lat = lat
self.lng = lng
class LocationManager:
def __init__(self) -> None:
self._locations = []
def add_location(self, name: str, lat: float, lng: float) -> None:
self._locations.append(Location(name=name, lat=lat, lng=lng))
@classmethod
def build(cls, data: dict[str, dict[str, float]]) -> Self:
self = cls()
for name, coords in data.items():
self.add_location(name, coords["lat"], coords["lng"])
return self
def export(self) -> dict[str, dict[str, float]]:
r = {}
for loc in self._locations:
r[loc.name] = {"lat": loc.lat, "lng": loc.lng}
return r
This would offload the complexity carrying around that structure throughout your application and instead define a set API between "how you think about locations" and "how your app uses them". It'd also let you remove a lot of your location-specific code from the rest of your project where arguably it doesn't belong.
__init__It's fine to change an instance's attributes from inside a random method, but initialising them should only ever happen in __init__. This is largely to do with readability, but also with stability. Consider the following:
class Thing:
def __init__(self) -> None:
pass
def do_x(self, something: str) -> None:
self.alpha = something
def do_y(self) -> None:
print(self.alpha)
Thing().do_y()
This will barf with an attribute error and when someone looks at the class trying to figure out where alpha is set, __init__() is useless. Now imagine that the class is around 600 lines long and that's quite the headache.
Sometimes, this is rather academic, like where you've called .load_config() from .__init__() directly. In these cases, I'd recommend defining the attribute on the class so at least it's clear that this is something that the class supports externally:
class WeatherApp:
config: dict[str, str | dict[str, dict[str, float]
api_url: str
locations: LocationManager
def __init__(self, config_file="config.json") -> None:
self.load_config(config_file)
It's great that you're trying to break up your project into responsible parts, but they're rather tightly coupled, so the responsibility to do anything rests with the entire app rather than any individual part.
For example, you've go this WeatherAPI class. It's a good idea. You want to delegate the responsibility of talking to an external API to something that knows how to do that (and only that), but in order to use the one you've built here, I'd need to pass it both the name of the city you want to look up, and the entire cities dataset, and the URL it needs to do the job.
It's kind of like asking someone to make you a sandwich, and then taking the time to show them where the bread, ham, and cheese are in the fridge... you might as well make it yourself at that point.
Additionally, your API abstraction isn't just doing API things, but it's also handling the rendering step, doing a whole bunch of print() and colour formatting etc. That's not the job of an API.
Instead, I suggest building this sort of thing "backwards". Decide on the API you want, and then build that out. Imagine for a moment how you might want the WeatherAPI class to work:
class WeatherApp:
def __init__(self, ...) -> None
...
self.wapi = WeatherAPI(api_url)
def run(self) -> None:
...
for location in locations:
# We can use our `Location` class to pass
# everything `.fetch()` needs in one variable.
weather = wapi.fetch(location)
self.render_daily_weather(weather.current)
self.render_current_temperature(weather.temperature)
This drastically simplifies your WeatherAPI class and allows you room to add support for things like caching, or handling rate limits etc. Better yet, you can delegate the various bits of data tweaking you're doing in both WeatherApp and WeatherAPI to a separate class that just accepts raw API data and then distils it down to useful values. In the end, it might look something like this:
class WeatherResult:
CODES = {
0: "Clear sky",
...
}
DAY_NIGHT = {0: "Day", 1: "Night"}
def __init__(self, current: dict, temperature: float) -> None:
self.current = current
self.temperature = temperature
@property
def description(self) -> str:
return self.CODES.get(
self.current["weather_code"],
"Unknown weather code",
)
@property
def daynight(self) -> str:
return self.DAY_NIGHT[self.current["is_day"]]
class WeatherAPI:
def __init__(self, url: str) -> None:
self.url = url
def fetch(self, city: Location) -> None:
url = f"{self.url}?latitude={city.lat}&longitude"
...
return WeatherResult(current=..., temperature=...)
That's it! Honestly, this is a good start, so please don't be discouraged by the verbosity of the above. Thanks for sharing your code, and have fun in future projects!
In an election where the two leading parties are refusing to even acknowledge that genocide is being committed by a "friend" and ally, a country to which we continue to sell arms, I'd argue that the NDP's stance on Gaza is probably the only thing they've done right in this election. Your suggestion that Canada can't do anything is just plain wrong. We should, for example:
I'm all for trying to build a "big tent" party with a diversity of views, but that should stop at genocide enablers and apologists.
Sadly, this sort of bulllshit is common with border authorities all over the place. My wife's Greek passport was once rejected by a British official who claimed that it must be fake because "there's no such thing as a Hellenic Republic".
That's the official name for Greece.
I'm not sure that I would attribute this sort of thing to malice though. I think CBSA might just be perpetually hiring from the shallow end of the gene pool.
I've got an Arctis 7 myself and it works just fine in Linux, no special drivers or anything needed. However, there are a bunch of features in their proprietary app which I used for all of a few minutes on a Windows machine (I think there was an equaliser in there?) and that might work in Linux under Wine... but I'm not sure as I've never bothered.
“Canada would then have to put the customs border between itself and the U.S. and apply EU tariffs and regulations on imports from the U.S. … It would be incredibly economically destructive. It would outweigh any benefits that it might expect to get from the [EU] membership over many, many years,”
With what Trump's been doing with the tariffs, the above statement may not be true for much longer. It may well be cheaper to ship to Rotterdam than to Rochester.
He definitely says "gagged". This post is ridiculous.
Well shit. What good is pasta without parmesan? And no feta? Gouda? How is life worth living without good cheese?
Honestly, this feels a little gross.
Too many people just spent the last 5 weeks demanding that everyone "hold their nose and vote Liberal to keep the Conservatives out", knowingly cratering support for the smaller parties, and now you turn around and are all like "we have to work together"?
Fuck. That.
We have common cause, but if the Liberals were serious about working together they would have embraced proportional representation. They didn't. They wanted domination, campaigning hard in Green & NDP ridings and even with the #ElbowsUp anti-Trump wave, Canadians still didn't want to trust them with a majority. It's not the role of the smaller parties to prop up the neoliberal "shit lite" party, it's to force them to do right by the country. I expect them to do that.