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

CLI tools hidden in the Python standard library

til.simonwillison.net

Post reply on HN
Print view View original

151–160 of 160 posts

Re: CLI tools hidden in the Python standard library

#151

Post by vamega »

bombolo wrote: post #136
Znafon wrote: post #66

Earlier quoted context omitted.

This is quite an oversimplification. Some modules have no active maintainers and take time from the small team that work on CPython. Some modules are deprecated and removed to make it possible to allocate time on other improvements, and they went back on some removals when users came forward showing that they were still needed. There is some discussion about the rationale at https://peps.python.org/pep-0594/#rational…

Did you read the latest news or not? They regret asyncio! (and many other core modules). They won't remove them… but they regret having made them. I think without, people would have just not used python.

Where was this news? I’d like to read this.

Re: CLI tools hidden in the Python standard library

#152

Post by HumblyTossed »

IshKebab wrote: post #135
HumblyTossed wrote: post #79

Earlier quoted context omitted.

Oh and the Rust brigade have arrived... Was only a matter of time.

How dare people mention tools written in Rust? It may be a fantastic, well loved language that's exploding in popularity and the source of endless very high quality CLI tools... but. The absolute cheek! We must only mention Python and Bash forevermore.

Every time there's a discussion about language X, Rusties jump in. Stop it.

One of the biggest turn offs about Rust is the community.

Re: CLI tools hidden in the Python standard library

#153

Post by cxr »

totallywrong wrote: post #141
cxr wrote: post #137

Earlier quoted context omitted.

Please don't derail discussions with zero-effort, low-substance nonsequitur oneliners like this.

Sorry you're right. But you are being pedantic. These are quick hacks that might come in handy a couple times per year, maybe. Bringing up security, alternative native tools, and even trying to find a formal definition for "most people" is, imo, missing the point.

Okay, so what is the point (in terms more specific than "quick hacks that might come in handy a couple times per year", and for whom, exactly)?

Re: CLI tools hidden in the Python standard library

#154

Post by arp242 »

bombolo wrote: post #140
oefrha wrote: post #80

Earlier quoted context omitted.

You're reading a ridiculous mischaracterization of reality (~20 deprecated modules [1] out of the ~300 PSL modules [2] is "most"?). Of course you find it odd. [1] https://peps.python.org/pep-0594/ [2] https://docs.python.org/3/library/

I was referring to this: https://pyfound.blogspot.com/2023/05/the-python-language-sum... Of course nobody even knew so the default response is to hit that bottom arrow :D

"Had possibly been added before it was fully baked" is not the same as "we should never have added anything like it", and neither is "we have a much better solution but no one uses that because asyncio is in stdlib which we're now stuck with, for better or worse".

Your entire reading of that is just wrong.

Re: CLI tools hidden in the Python standard library

#155

Post by IshKebab »

HumblyTossed wrote: post #152
IshKebab wrote: post #135

Earlier quoted context omitted.

How dare people mention tools written in Rust? It may be a fantastic, well loved language that's exploding in popularity and the source of endless very high quality CLI tools... but. The absolute cheek! We must only mention Python and Bash forevermore.

Every time there's a discussion about language X, Rusties jump in. Stop it. One of the biggest turn offs about Rust is the community.

He literally did not mention Rust.

Re: CLI tools hidden in the Python standard library

#156

Post by n8henrie »

burntsushi wrote: post #82
BoppreH wrote: post #22

Speaking of hidden Python tools, I'm a big fan of re.Scanner[0]. It's a regex-based tokenizer[1] in the `re` module, that for reasons is completely missing from any official documentation. You give it a pattern for each token type, and a function to be called on each match, and you get back a list of processed tokens. Importantly, it processes the list in one pass and ensures the matches are contiguous, where a naive…

You'll be able to do this soon with the Rust regex crate as well. Well, by using one of its dependencies. Once regex 1.9 is out, you'll be able to do this with regex-automata: use regex_automata::{ meta::Regex, util::iter::Searcher, Anchored, Input, }; #[derive(Clone, Copy, Debug)] enum Token { Integer, Identifier, Punctuation, } fn main() { let re = Regex::new_many(&[ r"[0-9]+", r"[a-z_]+", r"[,.]+", r"\s+", ]).unwr…

Interesting! Not often using either crate, this example looks like something for which I might usually look to nom. Is there a reason I should consider using regex for this use case instead (if neither is a pre-existing dependency)?

Re: CLI tools hidden in the Python standard library

#157

Post by HumblyTossed »

IshKebab wrote: post #155
HumblyTossed wrote: post #152

Earlier quoted context omitted.

Every time there's a discussion about language X, Rusties jump in. Stop it. One of the biggest turn offs about Rust is the community.

He literally did not mention Rust.

Implicitly, they did.

Re: CLI tools hidden in the Python standard library

#159

Post by mejutoco »

BiteCode_dev wrote: post #148
mejutoco wrote: post #147

Earlier quoted context omitted.

After triggering pdb by having "breakpoint()" in tour python code and dropping in the debugger you can type "interactive" in the console to enter multiline strings.

TIL again. Very good thread! It's "interact" though, not "ive". You can exit it to carry on with the regular pdb.

Thanks. I make that mistake every time I use it:)

Re: CLI tools hidden in the Python standard library

#160

Post by burntsushi »

n8henrie wrote: post #156
burntsushi wrote: post #82

Earlier quoted context omitted.

You'll be able to do this soon with the Rust regex crate as well. Well, by using one of its dependencies. Once regex 1.9 is out, you'll be able to do this with regex-automata: use regex_automata::{ meta::Regex, util::iter::Searcher, Anchored, Input, }; #[derive(Clone, Copy, Debug)] enum Token { Integer, Identifier, Punctuation, } fn main() { let re = Regex::new_many(&[ r"[0-9]+", r"[a-z_]+", r"[,.]+", r"\s+", ]).unwr…

Interesting! Not often using either crate, this example looks like something for which I might usually look to nom. Is there a reason I should consider using regex for this use case instead (if neither is a pre-existing dependency)?

I don't use nom. I've tried using parser combinator libraries in the past but generally don't like them.

That said, I don't usually use regexes for this either. Instead, I just do things by hand.

So I'm probably not the right person to answer your question unfortunately. I just know that more than one person has asked for this style of use case to be supported in the regex crate. :-)

Post reply on HN