Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • must admit that my first association was with the drum and bass band
    by Philpax
  • "In the face of ambiguity, refuse the temptation to guess."
    by david2ndaccount
  • I’ve been looking forward to whenever 1.0 for a few years now. Looks like it’s actually close now!
    by reagle
  • I can't provide any code samples, but this only strikes me as medium-cursed as far as python code goes. That stuff can get nasty! Once a team realizes they can modify anything at runtime things can go bad quite quickly.

    Nice hack for maintaining old behavior tho!

    by aeturnum
  • I'll one up this with my hack that changes the value of `sys.platform` based on the caller: https://github.com/jvolkman/rules_pycross/blob/main/pycross/...

    This is used when cross compiling binary wheels (e.g., building a macos wheel on a linux build host or vice versa).

    by jvolkman
  • OMGeeeee!

    I too have plumbed the call stack for hidden-maybe-forbidden knowledge from the caller, and it is always fraught. No matter how good one's intentions. Forget dynamic type testing. Forget Perl's `wantarray` dynamic introspection of "what does the caller want?" Those are small potatoes. This is full on "who's calling me and what do I want to send back as a result?" The people who will never forgive you for type testing are going to straight-up excommunicate whoever wrote this! And yet...it makes complete sense. Based on the promises made, you have to do something... and you're already in "what is the least of the evils?" territory, because you're going to have to do something that someone—maybe a lot of someones—will call evil.

    My admiration for Pendulum just increased. This is sin-eating.

    by jonathaneunice
  • Mmm. Changing control flow based on introspection of the call stack is reasonably nasty.

    I recall we found a neat use for call stack introspection in one project - not to change control flow but to improve logging. Inside an open_db_connection utility function, to auto-generate an informational name describing which part of the codebase had opened the connection:

    E.g. some_backend_process: main -> ... > grandparent -> parent -> open_db_connection

    We'd use information from the call stack generate a string "some_backend_process grandparent.parent" describing the call site which could be passed to postgres as the application_name [1] when establishing a connection. Then from the database side, if we had problematic queries at runtime, we had a lot more clues to figure out which part of the backend codebase was responsible [2].

    There'd be a way to do something equivalent without peeking at the call stack, by requiring the caller to explicitly pass a descriptive & unique name, but that makes things a bit more error-prone, especially since some devs would be prone to copy-pasting chunks of existing code & reusing the same name everywhere.

    [1] https://www.postgresql.org/docs/current/libpq-connect.html#L... [2] https://www.postgresql.org/docs/current/monitoring-stats.htm...

    by shoo
  • Author here. I ran into this while comparing Pendulum with `whenever`, the datetime library I maintain. I sent a patch that removes the hack, but the post is about why the underlying design can't be patched the same way. Happy to answer questions.
    by ariebovenberg

Explore Birbla archives