Please refrain from using slurs and disparage people for no good reason on our instance.

The person has previously been warned to stopped posting links to the site. They’ve now been given a temp ban, if that doesn’t deter them, they’ll be given a permanent ban and we might ban the site from our instance.

Please refrain from using personal insults in this community. You’re free to express your opinion, but personal insults does nothing but make the community more toxic. c/programming is a gathering ground for both inexperienced and experienced programmers, so this level of lashing out is uncalled for.

match isn’t a protected keyword like if is.

match = 0
match match:
    case 0:
        print(0)
    case _:
        print(1)

Is legal and will give print out 0.

That’s interesting, thanks for the reply

Might as well start with a solid foundation from the start though. The extra work is minimal so there isn’t much of a time cost to it. I wouldn’t call it overengineering, it’s just a different way to write code, and the way many naturally default to without really thinking about it.

Those doesn’t break backwards compatibility though. Naturally you can’t use match with a python 3.7 interpreter, but what scripts written for python 3.7 wouldn’t work with a 3.11 interpreter?

I haven’t encountered that issue before, so I’m curious what those problems OP have encountered looks like.

That honestly makes me curious, what issues have you encountered when upgrading your python(3) version?

I get the point the author is coming from. When I was teaching first year engineering students programming, the one on the left is how everyone would write, it’s simply how human intuitively think about a process.

However, the one on the right feels more robust to me. For non trivial processes with multiple branches, it can ugly real quick if you haven’t isolated functionalities into smaller functions. The issue is never when you are first writing the function, but when you’re debugging or coming back to make changes.

What if you’re told the new Italian chef wants to have 15 different toppings, not just 2. He also got 3 new steps that must be done to prepare the dough before you can bake the pizza, and the heat of the oven will now depend on the different dough used. My first instinct if my code was the one on the left, would be to refactor it to make room for the new functionality. With the one on the right, the framework is already set and you can easily add new functions for preparing the dough and make a few changes to addToppings() and bake()

If I feel too lazy to write “proper” code and just make one big function for a process, I often end up regretting it and refactoring it into smaller, more manageable functions once I get back to the project the next day. It’s simply easier to wrap your head around

bakePizza() 
box()```
than reading the entire function and look for comments to mark each important step. The pizza got burned? Better take a look at `bakePizza()` then.

All it took for me to switch to GitLab was a larger free lfs quota which I wanted for a project. The superior webpage UI made me migrate every old project to it too.

I assume you meant that both Rust and C compiles into machine code? Python compiles into bytecode that is then run in a VM, Rust and C usually doesn’t do that as far as I know.

I was mostly curious if it was as easy as in C. Turun’s reply answered that question though. Cheers.

Interesting stuff, might give me an excuse to look into rust in the future. Thanks!

Could you elaborate on that point? Is it as smooth as using C?

Tabs work fine, you aren’t allowed to mix, indentation must be consistent.

It’d honestly the funniest thing I’ve read on this instance. Puts programmer humour to shame. Love it when developers finds the jankiest/unconventional way to solve problems.

Clean code would have indentation though, and you can use whatever space you want as indentation. Bonus points if you use tabs so that others with special needs can configure the tab length on their end.

And I don’t think I’ve encountered an indentation error since the day I learned the language. How often do you encounter that error when writing python scripts? Sounds more like a theoretical problem than something anyone used to python would encounter.

I’ve never understood the complaint about forced indentation. What kind of monster doesn’t use indentation for their code anyway?

If anything, it’s nice that the language forces it on you so that you don’t stumble on code written by one of those monsters.

A round number is a number that is the product of a considerable number of comparatively small factors (Hardy 1999, p. 48). Round numbers are very rare. As Hardy (1999, p. 48) notes, “Half the numbers are divisible by 2, one-third by 3, one-sixth by both 2 and 3, and so on. Surely, then we may expect most numbers to have a large number of factors. But the facts seem to show the opposite.”

A positive integer n is sometimes said to be round (or “square root-smooth”) if it has no prime factors greater than sqrt(n). The first few such numbers are 1, 4, 8, 9, 12, 16, 18, 24, 25, 27, 30, 32, … (OEIS A048098). Using this definition, an asymptotic formula for the number of round integers less than or equal to a positive real number x is given by N(x)∼(1-ln2)x+O(x/lnx)

(Hildebrand).

https://mathworld.wolfram.com/RoundNumber.html

Alternatively, a number rounded off to a given precision in whatever numeral system you are using. E.g. ten in decimal may be round if you are dealing with small numbers in the decimal system, but it wouldn’t be particularly round if you were dealing with large numbers or hexadecimal.

Strange, is there really no report button on lemmy/Jerboa?

I ended up finding a oled theme and then just tweak it to fit my taste. It’s a bit of a hassle but you can upload it to the marketplace to have easy access to it across your units.