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

21–30 of 67 posts

Re: Python finally offloads some batteries

#21

Post by rtpg »

samhw wrote: post #16
rtpg wrote: post #14

Earlier quoted context omitted.

Honestly it's kinda disappointing that the CGI library would not be included in Python if proposed today. Why would wsgiref get included then? I get the arguments for a small standard library in theory, but given how absolutely nightmarish it is to deal with python requirements in a "will work every time" way, I don't know where we end up with the Python standard library in general. Not making a slippery slope argume…

This is an argument for good package management. There’s no way around it. You can’t add everything anyone could ever hypothetically need into the standard library, just because Pip is rubbish. (I mean, I don’t care. I use Rust. I’m just arguing on behalf of the poor people who are still abused by their employers, or wacky enough to voluntarily choose to use Python.)

I use Rust and Python, and I don't believe that Rust's strategies regarding standard libraries are great either. And let's not talk about Javascript "in order to use CSS with Webpack you need to download this 20 line package with its own release cycle"-style noncense.

I do believe that package management solutions are needed. But I also think that a big standard library is A Good Thing, especially in a universe where some random micro-package will just lose its maintainer and cause 100 knock-on effects.

Re: Python finally offloads some batteries

#22

Post by naniwaduni »

tines wrote: post #6
divbzero wrote: post #5

It’s interesting to see which modules were set for deprecation but ended up being un-deprecated (de-deprecated?): colorsys fileinput getopt optparse wave https://peps.python.org/pep-0594/#modules-to-keep Seems like the maintainers have been generous in deciding which batteries are not dead yet.

precated :)

comprecated?

Re: Python finally offloads some batteries

#23

Post by dragonwriter »

rtpg wrote: post #21
samhw wrote: post #16

Earlier quoted context omitted.

This is an argument for good package management. There’s no way around it. You can’t add everything anyone could ever hypothetically need into the standard library, just because Pip is rubbish. (I mean, I don’t care. I use Rust. I’m just arguing on behalf of the poor people who are still abused by their employers, or wacky enough to voluntarily choose to use Python.)

I use Rust and Python, and I don't believe that Rust's strategies regarding standard libraries are great either. And let's not talk about Javascript "in order to use CSS with Webpack you need to download this 20 line package with its own release cycle"-style noncense. I do believe that package management solutions are needed. But I also think that a big standard library is A Good Thing, especially in a universe where…

> But I also think that a big standard library is A Good Thing, especially in a universe where some random micro-package will just lose its maintainer and cause 100 knock-on effects.

Standard libraries have the same problems; in fact, part of the reason these are being removed from Python's stdlib is...they don't have maintainers.

Re: Python finally offloads some batteries

#24

Post by tyingq »

tyingq wrote: post #18
LeoPanthera wrote: post #7

What is the alternative to “cgi”?

There seems to be overlap with wsgiref, and that ships with Python. There's a CGIHandler class that can use stdin/stdout. Most of the examples show spinning up and listening to a port, but you can google around to find examples that work with just stdin/stdout.

Since there's no dead simple examples:

  #!/usr/bin/env python
  from wsgiref.handlers import CGIHandler

  def app(environ, start_response):
      start_response('200 OK', [('Content-Type', 'text/html')])
      return [
         b"foobar\n"
      ]

  if __name__ == '__main__':
      CGIHandler().run(app)

Re: Python finally offloads some batteries

#25

Post by rtpg »

dragonwriter wrote: post #23
rtpg wrote: post #21

Earlier quoted context omitted.

I use Rust and Python, and I don't believe that Rust's strategies regarding standard libraries are great either. And let's not talk about Javascript "in order to use CSS with Webpack you need to download this 20 line package with its own release cycle"-style noncense. I do believe that package management solutions are needed. But I also think that a big standard library is A Good Thing, especially in a universe where…

> But I also think that a big standard library is A Good Thing, especially in a universe where some random micro-package will just lose its maintainer and cause 100 knock-on effects. Standard libraries have the same problems; in fact, part of the reason these are being removed from Python's stdlib is...they don't have maintainers.

What I have had a lot of is that infra fixes (like "oh this is now a keyword in the latest Python release, there's a trivail fix") just ends up not happening and then your packages are all in limbo.

I understand not having maintainers for actual bug fixes of tricky things. But the "maintainer disappearing" scenario has almost always been just for keeping things running. And in particular people show up with patches! Just well... some arbitrary person was a maintainer, is no longer there, and now there are bunch of people who would love to do most of the work.

I think that "lack of succession strategies" is what really gets these packages, rather than the lack of willing maintainers. Combine that with deep dependency trees and you have a lot of stuff that needs to happen.

I get it though. And I maintain some packages but I don't get involved in standard library shenanigans cuz my imagination is there's a lot of friction there. Just I like that things will probably be there for a while if its in the standard library.

Re: Python finally offloads some batteries

#27

Post by __del__ »

divbzero wrote: post #5

It’s interesting to see which modules were set for deprecation but ended up being un-deprecated (de-deprecated?): colorsys fileinput getopt optparse wave https://peps.python.org/pep-0594/#modules-to-keep Seems like the maintainers have been generous in deciding which batteries are not dead yet.

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 process pcm audio data without a whole framework

Re: Python finally offloads some batteries

#28

Post by glouwbug »

em3rgent0rdr wrote: post #26

I was hoping this article was going to talk about Python reducing its high energy usage relative to energy-efficient languages like Rust and C/C++.

I often wonder how many businesses often need code to operate. Back in school we had a database design class where the prof asked us to design a system for a user base of 50 something users per year. We were all dumbfounded when our react/postgres/python stacks were overkill when the prof explained that pen and paper or excel would’ve sufficed

Re: Python finally offloads some batteries

#29

Post by denimnerd42 »

glouwbug wrote: post #28
em3rgent0rdr wrote: post #26

I was hoping this article was going to talk about Python reducing its high energy usage relative to energy-efficient languages like Rust and C/C++.

I often wonder how many businesses often need code to operate. Back in school we had a database design class where the prof asked us to design a system for a user base of 50 something users per year. We were all dumbfounded when our react/postgres/python stacks were overkill when the prof explained that pen and paper or excel would’ve sufficed

reminds me of an interview I had a couple days ago where the interviewers wanted me to design an app for a 50 person building. I suggested a monolithic server side web app that serves html with minimal JS and they were expecting load balancers, multiple az, microservices, react, sharded db. lmao
Post reply on HN