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

51–60 of 67 posts

Re: Python finally offloads some batteries

#51

Post by zaidw »

willcipriano wrote: post #19
999900000999 wrote: post #9

What's the exact motivation for this. Just ask for more money, no reason Dropbox or Amazon can't pay for development. I'm worried this is going to break some use cases, not everyone has network access to install random pip packages

> not everyone has network access to install random pip packages Lucky that the lack of network access will prevent these new versions of Python just as well.

Airgap install of Python is quite straightforward. I normally scp the Python source and altinstall on target server.

But airgap install of pip packages with myriad dependencies can be annoying.

So I agree with parent comment that having standard packages make things easier

Re: Python finally offloads some batteries

#52

Post by zitterbewegung »

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…

The best way to talk about this is to make a PEP about it.

Re: Python finally offloads some batteries

#53

Post by tyingq »

djbeadle wrote: post #34
Noumenon72 wrote: post #33

What are you supposed to use instead of urllib? Seems like an oversight to write all about how you considered removing it without saying whether there is a replacement.

From the proposal to remove urllib linked in the article: https://lwn.net/ml/python-dev/CABqyc3wGDmdnDjrhYh0SxT_Tgr5M8... From: Victor Stinner To: Python Dev Subject: [Python-Dev] It's now time to deprecate the stdlib urllib module Date: Sun, 06 Feb 2022 15:08:40 +0100 Message-ID: Hi, I propose to deprecate the urllib module in Python 3.11. It would emit a DeprecationWarning which warn users, so users should consider…

Those don't come with python though, so the standard library wouldn't have any similar functionality. And both of the suggestions have a direct dependency on urllib.

Edit: So who maintains urllib, a dependency for the "better" libraries, if you push it out of python core?

Re: Python finally offloads some batteries

#54

Post by gxt »

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.

Resurected

Re: Python finally offloads some batteries

#56

Post by DangitBobby »

tyingq wrote: post #53
djbeadle wrote: post #34

Earlier quoted context omitted.

From the proposal to remove urllib linked in the article: https://lwn.net/ml/python-dev/CABqyc3wGDmdnDjrhYh0SxT_Tgr5M8... From: Victor Stinner To: Python Dev Subject: [Python-Dev] It's now time to deprecate the stdlib urllib module Date: Sun, 06 Feb 2022 15:08:40 +0100 Message-ID: Hi, I propose to deprecate the urllib module in Python 3.11. It would emit a DeprecationWarning which warn users, so users should consider…

Those don't come with python though, so the standard library wouldn't have any similar functionality. And both of the suggestions have a direct dependency on urllib. Edit: So who maintains urllib, a dependency for the "better" libraries, if you push it out of python core?

Yep. They kind of hint at the end that the real solution is to actually fix urllib. Removing it is a mistake IMO, even if it's for "security reasons" but especially if it's for a bad API. I'd rather it be included and kind of broken than removed.

Re: Python finally offloads some batteries

#57

Post by throwaway81523 »

postpawl wrote: post #39
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 "…

Interesting, I’ve never seen the cgi module used before. It’s good to know it exists. Here’s an example for those interested: https://dzone.com/articles/python-simple-http-server-with-cg...

Yep, if you want to throw a ghetto GUI onto your python script, easiest way is to run CGIHTTPServer (now renamed in py3), write some 1990's style basic HTML, and point a browser at it. Use for customer facing sites? No. But for your internal status checking script or personal photo tagger, it's low fuss, low dependencies, and completely practical.

Re: Python finally offloads some batteries

#58

Post by jwilk »

akvadrako wrote: post #48
jwilk wrote: post #47

Earlier quoted context omitted.

Link to the bug?

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...

Re: Python finally offloads some batteries

#59

Post by samhw »

lmm wrote: post #31
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…

A large "standard platform" may be a good thing, but it should definitely be decoupled from the language proper. (And personally I would say Javascript is doing it better than most languages on the library management front).

Eh, it's hard to talk about JavaScript because of all the different layers. My personal take is: JavaScript itself (ECMAScript) is an ugly and flawed but clearly generally productive language; Node is a work of art; NPM is horrendous with near-to-no redeeming qualities. TypeScript redeems lots of the problems with JavaScript, and I'm hopeful that Deno will ameliorate a lot of the problems with NPM (Yarn is good for what it is, but barely covers 3% of the necessary changes).

Also, an honorary mention for ESBuild (and the lesser-known SWC, extremely similarly optimal but eking out a small win due to Rust's advantages over Go). Both of them are terrific improvements over the extant tooling.

Re: Python finally offloads some batteries

#60

Post by sciurus »

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?
Post reply on HN