thebestaquaman @ thebestaquaman @lemmy.world

Posts

11

Comments

588

Joined

2 yr. ago

The next best time is now

If my Easter break gets boring I might just start cleaning up that Python library... It's the prime example of something that developed from a POC to a fully functional code base, was left largely unused for about a year, and just the past weeks has suddenly seen a lot of use again. Luckily we're strict about good docstrings, but type hints would have been nice too.

I really do agree on all your points, so at the end of the day I think a lot comes down to use-case and personal preference.

My primary use cases for Python are prototyping and as a frontend/scripting tool for software written in C/C++/Fortran. In those scenarios, spending significant time on type hinting and unittests defeats the purpose of using Python (blazing fast development).

I've written/worked on only one larger code base in pure Python, and my personal opinion became that I heavily prefer strictly typed languages once the code base exceeds a certain size. It just feels so much smoother to work with when I have actual guarantees that are enforced by the language.

With that said, we were a bunch of people that are used to using Python for prototyping that developed this larger library, and it would probably have gone a lot better if we actually enforced use of proper type hinting from the start (which we were not used to).

Type hints are usually great, as long as they're kept up to date and the IDE interprets them correctly. Recently I've had some problems with PyCharm acting up and insisting that matplotlib doesn't accept numpy arrays, leading me to just disable the type checker altogether.

All in all, I'm a bit divided on type hints, because I'm unsure whether I think the (huge) value added from correct type hints outweighs the frustration I've experienced from incorrect type hints. Per now I'm leaning towards "type hints are good, as long as you never blindly trust them and only treat them as a coarse indicator of what some dev thought at some point."

Exactly "locking away without food or water" makes it sound like the time perspective we're talking about is long enough that access to food and water are necessary within that time span.

I would say you should never lock away a kid for so long that they need access to food and water at all.

We seem to agree here: I'm by no means advocating that you should ever explicitly withhold water from a thirsty kid. I just think a lot of people here have gone over-the-top regarding how horrible it is to send a kid to their room without putting a bottle of water in there first. It's not like feeling thirsty for a bit or getting slightly dehydrated is in any way detrimental to anyone's health. People get thirsty and lightly dehydrated all the time, either on hiking trips or because they forgot to bring water for something that lasts a while.

The important thing, as I see it, is that you never put the kid in a situation where they honestly begin to doubt whether you care about their well-being and are going to look after them.

Then I absolutely understand you :)

How common it is 100 % depends on the code base and what practices are preferred. In Python code bases where I have a word in decisions, all Boolean checks should be x is True or x is False if x should be a Boolean. In that sense, if I read if x or if not x, it's an indicator that x does not need to be a Boolean.

In that sense, I could say that my preference is to flip it (in Python): Explicitly indicate/check for a Boolean if you expect/need a Boolean, otherwise use a "truethiness" check.

I definitely agree that len is the preferred choice for checking the emptiness of an object, for the reasons you mention. I'm just pointing out that assuming a variable is a bool because it's used in a Boolean context is a bit silly, especially in Python or other languages where any object can have a truthiness value, and where this is commonly utilised.

There is no guarantee that the comment is kept up to date with the code. "Self documenting code" is a meme, but clearly written code is pretty much always preferable to unclear code with a comment, largely because you can actually be sure that the code does what it says it does.

Note: You still need to comment your code kids.

Exactly as you said yourself: Checking falsieness does not guarantee that the object has a length. There is considerable overlap between the two, and if it turns out that this check is a performance bottleneck (which I have a hard time imagining) it can be appropriate to check for falsieness instead of zero length. But in that case, don't be surprised if you suddenly get an obscure bug because of some custom object not behaving the way you assumed it would.

I guess my primary point is that we should be checking for what we actually care about, because that makes intent clear and reduces the chance for obscure bugs.

I would say it depends heavily on the language. In Python, it's very common that different objects have some kind of Boolean interpretation, so assuming that an object is a bool because it is used in a Boolean context is a bit silly.

I write a lot of Python. I hate it when people use "X is more pythonic" as some kind of argument for what is a better solution to a problem. I also have a hang up with people acting like python has any form of type safety, instead of just embracing duck typing.This lands us at the following:

The article states that "you can check a list for emptiness in two ways: if not mylist or if len(mylist) == 0". Already here, a fundamental mistake has been made: You don't know (and shouldn't care) whether mylist is a list. These two checks are not different ways of doing the same thing, but two different checks altogether. The first checks whether the object is "falsey" and the second checks whether the object has a well defined length that is zero. These are two completely different checks, which often (but far from always) overlap. Embrace the duck type- type safe python is a myth.

I agree that "people should have access to clean water". Let's not confuse sending a child to their room to wind down when they're throwing a fit with torture.

No one takes harm from lack of water in a mild climate over the course of a couple hours. The reason it's bad to lock a kid in the basement (or any other room) is that you're taking away their freedom (which may be, to some point, justified and correct) and potentially making it harder for them to trust you. However, kids also need to learn that there are limits to how you can behave, and consequences for breaking those limits. Where the limit between "reasonable consequences for teaching children" and "trust-breaking punishment" lies is a fair discussion to have. No need to pull "locking a kid in their room is torture" into it.

Of all youtube jackasses, this might be one of the biggest. Imagine making a living off pushing semi-scams on twelve year olds and being a nuisance at sporting events..

I agree on a general basis that it's bad that these kind of decisions are offloaded to an AI. A human should be the one to consider whether the blind 70 year old is dangerous, because they definitely can be.

Operating a vehicle or weapon requires neither eyesight nor a clear mind if you don't intend to do it safely.

I don't mean to say that C++ is in any way without faults. If performance is crucial, that can definitely be a reason to forgo some of the guard-rails, and then you're on your own.

I guess my issue with the "C++ is unsafe"-trope, is that it usually (in my experience) comes from people not having heard of all the guard-rails in the first place, or refusing to use them when appropriate. They write C++ as if they were writing C, and then complain that the language is unsafe when they've made a mistake that is easily avoided using stl-containers.

OP isn't saying trump is playing 12D chess though. They're speculating whether some of the younger people that have been known to be planning for societal collapse for years already are using their influence over trump to help their plans for societal collapse.

As I said: There are tools in place in modern C++ that are designed to catch the errors you make. If you are using a raw pointer when you could have used a reference, or accessing an array without range checking, those are choices you've made. They may be valid choices in your use-case, but don't go complaining that the language is "unsafe" when it gives you the option to code with guard rails and you choose to forgo them.

Memory unsafe C++ is a choice. With modern C++ you have no excuse for accessing raw pointers or arrays without range checking if memory safety is a priority.

Let's get some to Europe as well! You're welcome here :D

What you say is true, but doesn't really answer "Could someone take down Wikipedia [without completely shutting off the internet]". For obvious reasons, shutting internet access completely off isn't going to happen short of an insurrection or a war.

Shutting down Wikipedia specifically is much harder. As others have pointed out, there are many thousand copies of Wikipedia lying around on peoples private devices. If Wikipedia were actually taken down (blocked by the government in some sense) hundreds of mirrors would likely pop up immediately, and it would be more or less impossible for the government to go after each individual site that some person decides to host, short of just cutting internet access completely.