4 ms·

The problem is not so much that python is slow. It's that in some scenarios python can't be made fast. Fast prototyping is great but being stuck with a prototy

The problem is not so much that python is slow. It's that in some scenarios python can't be made fast. Fast prototyping is great but being stuck with a prototype for deployment isn't.

ColinWright 9y ago
Did you read the section on "Optimizing Python" ?? If so, I'm assuming you read about using CPython to migrate your package/program/module painlessly to C. So given that, can you elaborate on your objection? I'd like to know why you think the article is wrong about optimising your Python to make it fast enough.
- VHRanger 9y ago
  "migrate your package/program/module painlessly to C" Do you or anyone on your python using team can use C professionally for things you'll use in production? I work with python everyday on a team that uses python everyday, and I worked professionally in C++ for a >2 years time, and I still wouldn't trust myself to write a reliable/safe C backend to something. And using C++ behind python with something like pybind11 is anything but painless on the other end; it requires careful consideration. Python is "good enough" in nearly all cases, but there are some instances where you sort of hate yourself for using it for the prototype since you're forced to effectively rewrite afterwards.
  - traverseda 9y ago
    You should try python-cffi. Using python code as a shared library under C is pretty easy, and calling C from python is pretty easy. The documentation is a bit crappy, but it's alright once you get the hang of it. I recently used it to prototype a shared library that overrides the `getenv` syscall, with the intent of providing decrypt-on-use environment variables. It's pretty simple, stolen from lua I believe. https://cffi.readthedocs.io/en/latest/overview.html#embedding https://cffi.readthedocs.io/en/latest/overview.html#embeddin...
auserperson 9y ago
In pure Python that is true, but the article discuss this issue.
traverseda 9y ago
>It's that in some scenarios python can't be made fast. Can you give some examples of this? I mean, obviously with enough effort you can "make python fast" since it has good C bindings, and can just be a thin wrapper around fast stuff. Similar to how command line tools can be ridiculously fast[^1] despite, ostensibly, running in bash. So I'm a bit confused about what you're claiming. Organizational issues, it's difficult to get management on board with an optimization pass? [^1]: https://aadrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html https://aadrake.com/command-line-tools-can-be-235x-faster-th...
- deleted 9y ago
  [deleted]
- VHRanger 9y ago
  My point is do you have competent C programmers on your team? That said, there is a point in some python prototypes where you "hit the performance wall". For whatever reason, you'll need to look at one of the options to make python faster and none of them are painless unless you're already a serious C programmer.
kerkeslager 9y ago
In ten years of Python development I have yet to come across an instance where Python couldn't be made fast. In some cases critical sections had to be delegated to C but even that is very rare.
fnord123 9y ago
One of the best features of Python is the almost free FFI into C. This means you can prototype and then dial up the performance to 11 if required.

The problem is not so much that python is slow. It's that in some scenarios python can't be made fast. Fast prototyping is great but being stuck with a prototype for deployment isn't.

ColinWright 9y ago

Did you read the section on "Optimizing Python" ?? If so, I'm assuming you read about using CPython to migrate your package/program/module painlessly to C. So given that, can you elaborate on your objection? I'd like to know why you think the article is wrong about optimising your Python to make it fast enough.

VHRanger 9y ago
"migrate your package/program/module painlessly to C" Do you or anyone on your python using team can use C professionally for things you'll use in production? I work with python everyday on a team that uses python everyday, and I worked professionally in C++ for a >2 years time, and I still wouldn't trust myself to write a reliable/safe C backend to something. And using C++ behind python with something like pybind11 is anything but painless on the other end; it requires careful consideration. Python is "good enough" in nearly all cases, but there are some instances where you sort of hate yourself for using it for the prototype since you're forced to effectively rewrite afterwards.
- traverseda 9y ago
  You should try python-cffi. Using python code as a shared library under C is pretty easy, and calling C from python is pretty easy. The documentation is a bit crappy, but it's alright once you get the hang of it. I recently used it to prototype a shared library that overrides the `getenv` syscall, with the intent of providing decrypt-on-use environment variables. It's pretty simple, stolen from lua I believe. https://cffi.readthedocs.io/en/latest/overview.html#embedding https://cffi.readthedocs.io/en/latest/overview.html#embeddin...

auserperson 9y ago

In pure Python that is true, but the article discuss this issue.

traverseda 9y ago

>It's that in some scenarios python can't be made fast. Can you give some examples of this? I mean, obviously with enough effort you can "make python fast" since it has good C bindings, and can just be a thin wrapper around fast stuff. Similar to how command line tools can be ridiculously fast[^1] despite, ostensibly, running in bash. So I'm a bit confused about what you're claiming. Organizational issues, it's difficult to get management on board with an optimization pass? [^1]: https://aadrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html https://aadrake.com/command-line-tools-can-be-235x-faster-th...

deleted 9y ago
[deleted]
VHRanger 9y ago
My point is do you have competent C programmers on your team? That said, there is a point in some python prototypes where you "hit the performance wall". For whatever reason, you'll need to look at one of the options to make python faster and none of them are painless unless you're already a serious C programmer.

kerkeslager 9y ago

In ten years of Python development I have yet to come across an instance where Python couldn't be made fast. In some cases critical sections had to be delegated to C but even that is very rare.

fnord123 9y ago

One of the best features of Python is the almost free FFI into C. This means you can prototype and then dial up the performance to 11 if required.