3 ms·

It's great software for the use case that Python is intended for. Python is supposed to be glue code. You embed a scripting runtime in your application, do al

It's great software for the use case that Python is intended for. Python is supposed to be glue code. You embed a scripting runtime in your application, do all the heavy lifting in C, but configure your building blocks in Python so that you can easily reconfigure them as needs change. NumPy, SciPy, TensorFlow, PyTorch, JAX, Pandas, Pillow, lxml, cjson, PyCapnP, Tornado, fast-avro, etc. all get it right. They are wrappers around C (or in some cases: Fortran/assembly/CUDA) code, where the overflow of Python method dispatch is dwarfed by the hundreds of thousands of iterations of an inner loop that's in optimized, vectorized assembly. Django, Protobufs, and Avro get it wrong (often for portability or developer velocity sake), where they wrote the whole library in Python at the expense of performance. I was briefly tempted to write an API-compatible reimplementation of Django with the core in C++ when I left Google, but by then Django (and server-side web programming) was already falling out of favor, and if you're just shipping JSON to a SPA you can use cjson with any number of fast wsgi or asgi gateways.

bb88 3y ago
I've been playing around with HTMX with Django, and it seems simple enough for server side rendering. It works well with the Django templating system. I feel like as an industry we should step back and take a serious look at front end frameworks from first principles. One aspect that's clear to me, is that we should make modifications to HTML to support HTMX like transactions.
oivey 3y ago
Arguably no one’s goal is to glue pieces of C together. That’s too abstract. Their goal is to do something like write a performant web server, maybe easily and quickly. Python’s approach is one way to do that, but there are other ways that might be better. Having to write code in two languages to solve a problem, one of which that is difficult to write and has lots of footguns, has some clear downsides.
- nerdponx 3y ago
  Ritchie and Thompson might disagree with you.
- eesmith 3y ago
  Gluing pieces of C together was literally the reason I started using Python back in the 1990s. My other two main options were Tcl and Perl. Tcl was excellent at gluing, but worse at scaling, with no namespaces (then) and OO only as third-party add-ons. Perl extensions were not so easy (better with Perl 5), and much as I enjoyed the language, handling complex data structures, was not for the faint-hearted. Gluing pieces of C together is why we have NumPy, PyQt, pywin32, wxPython, and tens of thousands of other packages that work with C/C++/Fortran libraries.
- nostrademons 3y ago
  Basically nobody's goal is to "write a performant web server" either, it's to serve data to customers quickly and efficiently. And that highlights why it may not be worth optimizing the Python web ecosystem. There are so many newer alternatives for that overall goal - Firebase, Amazon Lambda, ditching webapps for native mobile, etc - that it may not make sense to try to optimize an application server unless you work for Google or Amazon, because very few people setup a standalone webserver on bare-metal hardware anymore, and those that do probably aren't going to try a new and untested alternative.
  - kazinator 3y ago
    Nobody's goal is to serve data to customers quickly and efficiently either. It's more like, get this startup acquired and buy a ranch in New Zealand.
    - SilasX 3y ago
      Haha you might like this old comment I made where I gradually go up the abstraction ladder about what you "really care" about (in the unlikely event you see this comment): https://news.ycombinator.com/item?id=9777816 https://news.ycombinator.com/item?id=9777816 Root of the subthread: https://news.ycombinator.com/item?id=9775799 https://news.ycombinator.com/item?id=9775799
- deleted 3y ago
  [deleted]
kazinator 3y ago
> for the use case that Python is intended for Where is this single use case intent articulated, by whom, and what year was it? What is the use case? Today, it seems that Python is pitched for almost everything, short of ethernet drivers.
- MR4D 3y ago
  From https://www.python.org/about/ https://www.python.org/about/ (mouse over the "About" menu) : 'Python is a programming language that lets you work more quickly and integrate your systems more effectively.'
  - spookie 3y ago
    This is one of the biggest misunderstandings in computing for the last decade, I feel.
  - kazinator 3y ago
    That's not a specific use case. That's like brochure pitch.
- jasode 3y ago
  >Today, it seems that Python is pitched for almost everything, short of ethernet drivers. I think the "Python is pitched for almost everything" in that sentence shows a misinterpretation of gp's phrasing of "use case". The "use case" isn't about different subject matter domains as if it was a claim about using Python as a universal language for writing database kernels or AAA games. Instead, the "use case" is about the 2-level 2-language architecture of (1) a high-level scripting language and (2) extension modules that can be written in low-level C and imported into the interpreter. That's the "glue language" + "C Language" to combine the strengths of each language approach. (In contrast, Julia took approach of designing a language that was "fast enough" to avoid the "2 languages issue".) >Where is this single use case intent articulated, by whom, and what year was it? What is the use case? The Python "ergonomics use case" (not "domains use case") was originated by Python's inventor Guido van Rossum from the beginning in 1991. A clone of the 1991 Python source code has Guido's commentary for importing C modules: https://github.com/smontanaro/python-0.9.1 https://github.com/smontanaro/python-0.9.1 Modern frameworks and libraries like TensorFlow and Pytorch continue the same use case of "high-level script glue code calling low-level C code" that was there in 1991. You can't write a tight cpu loop in pure Python code to paint a 60fps video game. That's not Python's intended use case. That philosophy is why a library like Tensorflow only has Python code for users to "glue" together the neural network graph which then calls out to the C++ code for the expensive cpu loops of backpropagation, gradient descent, etc.
tesdinger 3y ago
> I was briefly tempted to write an API-compatible reimplementation of Django with the core in C++ when I left Google, but by then Django (and server-side web programming) was already falling out of favor, and if you're just shipping JSON to a SPA you can use cjson with any number of fast wsgi or asgi gateways. I like Django. I need to process data on the server side and like to write that in python because it is more convenient than C. I also built my GUI in Django without knowing JavaScript. "just shipping JSON" seems like a different use case. I have a piece of hardware (a laboratory hardware switch) that exposes a REST API for CRUD. I wanted to build a GUI that formats and summarizes information and offers convenient control. The data is small enough so that python can process it without becoming the bottleneck. I used Django ORM to model the data and django forms with htmx for the GUI. Authentication was easily added to Django. The ORM part was a bit painful as Django forms expect a queryset and a queryset is not be the result of a raw sql query. There is a way to feed list of tuples into a choices argument but I decided against that , and instead dumbed down my query so I was able to write it as an django ORM language query.
- tesdinger 3y ago
  This is the problem with SQL queries and Django Forms I am talking about https://stackoverflow.com/questions/17330158/django-how-to-use-django-forms-modelchoicefield-with-a-raw-sql-query#17331671 https://stackoverflow.com/questions/17330158/django-how-to-u...

bb88 3y ago

I've been playing around with HTMX with Django, and it seems simple enough for server side rendering. It works well with the Django templating system. I feel like as an industry we should step back and take a serious look at front end frameworks from first principles. One aspect that's clear to me, is that we should make modifications to HTML to support HTMX like transactions.

oivey 3y ago

Arguably no one’s goal is to glue pieces of C together. That’s too abstract. Their goal is to do something like write a performant web server, maybe easily and quickly. Python’s approach is one way to do that, but there are other ways that might be better. Having to write code in two languages to solve a problem, one of which that is difficult to write and has lots of footguns, has some clear downsides.

nerdponx 3y ago
Ritchie and Thompson might disagree with you.
eesmith 3y ago
Gluing pieces of C together was literally the reason I started using Python back in the 1990s. My other two main options were Tcl and Perl. Tcl was excellent at gluing, but worse at scaling, with no namespaces (then) and OO only as third-party add-ons. Perl extensions were not so easy (better with Perl 5), and much as I enjoyed the language, handling complex data structures, was not for the faint-hearted. Gluing pieces of C together is why we have NumPy, PyQt, pywin32, wxPython, and tens of thousands of other packages that work with C/C++/Fortran libraries.
nostrademons 3y ago
Basically nobody's goal is to "write a performant web server" either, it's to serve data to customers quickly and efficiently. And that highlights why it may not be worth optimizing the Python web ecosystem. There are so many newer alternatives for that overall goal - Firebase, Amazon Lambda, ditching webapps for native mobile, etc - that it may not make sense to try to optimize an application server unless you work for Google or Amazon, because very few people setup a standalone webserver on bare-metal hardware anymore, and those that do probably aren't going to try a new and untested alternative.
- kazinator 3y ago
  Nobody's goal is to serve data to customers quickly and efficiently either. It's more like, get this startup acquired and buy a ranch in New Zealand.
  - SilasX 3y ago
    Haha you might like this old comment I made where I gradually go up the abstraction ladder about what you "really care" about (in the unlikely event you see this comment): https://news.ycombinator.com/item?id=9777816 https://news.ycombinator.com/item?id=9777816 Root of the subthread: https://news.ycombinator.com/item?id=9775799 https://news.ycombinator.com/item?id=9775799
deleted 3y ago
[deleted]

kazinator 3y ago

> for the use case that Python is intended for Where is this single use case intent articulated, by whom, and what year was it? What is the use case? Today, it seems that Python is pitched for almost everything, short of ethernet drivers.

MR4D 3y ago
From https://www.python.org/about/ https://www.python.org/about/ (mouse over the "About" menu) : 'Python is a programming language that lets you work more quickly and integrate your systems more effectively.'
- spookie 3y ago
  This is one of the biggest misunderstandings in computing for the last decade, I feel.
- kazinator 3y ago
  That's not a specific use case. That's like brochure pitch.
jasode 3y ago
>Today, it seems that Python is pitched for almost everything, short of ethernet drivers. I think the "Python is pitched for almost everything" in that sentence shows a misinterpretation of gp's phrasing of "use case". The "use case" isn't about different subject matter domains as if it was a claim about using Python as a universal language for writing database kernels or AAA games. Instead, the "use case" is about the 2-level 2-language architecture of (1) a high-level scripting language and (2) extension modules that can be written in low-level C and imported into the interpreter. That's the "glue language" + "C Language" to combine the strengths of each language approach. (In contrast, Julia took approach of designing a language that was "fast enough" to avoid the "2 languages issue".) >Where is this single use case intent articulated, by whom, and what year was it? What is the use case? The Python "ergonomics use case" (not "domains use case") was originated by Python's inventor Guido van Rossum from the beginning in 1991. A clone of the 1991 Python source code has Guido's commentary for importing C modules: https://github.com/smontanaro/python-0.9.1 https://github.com/smontanaro/python-0.9.1 Modern frameworks and libraries like TensorFlow and Pytorch continue the same use case of "high-level script glue code calling low-level C code" that was there in 1991. You can't write a tight cpu loop in pure Python code to paint a 60fps video game. That's not Python's intended use case. That philosophy is why a library like Tensorflow only has Python code for users to "glue" together the neural network graph which then calls out to the C++ code for the expensive cpu loops of backpropagation, gradient descent, etc.

tesdinger 3y ago

> I was briefly tempted to write an API-compatible reimplementation of Django with the core in C++ when I left Google, but by then Django (and server-side web programming) was already falling out of favor, and if you're just shipping JSON to a SPA you can use cjson with any number of fast wsgi or asgi gateways. I like Django. I need to process data on the server side and like to write that in python because it is more convenient than C. I also built my GUI in Django without knowing JavaScript. "just shipping JSON" seems like a different use case. I have a piece of hardware (a laboratory hardware switch) that exposes a REST API for CRUD. I wanted to build a GUI that formats and summarizes information and offers convenient control. The data is small enough so that python can process it without becoming the bottleneck. I used Django ORM to model the data and django forms with htmx for the GUI. Authentication was easily added to Django. The ORM part was a bit painful as Django forms expect a queryset and a queryset is not be the result of a raw sql query. There is a way to feed list of tuples into a choices argument but I decided against that , and instead dumbed down my query so I was able to write it as an django ORM language query.

tesdinger 3y ago
This is the problem with SQL queries and Django Forms I am talking about https://stackoverflow.com/questions/17330158/django-how-to-use-django-forms-modelchoicefield-with-a-raw-sql-query#17331671 https://stackoverflow.com/questions/17330158/django-how-to-u...