Not sure what point this is making. It's not pure Python, and even the bulk of it is just testing the performance of built-in data structures. Can't use Cython but it's OK to use uvloop? Want to prove you don't need C but use hiredis to parse?
This was a quite common criticism over r/Python[0] as well, saying that using C modules and then benchmarking "Python" with C isn't fair.
Perhaps it was my wording that caused this confusion, for which I am sorry, but I never meant to compare "pure" Python with C. The point I am trying to make is that, Python with C extensions can be as considerably[1] performant as C code for network or memory bound tasks.
I think you have a point, but it's not a terribly surprising one to most people here. This is pretty much the same thing people had already realized with Node.js, after all. I'll even go as far as to say the use of uvloop is fair, it's a reasonably generic piece of software that applies to a wide range of problems. It fits the Node.js comparison well, too.
But personally, I don't see how the usage of hiredis is so much different from literally taking a part of Redis itself and embedding it in Python. As a thought experiment, if I did take Redis's parsing code and embed it in Python, would it still be fair?
I'm not really convinced that a pure Python implementation of the Redis Serialization Protocol would actually be meaningfully slower than the Python bindings to hiredis, so this whole thing may be a bit moot.
I think your project is cool. Perhaps some changes to the README to explain exactly what your benchmarks are meant to show about Python itself would help the criticism.
> I think your project is cool. Perhaps some changes to the README to explain exactly what your benchmarks are meant to show about Python itself would help the criticism.
I agree. I'll edit when I have some time this week. =)
Well, hiredis and uvloop already exist and are well tested, so anybody can easily use them with normal Python. Rewriting things in Cython isn't something many Python users would be doing routinely.
Fine, but then I don't see what this program is proving about Python performance, other than that it's actually bad and even basic programs will need to use high performance libraries that are not pure Python. This is in contrast to say, languages like Go or Rust, where most of the time shelling out to C is an issue of ecosystem maturity.
> Unfortunately many programmers, due to their lack of experience, of some knowledge of computer architecture(s), or of an in-depth understanding of the task they are given
Where you fail to see that C libs being linked into python code is the same as python code performance
I think the most bizarre part of that paragraph is the note about dropping type safety for performance. I mean... Python is very much not type safe. Memory safe perhaps, though that argument is out the window if you are willing to accept arbitrary C extensions. All in all... It seems either I'm missing the point, or the author is.
It's strongly typed and mypy adds static typing support too (so you end up with a strong gradually typed language). Would you consider it insufficient?
Sure, it's strongly typed, but I think that's irrelevant, at least if my understanding of the term 'type safe' is correct. From Wikipedia:
>In computer science, type safety is the extent to which a programming language discourages or prevents type errors.
The thing is, a Python program that causes a type error is valid, even if it crashes. TypeError is strictly a runtime error. To me, that is the epitome of not having type safety.
Of course pretty much everything is runtime in Python, by virtue of it being a script language. So you really would need a type checking stage, like TypeScript. But...
>mypy adds static typing support too
In my opinion, MyPy is not sufficient to represent common usages of Python's type system. Even with the recent addition of structural typing, many Python programs just do things that are not easily typed. An example would be, in Django, many things in the core directly patch the Request object, and there's really not a terribly sane way to represent this in a reasonable type system. I feel Python encourages all kinds of type craziness, with metaclasses, 'file-like' objects, etc.
Opinions aside... Since MyPy is not part of Python itself (yet?) it is unfair to call the Python language 'type safe' simply by virtue of a type checker existing, for the same reason one wouldn't call JavaScript type safe (I do acknowledge that both of them definitely have a chance of becoming 'official', but neither have yet, and that's the important part.)
