this post was submitted on 14 May 2024

311 points (91.2% liked)

Programmer Humor

32415 readers

518 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.

founded 5 years ago

MODERATORS

[email protected]

311

Python is great, but stuff like this just drives me up the wall (lemmy.world)

submitted 5 months ago* (last edited 5 months ago) by [email protected] to c/[email protected]

61 comments fedilink hide all child comments

Explanation: Python is a programming language. Numpy is a library for python that makes it possible to run large computations much faster than in native python. In order to make that possible, it needs to keep its own set of data types that are different from python's native datatypes, which means you now have two different bool types and two different sets of True and False. Lovely.

Mypy is a type checker for python (python supports static typing, but doesn't actually enforce it). Mypy treats numpy's bool_ and python's native bool as incompatible types, leading to the asinine error message above. Mypy is "technically" correct, since they are two completely different classes. But in practice, there is little functional difference between bool and bool_. So you have to do dumb workarounds like declaring every bool values as bool | np.bool_ or casting bool_ down to bool. Ugh. Both numpy and mypy declared this issue a WONTFIX. Lovely.

top 50 comments

sorted by: hot top controversial new old

[–] [email protected] 2 points 5 months ago

Why use bool when you can use int?

just never #define true 0

[–] [email protected] 67 points 5 months ago (1 children)

Type checker detecting different types?

[–] [email protected] 1 points 5 months ago

Why is this meme still so fuckin funny 😅

[–] [email protected] 79 points 5 months ago (3 children)

What years of dynamic typing brainrot does to mf

[–] [email protected] 5 points 5 months ago

That's actually a quite bad way of naming types, even if someone really insists on using 32 bit integers for bools for "performance" reasons.

[–] [email protected] 18 points 5 months ago (1 children)

I currently work on a NodeJS/React project and apparently I'm going to have to start pasting "'any' is not an acceptable return or parameter type" into every damned PR because half the crazy kids who started programming in JavaScript don't seem to get it.

For fucks sake, we have TypeScript for a reason. Use it!

[–] [email protected] 15 points 5 months ago (1 children)

if you have a pipeline running eslint on all your PRs (which you should have!), you can set no-explicit-any as an error in your eslint config so it's impossible to merge code with any in it

[–] [email protected] 4 points 5 months ago

+1 if you can have automated checks do part of your reviews for you, it's a win. I never comment about code style anymore, if I care enough I'll build it into the lint config

[–] [email protected] 5 points 5 months ago

I learned Python as my first programming language, but ever since I got into other languages, I don't like going back to dynamic typing...

[–] [email protected] 32 points 5 months ago* (last edited 5 months ago) (3 children)

So you have to do dumb workarounds like declaring every bool values as bool | np.bool_ or casting bool_ down to bool.

these dumb workarounds prevent you from shooting yourself on the foot and not allowing JS-level shit like "1" + 2 === "12"

[–] [email protected] 1 points 5 months ago* (last edited 5 months ago) (1 children)

"1" + 2 === "12" is not unique to JS (sans the requirement for the third equals sign), it's a common feature of multiple strongly typed languages. imho it's fine.

EDIT: I did some testing:

What it works in:

JS
TS
Java
C#
C++
Kotlin
Groovy
Scala
PowerShell

What produces a number, instead of a string:

PHP
SQL
Perl
VB
Lua

What it doesn't work in:

R
C
Go
Swift
Rust
Python
Pascal
Ruby
Objective C
Julia
Fortran
Ada
Dart
D
Elixir

And MATLAB appears to produce 51, wtf idk

[–] [email protected] 2 points 5 months ago (1 children)

And MATLAB appears to produce 51, wtf idk

The numeric value of the '1' character (the ASCII code / Unicode code point representing the digit) is 49. Add 2 to it and you get 51.

C (and several related languages) will do the same if you evaluate '1' + 2.

[–] [email protected] 1 points 5 months ago

Oh that makes sense. I didn't consider it might be treated as a char

[–] [email protected] 1 points 5 months ago* (last edited 5 months ago) (2 children)

Well, C has implicit casts, and it's not that weird (although results in some interesting bugs in certain circumstances). Python is also funny from time to time, albeit due to different reasons (e.g. -5**2 is apparently -25 because of the order of operations)

[–] [email protected] 1 points 5 months ago (1 children)

-5**2 is apparently -25 because of the order of operations)

Which is correct

[–] [email protected] 1 points 5 months ago (1 children)

Well, the link doesn't load for me, so if that's smth related to python and not a justification of the behavior from math's pov, I know that's expected. Hence,

because of the order of operations

But just as well is "1" + 2.

[–] [email protected] 1 points 5 months ago

Well, the link doesn’t load for me

Yeah, they're doing an upgrade right now. Yes, it's the Maths explanation - -25 is the correct answer.

[–] [email protected] 7 points 5 months ago (1 children)

I don't see how your example is 'funny'. That's what you expect to get. -5^2^ is -25. (-5)^2^ = 25.

[–] [email protected] 0 points 5 months ago

And how's that different from js's "1" + 2? One can always convert a number to string, and only sometimes -- a string to a number, so it's pretty logical to go with the former.

[–] [email protected] 2 points 5 months ago* (last edited 5 months ago) (1 children)

The JS thing makes perfect sense though,

"1" is a string. You declared its type by using quotes. myString = "1" in a dynamically typed language is identical to writing string myString = "1" in a statically typed language. You declare it in the symbols used to write it instead of having to manually write out string every single time.

2 is an integer. You know this because you used neither quotes nor a decimal place surrounding it. This is also explicit.

"1" + 2, if your interpreter is working correctly, should do the following

identify the operands from left to right, including their types.
note that the very first operand in the list is a string type as you explicitly declared it as such by putting it in quotes.
cast the following operands to string if they are not already.
use the string addition method to add operands together (in this case, this means concatenation).

In the example you provided, "1" + 2 is equivalent to "1" + "2", but you're making the interpreter do more work.

QED: "1" + 2 should, in fact, === "12", and your lack of ability to handle a language where you declare types by symbols rather than spending extra effort writing the type out as a full english word is your own shortcoming. Learn to declare and handle types in dynamic languages better, don't blame your own misgivings on the language.

Signed, a software engineer.

[–] [email protected] 2 points 5 months ago

TypeError is also a correct response, though, and I think many folks would say makes more sense. Is an unnecessary footgun

[–] [email protected] 28 points 5 months ago (2 children)

Good meme, bad reasoning. Things like that are why JavaScript is hated. While it looks the same, It should never, and in ANY case be IMPLICITLY turned into another type.

[–] [email protected] 1 points 5 months ago

reasoning

What reasoning? I'm not trying to make any logical deductions here, I'm just expressing annoyance at a inevitable, but nevertheless cumbersome outcome of the interaction between numpy and mypy. I like python and I think mypy is a great tool, I wouldn't be using it otherwise.

[–] [email protected] 4 points 5 months ago

Typing and function call syntax limitations are exactly why I hate JS.

[–] [email protected] 87 points 5 months ago* (last edited 5 months ago) (2 children)

Honestly, after having served on a Very Large Project with Mypy everywhere, I can categorically say that I hate it. Types are great, type checking is great, but applying it to a language designed without types in mind is a recipe for pain.

[–] [email protected] 17 points 5 months ago

Adding types on an untyped project is hell. Greenfield stuff is usually pretty smooth sailing as far as I’m concerned…

[–] [email protected] 13 points 5 months ago (1 children)

In my experience, mypy + pydantic is a recipe for success, especially for large python projects

[–] [email protected] 6 points 5 months ago (1 children)

I wholeheartedly agree. The ability to describe (in code) and validate all data, from config files to each and every message being exchanged is invaluable.

I'm actively looking for alternatives in other languages now.

[–] [email protected] 9 points 5 months ago (2 children)

You're just describing parsing in statically-typed languages, to be honest. Adding all of this stuff to Python is just (poorly) reinventing the wheel.

Python's a great language for writing small scripts (one of my favorite for the task, in fact), but it's not really suitable for serious, large scale production usage.

[–] [email protected] 2 points 5 months ago

Gradual typing isn't reinventing the wheel, it's a new paradigm. Statically typed code is easier to write and harder to debug. Dynamically typed code is harder to debug, but easier to write. With gradual typing, the idea is that you can first write dynamic code (easier to write), and then -- wait for it -- GRADUALLY turn it into static code by adding type hints (easier to debug). It separates the typing away from the writing, meaning that the programmer doesn't have to multitask as much. If you know what you're doing, mypy really does let you eat your cake and keep it too.

[–] [email protected] 2 points 5 months ago (1 children)

I'm not talking about type checking, I'm talking about data validation using pydantic. I just consider mypy / pyright etc. another linting step, that's not even remotely interesting.

In an environment where a lot of data is being exchanged by various sources, it really has become quite valuable. Give it a try if you haven't.

[–] [email protected] 4 points 5 months ago (1 children)

I understand what you're saying—I'm saying that data validation is precisely the purpose of parsers (or deserialization) in statically-typed languages. Type-checking is data validation, and parsing is the process of turning untyped, unvalidated data into typed, validated data. And, what's more, is that you can often get this functionality for free without having to write any code other than your type (if the validation is simple enough, anyway). Pydantic exists to solve a problem of Python's own making and to reproduce what's standard in statically-typed languages.

In the case of config files, it's even possible to do this at compile time, depending on the language. Or in other words, you can statically guarantee that a config file exists at a particular location and deserialize it/validate it into a native data structure all without ever running your actual program. At my day job, all of our app's configuration lives in Dhall files which get imported and validated into our codebase as a compile-time step, meaning that misconfiguration is a compiler error.

[–] [email protected] 1 points 5 months ago* (last edited 5 months ago)

I am aware of what you are saying, however, I do not agree with your conclusions. Just for the sake of providing context for our discussion, I wrote plenty of code in statically typed languages, starting in a professional capacity some 33 years ago when switching from pure TASM to AT&T C++ 2, so there is no need to convince me of the benefits :)

That being said, I think we're talking about different use cases here. When I'm talking configuration, I'm talking runtime settings provided by a customer, or service tech in the field - that hardly maps to a compiler error as you mentioned. It's also better (more flexible / higher abstraction) than simply checking a JSON schema, and I'm personally encountering multiple new, custom JSON documents every week where it has proven to be a real timesaver.

I also do not believe that all data validation can be boiled down to simple type checking - libraries like pydantic handle complex validation cases with interdependencies between attributes, initialization order, and fields that need to be checked by a finite automaton, regex or even custom code. Sure, you can graft that on after the fact, but what the library does is provide a standardized way of handling these cases with (IMHO) minimal clutter. I know you basically made that point, but the example you gave is oversimplified - at least in what I do, I rarely encounter data that can be properly validated by simple type checking. If business logic and domain knowledge has to be part of the validation, I can save a ton of boilerplate code by writing my validations using pydantic.

Type annotations are a completely orthogonal case and I'll be the first to admit that Python's type situation is not ideal.

load more comments