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

Making Python fast – Adventures with mypyc

blog.meadsteve.dev

Post reply on HN
Print view View original

81–90 of 95 posts

Re: Making Python fast – Adventures with mypyc

#81

Post by meadsteve »

jmt_ wrote: post #80
isitmadeofglass wrote: post #79

Earlier quoted context omitted.

No, its better. You can build the code first, test that it functions as expected, then add types, then compile it. This is miles ahead of having to struggle with getting types correct in C++ before you even have anything resembling a workable solution.

I don't disagree but I wish Python had builtin support for runtime type checking. I've thought about switching to Go or Rust for certain projects but Python's rich ecosystem makes it hard for me to switch, so for now I long for runtime type checking without needing an external library (e.g typeguard).

Very much agree. It's one thing I really appreciated about how php added type annotations. You didn't need them but once you added them they became a gaurantee.

Re: Making Python fast – Adventures with mypyc

#82

Post by aprdm »

jmt_ wrote: post #80
isitmadeofglass wrote: post #79

Earlier quoted context omitted.

No, its better. You can build the code first, test that it functions as expected, then add types, then compile it. This is miles ahead of having to struggle with getting types correct in C++ before you even have anything resembling a workable solution.

I don't disagree but I wish Python had builtin support for runtime type checking. I've thought about switching to Go or Rust for certain projects but Python's rich ecosystem makes it hard for me to switch, so for now I long for runtime type checking without needing an external library (e.g typeguard).

You can configure vscode to fail on typing problems and it will show errors in your editor

Re: Making Python fast – Adventures with mypyc

#83

Post by ok_dad »

isitmadeofglass wrote: post #79
peterashford wrote: post #75

Earlier quoted context omitted.

Optional type hints are not the same at all.

No, its better. You can build the code first, test that it functions as expected, then add types, then compile it. This is miles ahead of having to struggle with getting types correct in C++ before you even have anything resembling a workable solution.

I don’t get the struggle with types people have. It’s not hard to use a knife instead of a hammer to cut stuff. What’s the struggle with types, specifically?

Re: Making Python fast – Adventures with mypyc

#84

Post by mixmastamyk »

chrisseaton wrote: post #78
mixmastamyk wrote: post #77

Earlier quoted context omitted.

It's solved stuff in languages other than Python. Many groups even at google have tried and failed.

No, we know how to optimise all these issues. They're solved, through a combination of online profiling, inline caching, splitting, deoptimisation, scalar replacement, etc. (I wrote a PhD on it.) I don't think you could name a single Python language feature that we don't know how to optimise efficiently. (I'd be interested if you could.) But implementing them all is a difficult engineering challenge, even for Google,…

Yes, that’s what my reply means, your “no…” is poor communication style. If you think you can do better than the folks working on it for a decade plus, by all means step up.

Re: Making Python fast – Adventures with mypyc

#85

Post by isitmadeofglass »

ok_dad wrote: post #83
isitmadeofglass wrote: post #79

Earlier quoted context omitted.

No, its better. You can build the code first, test that it functions as expected, then add types, then compile it. This is miles ahead of having to struggle with getting types correct in C++ before you even have anything resembling a workable solution.

I don’t get the struggle with types people have. It’s not hard to use a knife instead of a hammer to cut stuff. What’s the struggle with types, specifically?

Try teaching c++ to a new programmer and you’ll understand the struggles people have with types.

You might have forgotten, but you had head scratchers too when you where learning. Everyone has them. I’ve taught people who are absolute geniuses, even they struggled initially. And sure you get over it, just like people can become quite adapt at programming in esoteric languages like brainfuck, but that doesn’t mean there aren’t any better ways.

Re: Making Python fast – Adventures with mypyc

#86

Post by isitmadeofglass »

jmt_ wrote: post #80
isitmadeofglass wrote: post #79

Earlier quoted context omitted.

No, its better. You can build the code first, test that it functions as expected, then add types, then compile it. This is miles ahead of having to struggle with getting types correct in C++ before you even have anything resembling a workable solution.

I don't disagree but I wish Python had builtin support for runtime type checking. I've thought about switching to Go or Rust for certain projects but Python's rich ecosystem makes it hard for me to switch, so for now I long for runtime type checking without needing an external library (e.g typeguard).

You can check types at runtime in python. You can even check values at runtime. Heck you can check the weather at runtime if you like. What’s the problem exactly?

Re: Making Python fast – Adventures with mypyc

#87

Post by chromatic »

zzzeek wrote: post #28
peterkelly wrote: post #11

Earlier quoted context omitted.

I'm well aware of V8 and pypy. I also really like Python as a language, especially with mypy. It just makes me sad that in a world with multiple high-performance JIT engines (including pypy, for Python itself), the standard Python version that most people use is an interpreter. I know it's largely due to compatibility reasons (C extensions being deeply intertwined with CPython's API). There is a really important (if…

> It just makes me sad that in a world with multiple high-performance JIT engines (including pypy, for Python itself), the standard Python version that most people use is an interpreter. I know it's largely due to compatibility reasons (C extensions being deeply intertwined with CPython's API). this is misleading, if one sees the phrase "interpreter" as that code is represented as syntax-derived trees or other datast…

someone correct me if I'm wrong but this would apply to well known interpreted languages like Perl 5

Perl uses the same execution method you describe for cPython.

Re: Making Python fast – Adventures with mypyc

#88

Post by [deleted] »

mixmastamyk wrote: post #84
chrisseaton wrote: post #78

Earlier quoted context omitted.

No, we know how to optimise all these issues. They're solved, through a combination of online profiling, inline caching, splitting, deoptimisation, scalar replacement, etc. (I wrote a PhD on it.) I don't think you could name a single Python language feature that we don't know how to optimise efficiently. (I'd be interested if you could.) But implementing them all is a difficult engineering challenge, even for Google,…

Yes, that’s what my reply means, your “no…” is poor communication style. If you think you can do better than the folks working on it for a decade plus, by all means step up.

[deleted]

Re: Making Python fast – Adventures with mypyc

#89

Post by chrisseaton »

mixmastamyk wrote: post #84
chrisseaton wrote: post #78

Earlier quoted context omitted.

No, we know how to optimise all these issues. They're solved, through a combination of online profiling, inline caching, splitting, deoptimisation, scalar replacement, etc. (I wrote a PhD on it.) I don't think you could name a single Python language feature that we don't know how to optimise efficiently. (I'd be interested if you could.) But implementing them all is a difficult engineering challenge, even for Google,…

Yes, that’s what my reply means, your “no…” is poor communication style. If you think you can do better than the folks working on it for a decade plus, by all means step up.

But you can't actually give any examples? Ok.

I'll give you one you could have used - the GIL - however I'm not sure the GIL's semantics are really specified for Python, they're an implementation detail people accidentally have relied on.

Re: Making Python fast – Adventures with mypyc

#90

Post by peterashford »

aprdm wrote: post #82
jmt_ wrote: post #80

Earlier quoted context omitted.

I don't disagree but I wish Python had builtin support for runtime type checking. I've thought about switching to Go or Rust for certain projects but Python's rich ecosystem makes it hard for me to switch, so for now I long for runtime type checking without needing an external library (e.g typeguard).

You can configure vscode to fail on typing problems and it will show errors in your editor

So that's an IDE feature rather than a language level feature
Post reply on HN