Earlier quoted context omitted.
The secret is stop using frameworks and use just libraries (even the latter with parsimony)
What libraries do you use for python webapps, at least for url routing, etc?
Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
121–130 of 192 posts
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#122Yet another "X faster than Y" where inside X all hot jobs are done by really good-tuned C or C++. Facepalm. Without real problem-solving (business logic) written in Python, this is only lightweight wrapper on C/C++. When the number of Python code start growing in the hot path, then these blazing-amazing thruput numbers tremendously will be going down.
I'm so happy this is (currently) the top comment and people are starting to realize measuring perf with these well tuned micro-benchmarks is a sham.
Real world benchmarks take more time to prepare, we get that, but let’s be honest: a bold claim _needs_ bold evidence.
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#123Earlier quoted context omitted.
For all practical purposes, a programming language is defined by it's general real world implementation, and not it's specification. Maybe not so much for computer scientists, but for programmers, Python is interpreted with some JIT alternatives and C++ is compiled.
I literally posted the links to the AOT Python compiler and to the C++ interpreter.
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#124Earlier quoted context omitted.
For all practical purposes, a programming language is defined by it's general real world implementation, and not it's specification. Maybe not so much for computer scientists, but for programmers, Python is interpreted with some JIT alternatives and C++ is compiled.
I literally posted the links to the AOT Python compiler and to the C++ interpreter.
> general real world implementation
By this they mean the real-world-implementation that is in general use, which in this case is interpreted.
Yes, Python can be compiled and C++ can be interpreted. 99% of the time, they're not though.
When somebody says X language is interpreted, they mean that the most common and widely implementation is an interpreter. That's a useful bit of information to know about a language. "Correcting" them and saying that all languages can be interpreted OR compiled, doesn't really add anything of value to the discussion, other than to label yourself as a pedant.
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#125This is a python wrapper around libuv not a pure python solution (not that it’s bad but it explains the click bait title).
I don't understand this this logic.
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#126Yet another "X faster than Y" where inside X all hot jobs are done by really good-tuned C or C++. Facepalm. Without real problem-solving (business logic) written in Python, this is only lightweight wrapper on C/C++. When the number of Python code start growing in the hot path, then these blazing-amazing thruput numbers tremendously will be going down.
But I also think that writing Python and then dropping down into C or C++ for performance is perfectly valid and often a great idea. Of course, there's nothing wrong with just using a different language that's a sensible middle ground between Python and C (like Go). But hold on to the baby when that bathwater is being dumped: there's nothing wrong with writing a blend of Python and C++ for real uses.
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#127Earlier quoted context omitted.
> Making a new implementation is a practical purpose. Not yet it isn't. At least not for Python. I mean there are plenty of alternative implementations of Python but they aren't practical because they don't work with CPython modules (as far as I know anyway) so approximately nobody uses them. The de facto spec is "what CPython does".
PyPy work well with CPython modules but the performance is not that great, with CFFI performance is really good in PyPY, HPy project will change this https://hpyproject.org/
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#128Earlier quoted context omitted.
https://discord.socketify.dev/
Sorry for all the hate you seem to be recieving, I think it looks great! I can't join the discord however since I was banned for unknown reasons and cannot create a new account without giving them my phone number, which I refuse to do. But remember many great things get hated upon in the beginning, take dropbox as an example. People on HN thought it was a shitty idea and they seem to be doing just fine :)
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#129Good point! However, you bring in a common misconception I'm fighting with within my company for a long time. Python is not an interpreted language. There is no such thing as an "interpreted language", a language is just a set or rules and keywords. Everything you can fit into Backus–Naur form is already a language even if it doesn't have any implementation nor compiler neither interpreter. Just as a piece of evidenc…
My advice to you: Stop fighting that "misconception". See the other responses to back up the idea that Python is interpreted. The existence of a Python compiler is also not relevant here, as the linked project does not list that as a supported Python variant.
Let's assume that by some technicality you are not wrong. The "misconception" is so common that it is generally a fact in peoples mind. Rather than convince them, you are destroying your own credibility and probably making a fool of yourself in their eyes. And remember, I prefaced this with you not being wrong. It's worse for you if you are wrong. Just stop for your own good.
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#130Earlier quoted context omitted.
> Making a new implementation is a practical purpose. Not yet it isn't. At least not for Python. I mean there are plenty of alternative implementations of Python but they aren't practical because they don't work with CPython modules (as far as I know anyway) so approximately nobody uses them. The de facto spec is "what CPython does".
PyPy work well with CPython modules but the performance is not that great, with CFFI performance is really good in PyPY, HPy project will change this https://hpyproject.org/