Hacker News new | past | comments | ask | show | jobs | submit login
Fuckit.py – The Python error steamroller (github.com)
86 points by aburan28 on Aug 31, 2015 | hide | past | web | favorite | 46 comments

From the test suite:

def test_context_manager(): with fuckit: pass

    assert 'P' != 'NP' # proof is left as an excercise for the reader

From the implementation:

     except IOError:
         # Worst-case scenario we can only catch errors at a granularity
         # of the whole function.
         # If we have access to the source, we can silence errors on a
         # per-expression basis, which is "better".
and then:

    def __exit__(self, exc_type, exc_value, traceback):
        # Returning True prevents the error from propagating. Don't silence
        # KeyboardInterrupt or SystemExit. We aren't monsters.

I've been searching for something similar I saw years ago. It was a python library that would remove "heretical" code or something like that. Any error would be "eradicated".

It was funny! There was a religious or medieval theme or something. I can never find it...

Vigil, the eternal morally vigilant programming language:


This needs SCM support added too it. After all, what use is it if its grand moral vision can be reversed by a simple git checkout?

HN discussion, for your convenience: https://news.ycombinator.com/item?id=5002597

yes! thank you!

Works as advertised. I just added it to my project and now all tests are 100% passing! Even 1 == 0!

That took me a few seconds, well played.

"This module is like violence: if it doesn't work, you just need more of it."

How could anyone not love this tool?

It's the Serious Sam of Python programming ... moar bullets

s/module/XML/ is another favorite

In my previous life I was maintaining some backend services. One of the most common reasons for a service dying was a typo in a name in some rarely visited code path. I was tempted to write a similar module that would be a little bit smarter: when some identifier (variable, method, etc.) was not found, instead of raising an exception, try to find a similarly named thing and use that instead. I never did find a good way of implementing that.

I think you might like something like TheFuck? EDIT: This bash commandline completion has been updated to by default wait for the user to verify the replacement command is what they wanted; this pretty much turns this from a terminal Russian Roulette into a kinda handy autosuggestion!


(Previous discussion: https://news.ycombinator.com/item?id=9396116 )

That's probably for the best.

Seriously, that's asking for unpredictable behavior. Maybe if it printed the suggestion to the logs and then failed it would be ok.

Yes, it's crazy. I saw a Python library a while ago that when would pip install any missing module, even if it's because of a typo. Crazy.

I spilled tea because of laughter induced by your comment. well done.

How about better testing and path coverage of your code? I hope that was also explored as a way to stabilize your codebase? Otherwise your suggestion does come offa bit as 'cowboy-ish' to say the least ...

Ruby has a language feature for this and it's pure 100% poison.


That came from Smalltalk, where it was named doesNotUnderstand. It's always difficult to choose between crippling the language and encouraging stupidity.

that is neither what OP mentioned (automatic matching of a typo) nor poison.

Also, it's from Smalltalk, and found in some ways also in python, objective-c and many others.

Looks to be inspired by fuckit.js:


So if you want the same thing but for JS give the above a shot.

JS doesn't really need an extra library for that, does it?

There's also this for your text conversion needs.


Visual Basic has/had this and not as a joke. It was called "On Error Resume Next."

There's debate in that thread whether this project is satire or not. I must admit it looks remarkably like satire, especially the test suite.

That said, I have met some developers who would find this as an advantage and might actually try to put it into use. Generally these are folks who prefer the default soldier-on-in-the-face-of-errors behavior from sh and perl.

> Generally these are folks who prefer the default soldier-on-in-the-face-of-errors behavior from ... perl.

Nobody in the Perl world prefers that, outside of people who are complete newbies. In fact, collectively Perl has been yelling at newbies for decades that anything not containing `use strict;` and `use warnings;` is almost without fail broken code, mainly because there are a lot of very old and outdated tutorials which introduce these modules as optional and/or way too late.

> Nobody in the Perl world prefers that, outside of people who are complete newbies

I think these are actually old-bies. They don't opt-in to `use strict;` because they like it that way. I suppose they just have an astonishingly high pain threshold.

To be clear here: You can be a perl newbie even after you've been writing Perl for decades. I know this because i sometimes see code like that in companies that don't value their employee education, or heck, their employee. Period. You'll have a guy who's been writing Perl for 15 years and never got past the small 500 word tutorial he once read back then. He may be old and have the years, but he's still a newbie since he doesn't know shit.

That said, i've never met these people outside of said companies and especially not on the internet and most decidedly not anywhere near any sort of perl community. They've all been strict 9-5ers for whom the coding is a burden to bear to pay the bills and nothing else.

The people who're old and in the community? They're on the same Kwalitee train as everyone else.

Ah, this leads to some of my favourite python bugs. Silent failures because you are catching and ignoring an error in some higher calling function where the error type that was once designed to deal with a single case is now overly broad. I've almost given up using try/catch for KeyErrors as a result.

Python uses try/except, not try/catch. The only reason to catch KeyError is to detect missing keys, so if you are trying to do that, only wrap your dict access rather than wrapping large blocks of code where anything could happen. If you are writing code to ignore errors, that is a bug in your own code, not a python bug.

Yes. s/python bugs/bugs in my python code

The license model is great.

Yup. The WTFPL is an actual, (semi)-recognized license used in other projects: https://en.wikipedia.org/wiki/WTFPL

It's not an OSI approved license, nor does it actually grant any rights. If you use the WTFPL then you are preventing others from legally using it.

Yeah, good to mention it here explicitly. The Wikipedia page linked above has a nice summary of its "compatibility":

  DFSG compatible   Yes
  FSF approved      Yes
  OSI approved      No
  GPL compatible    Yes
  Copyleft          No
  Linking from code with a different license  Yes

The tests are gold

I'm definitely going to use this thing!


> legitimate tool

You and I have different definitions.

But this tool is not meant to be used. You should never have to write "import someReallyOffensiveModuleName" because those are jokes not meant to be used at work.

At work you should probably never be using a tool that just ignores errors. Errors are there for a reason, and you should have a very good reason for ignoring them.

The purpose of this obviously went right over your head.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact