Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python types have an expectations problem

medium.com

Post reply on HN
Print view View original

61–70 of 115 posts

Re: Python types have an expectations problem

#61

Post by SAI_Peregrinus »

maxfurman wrote: post #54
robertlagrant wrote: post #33

Earlier quoted context omitted.

It has something, but not what you'd call modern type checking: #include int main(void) { unsigned int positive_number = -1; printf("%d", positive_number); return 0; } Prints -1.

I must be missing something here. Wouldn't an unsigned int be unable to represent -1 since the sign bit is part of the value?

C implicitly converts integer types as needed. The specific conversion rules are rather convoluted, see section 6.3 of the ISO C standard for the details. Before C23 this was implementation defined, but since C23 now mandates two's complement representation of signed integers and wrapping for unsigned overflow (as before) the `-1` is converted to UINT_MAX. Then the `%d` format specifier performs a conversion from `unsigned int` back to `int` for printing, resulting in `-1`. Implicit conversions between types of the same rank are guaranteed to "round-trip", you get back the value you started with when converting back to the starting type. If they'd specified an unsigned format specifier for printing then they wouldn't get `-1` printed.

Re: Python types have an expectations problem

#62

Post by free_bip »

maxfurman wrote: post #54
robertlagrant wrote: post #33

Earlier quoted context omitted.

It has something, but not what you'd call modern type checking: #include int main(void) { unsigned int positive_number = -1; printf("%d", positive_number); return 0; } Prints -1.

I must be missing something here. Wouldn't an unsigned int be unable to represent -1 since the sign bit is part of the value?

The -1 here is hiding the fact that -1 is really just 0xffffffff due to two's complement (architecture dependant of course)

And printing it as %d is technically a misuse of printf, since %d means print as a signed integer. If you did %u (print as unsigned integer) instead you'd see the value is really 4,294,967,295 (again, platform dependant)

Re: Python types have an expectations problem

#63

Post by sevensor »

michaelt wrote: post #58
sevensor wrote: post #49

Earlier quoted context omitted.

Python's type hints are great as machine-checkable statements about constraints on the behavior of your code. It's not strictly true that they're unavailable at runtime. > Don't count on them at runtime here either If you're adventurous enough, you can reflect on the type hints and check things yourself at runtime, but you have to understand that the type hints aren't meant for this and they could well blow up in you…

> It's not strictly true that they're unavailable at runtime. So is it possible for me to enforce type hints at runtime, so my program crashes if a type is ever wrong? How do I turn this checking on?

If you want to. It would be a lot of work. I check input data on the boundary and rely on mypy to tell me when I've made a type error in the interior, and I find that works well enough. Also, see my disclaimers, this stuff isn't really meant to be used how I'm using it; it's meant for static checkers like mypy and I'm just abusing the fact that the interpreter does anything at all with type hints. But if you really wanted to, you could probably write a decorater that would do the same kind of checking I'm doing at the boundary.

Re: Python types have an expectations problem

#64

Post by ReflectedImage »

empath-nirvana wrote: post #60
ReflectedImage wrote: post #59

Using static typing in Python is a serious mistake. The point of static typing is to allow an compiler to compile your code for performance reasons and nothing else. People do not normally compile Python code with a compiler. Static typing significantly increases code length compared to duck typing, significantly increases development times and significantly increases bug count per delivered software feature. It addi…

> significantly increases bug count per delivered software feature. Going to need a source for this.

It should be fair obvious that when you use a very verbose very boiler plate heavy coding style like static typing that because the programmer is writing a lot more lines of code per software feature and because the programmers make errors on a per line written basis that the number of the bugs will drastically increase.

You can easily find information on duck typed programs being significantly shorter and that statically typed and ducked typed programs have the same bug count per line. You can also look at the language defective tables showing ducked type Clojure as having the least bugs in commerical software and statically typed C++ having the most bugs in commerical software.

Google is your friend here.

Re: Python types have an expectations problem

#65

Post by d0mine »

olejorgenb wrote: post #31
miohtama wrote: post #5

Earlier quoted context omitted.

It's also good to note that all popular editors and IDEs like Visual Studio Code and PyCharm support type hints quite well by default. Some external tooling needed, but it's your editor and you are going to have any case.

PyCharm unfortunately does not supports type hints fully. It certainly utilize the hints, but there's a bunch of things it simply does not understand which make hinting much less useful when using PyCharm.

Could you provide an example?

Re: Python types have an expectations problem

#66

Post by dolni »

ReflectedImage wrote: post #64
empath-nirvana wrote: post #60

Earlier quoted context omitted.

> significantly increases bug count per delivered software feature. Going to need a source for this.

It should be fair obvious that when you use a very verbose very boiler plate heavy coding style like static typing that because the programmer is writing a lot more lines of code per software feature and because the programmers make errors on a per line written basis that the number of the bugs will drastically increase. You can easily find information on duck typed programs being significantly shorter and that stati…

I have written type-annotated Python for as long as type annotations have been a thing.

"Number of bugs will drastically increase" is simply wrong.

Type checking prevents bugs before they ship.

Re: Python types have an expectations problem

#67

Post by MrJohz »

saghm wrote: post #51
ehutch79 wrote: post #6

A note; typescript does nothing to ensure types are correct at runtime. Especially in the browser. You need to do runtime checking even if you're using typescript. In Python, yeah, they're called Type _Hints_ for a reason. Don't count on them at runtime here either. Both are dynamic languages, it's hard doing anything meta/schema driven with rigid types. If you really want a hard type system, just move to GO or Rust…

To be fair, TypeScript is a bit different because you can use it to compile to JavaScript rather than merely annotating in JavaScript files, which is crucial because it means that compilation can _fail_ to produce JavaScript. If I recall correctly, you can still have it produce JavaScript even if the type checking fails, but the fact that you can't just directly run the TypeScript makes a difference. With the Python…

I'm not sure that's really a practical distinction between Typescript and Python. Most of the practical bundling setups I've seen use a tool like Babel or Esbuild, which doesn't do any type checking - instead the type checking is done as a linting/testing check beforehand, the same as with Python. And as you point out, even if you compile directly with Typescript, it will quite happily compile code that doesn't pass the type checks, as a configuration option.

And this isn't just a side effect of the build tools, but a genuinely useful feature. While I'm working on a change, I can run half-finished code and get some feedback before fixing the rest. This is particularly useful for tests - I can test a module, even if I've not yet updated all of that module's usages, to sanity check whether what I'm doing makes sense.

There can definitely be downsides to this separation of type system and runtime behaviour, but it's also very useful, and it works the same in Typescript and Python.

I think the biggest issue that Python's type checking has in comparison to Typescript is just sheer power: Typescript can very explicitly and correctly type real-world Javascript code, whereas typed Python, in my experience, ends up feeling a lot more like old-school Java than idiomatic Python. And it's difficult to sell old-school Java to Python developers.

Re: Python types have an expectations problem

#68

Post by klardotsh »

ReflectedImage wrote: post #64
empath-nirvana wrote: post #60

Earlier quoted context omitted.

> significantly increases bug count per delivered software feature. Going to need a source for this.

It should be fair obvious that when you use a very verbose very boiler plate heavy coding style like static typing that because the programmer is writing a lot more lines of code per software feature and because the programmers make errors on a per line written basis that the number of the bugs will drastically increase. You can easily find information on duck typed programs being significantly shorter and that stati…

So not only did you pull the original comment's assertions out of your _bag of holding_ but rather than citing sources when asked, you doubled down on "well if you know you know" and claim that the (often relatively small) increases to line lengths of type-annotated programs somehow magically increases the number of bugs, again with no evidence.

If you're not going to bring bold numbers to support bold claims, why should any of us bother listening?

Re: Python types have an expectations problem

#69

Post by pharmakom »

yoyohello13 wrote: post #13
posix_monad wrote: post #11

In Python it's common to have functions whose return types depend on the run-time arguments. For example: def fooify(x): if isinstance(x, list): map(fooify, x) else: x * 2 I guess this is to make scripting more forgiving. In typical typed languages, you would have two functions instead: fooify : number -> number fooifyMany : [number] -> [number] But in the Python community, it's common to have a big function with man…

You can annotate OR types in python so in this case you could do def fooify(x: int | list[int])

But if x is an int, the result is an int

If x is a list, the result is a list

I don’t think that the type system can describe this.

Re: Python types have an expectations problem

#70

Post by ehutch79 »

lgas wrote: post #42
ehutch79 wrote: post #6

A note; typescript does nothing to ensure types are correct at runtime. Especially in the browser. You need to do runtime checking even if you're using typescript. In Python, yeah, they're called Type _Hints_ for a reason. Don't count on them at runtime here either. Both are dynamic languages, it's hard doing anything meta/schema driven with rigid types. If you really want a hard type system, just move to GO or Rust…

> A note; typescript does nothing to ensure types are correct at runtime. Especially in the browser. You need to do runtime checking even if you're using typescript. I'm not sure I understand - in what situation would you need runtime type checking? I always assumed the situation was similar to Haskell where the types are erased at runtime but it's still impossible (absent opting in to unsafe stuff) to have type erro…

As the other commenter said, ingesting data from various sources. You don't actually know what's in that JSON.

There's also a myriad of ways to alter data running in a browser. From plugins to just fooling around with the console in DevTools.

On a large enough team, you might not be able to trust the code calling your code. It's easy to slip 'as whatever' in there. I do it when using vue's reactive objects instead of fighting with typescript.

Post reply on HN