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

Python finally offloads some batteries

lwn.net

Post reply on HN
Print view View original

61–67 of 67 posts

Re: Python finally offloads some batteries

#61

Post by sciurus »

throwaway984393 wrote: post #32

Does anyone actually have normal users run Python programs? I thought programming was intended so that users could run your programs. But if a regular non-programming user wants to use a Python program, they need a whole tutorial on how to install and run it. Put everything in the standard library, or nothing at all, it doesn't really matter. Either way you still have to set up a custom environment and install a bunc…

> Does anyone actually have normal users run Python programs?

To give one example: Every Dropbox customer does, since their client is written in Python

Re: Python finally offloads some batteries

#63

Post by [deleted] »

jwilk wrote: post #58
akvadrako wrote: post #48

Earlier quoted context omitted.

https://bugs.python.org/issue17050 Apparently after 7 years they decided it can't be fixed and updated the docs.

I'm baffled with the resolution of this bug. Removing the docs doesn't help anybody. In my experience, argparse.REMAINDER works reasonably well, and apparently I'm not alone; there's >100 packages in Debian that use it: https://codesearch.debian.net/search?q=%5Cbargparse%5B.%5DRE...

[deleted]

Re: Python finally offloads some batteries

#64

Post by throwaway81523 »

sciurus wrote: post #60
throwaway81523 wrote: post #37

This is stupid. I use cgi all the time. My cheap Hetzner single core vps can fork a Linux process 10k times a second, so I don't want to hear about forking being too slow until Django can serve pages that fast. Cgi is still the simplest way to get a basic web script running, without worrying about lingering state between page hits, etc. Doesn't Linus always shut down such discussions regarding the Linux kernel with "…

It's not forking the process that's a concern, it's what happens next. How slow is Django to start up? Do you want to pay that penalty for every request?

Django as a cgi does sound painful, but that's because it's huge. Most cgi scripts I've written are quite simple. And they rarely have to serve 100s of requests per second. And of course it's possible to optimize the startup time, e.g. by dumping an already-initialized version of the script (even django). Emacs has done that forever. It wouldn't surprise me if there is some way to do it in Python.

I remember reading somewhere that amazon.com was originally implemented as CGI's written in C. And, Perl cgi scripts served the whole web for many years, on servers much slower than what we have now.

Re: Python finally offloads some batteries

#65

Post by mountainriver »

mcdermott wrote: post #62

The batteries are the strong part of Python. If you remove the batteries, then you can easily dump python for something else.

Not sure I agree with that. The strong parts of Python are that it is semantically simple and easy to pick up.

Removing some batteries just means a couple more pip installs

Re: Python finally offloads some batteries

#66

Post by Nasreddin_Hodja »

Dunedan wrote: post #50

Good, but let's talk about the other side of things: Features missing from Python's standard library. Here are some features I miss regularly and I believe should be part of the standard library: - support for modern compression algorithms (e.g. brotli, zstandard) - support for modern hashing algorithms (e.g. argon2, bcrypt) - support for parsing ISO 8601 date times with "Z" as timezone designator - a TTL-cache imple…

> Features missing from Python's standard library.

PHP's base_convert() equivalent.

Re: Python finally offloads some batteries

#67

Post by __del__ »

genmud wrote: post #35
__del__ wrote: post #27

Earlier quoted context omitted.

i mostly agree with those choices. colorsys: a small handful of conversion functions you need every now and then fileinput: quick and dirty boilerplate for when you want to accept input from files or stdin getopt: a fine, well understood command line parser optparse: it's a simpler more broken argparse that will eventually tell you "i'm sorry dave..." and people should stop using it wave: great way to create or proce…

I disagree that optparse is more broken than argparse. As someone who wanted to add some (trivial) features to argparse, I quickly backed away from that code [1]. To be honest, I was really surprised how needlessly complex that particular code is. [1] - https://github.com/python/cpython/blob/main/Lib/argparse.py

i suppose they are both broken, but i claim optparse is "more broken" because it lacks the nargs="+" and nargs="?" functionality, and doesn't support positional arguments.

it's also valid to suggest that a plate of spaghetti is better than a cauldron full (thus favoring optparse).

Post reply on HN