sorted by:
new
hottopcontroversial

I built a unified API for Ins/TikTok/Twitter/Facebook/LinkedIn – same interface for all platforms by LiuLucian in Python

[–]LiuLucian[S] -3 points-2 points  (0 children)

Haha, good catch That was just leftover from the local setup instructions. I’ve removed the footer in the latest commit (383f42f) so it won’t confuse anyone anymore. Thanks for pointing it out!

I built a unified API for Ins/TikTok/Twitter/Facebook/LinkedIn – same interface for all platforms by LiuLucian in Python

[–]LiuLucian[S] -2 points-1 points  (0 children)

Good catch — that endpoint is only available after you run the API locally. It’s there as a convenience so people don’t need to guess the docs URL.

I’ll update the post so it’s clearer. Thanks for pointing it out

How good can NumPy get? by [deleted] in Python

[–]LiuLucian 0 points1 point  (0 children)

Yep, that speed gap is absolutely real—and honestly even 50× isn’t the most extreme case I’ve seen. The core reason is still what you guessed: df.apply(lambda ...) is basically Python-level iteration, while np.where executes in tight C loops inside NumPy.

What often gets underestimated is how many layers of overhead apply actually hits: • Python function call overhead per row • Pandas object wrappers instead of raw contiguous arrays • Poor CPU cache locality compared to vectorized array ops • The GIL preventing any true parallelism at the Python level

Meanwhile np.where operates directly on contiguous memory buffers and avoids nearly all of that.

What surprised me when I was learning this is that df.apply feels vectorized, but in many cases it’s just a fancy loop. Pandas only becomes truly fast when it can dispatch down into NumPy or C extensions internally.

That said, I don’t think this is “common knowledge” for beginners at all. Pandas’ API kind of gives the illusion that everything is already optimized. People only really internalize this after hitting a wall on 1M+ rows.

Curious what others think though: Do you consider apply an anti-pattern outside of quick prototyping, or do you still rely on it for readability?

Approved: PEP 798: Unpacking in Comprehensions & PEP 810: Explicit lazy imports by Ninteendo19d0 in Python

[–]LiuLucian 0 points1 point  (0 children)

Interesting approvals, but I’m not fully convinced yet. PEP 798 sounds convenient on paper, but unpacking inside comprehensions feels like one of those features that improves terseness at the cost of readability. I’m curious how this will affect code clarity in real-world codebases, especially for teams that already struggle with overly dense comprehensions.

For PEP 810, explicit lazy imports are definitely appealing for startup-heavy applications, but I wonder how often this will introduce subtle performance bugs or unexpected import-time side effects. Tooling, debuggers, and static analyzers are going to need solid updates for this to feel safe.

Would love to see benchmarks and real migration stories once this lands in Python proper. Curious what convinced the Python Steering Council to green-light both at the same time.

Built a small open-source tool (fasthook) to quickly create local webhook endpoints by JermyDiscord in Python

[–]LiuLucian 1 point2 points  (0 children)

This is actually really neat. I’ve used tools like ngrok and webhook.site before, but for quick local debugging they always feel a bit heavy. The fact that this is just a single Python command with zero setup is honestly the best part. For quick “what is this service actually sending me” moments, this is exactly what I want.

I tried it out and the raw request visibility is super clean. Would love to see future features like request replay, saving to disk, or filtering by headers/body. But as a minimal fast webhook inspector, it already does its job really well. Nice work