• (nodebb)

    Frist,

    Also, it takes three parameters and uses one of them.

    As you see in the next snippet, it's an exception handler that's used with shutil.rmtree, so that's the parameter list it needs.

  • DanielOfMyr (unregistered)

    I'm curious about how and where this code is used

  • (nodebb) in reply to Dragnslcr

    Possibly it should do something with those parameters, though. The current logic is "if there's an error deleting a file, add write permission, and then delete it again". I don't think that will work anyway - IIRC you need write permission to the directory containing the file, not write permission to the file itself, to delete it. And if the error is due to something other than the file not being writable, deleting it again will still fail.

  • (nodebb) in reply to SteelCamel2

    IIRC you need write permission to the directory containing the file, not write permission to the file itself, to delete it

    In my experience, you need both write permissions (to the file and to the directory that contains the name that you want to delete(1).

    (1) That's not a circumlocution. If you want to delete the file, you have to delete all of its hard links.

  • jmeh (unregistered)

    I like the name safe_rmtree on it's own. It's like "safe chainsaw", no it's not. If it does what it is supposed to it isn't safe. The whole bit about minimum depth is probably to make it really hard to remove a top level directory. I guess he did it by accident at some point and decided to add this as a safe guard.

    As for the sleep(0.1) the idea is probably to give the file system time to flush changes to disk. Wrong way to do it but might make the program run better after deleting a big tree, particularly if the code is old enough to be running on a mechanical hard disk.

  • Brian (unregistered)

    On the plus side, I like that he cited his source on that first one. I do that sometimes, for a complex algorithm or even just SO code, it's nice to have a reference to the original for the full context.

  • Miles Archer (unregistered)

    This is the kind of thing Claude is great at fixing. I'd give it a sample and see what it does with it.

  • (nodebb) in reply to Steve_The_Cynic

    You don't need write permission on the file to delete it, but the rm command will prompt for permission unless you use the -f command. os.remove() has no similar requirement.

  • Steven J Pemberton (unregistered) in reply to Barry Margolin

    The rm command doesn't prompt for confirmation unless you specify -i (interactive). Most Linux variants that I've used in the last few years alias rm to rm -i for the root user, but not for unprivileged accounts.

  • enkorvaks (unregistered) in reply to Steven J Pemberton

    The rm command will prompt for confirmation (without the -i) if you have write permission for the directory, but not for the file.

  • Officer Johnny Holzkopf (unregistered)

    Regarding the documentation: "Recursively removes all files in a directory that should contain [...] nr of folders that the parent should contain [...]" - go on, tell me about the difference between a directory and a folder.

  • (nodebb)

    Fairly weak wtf honestly. A lot of it is simply nitpicking for the sake of nitpicking, e.g. that crappy del_rm function is automatically explained once it's a callback in the second function. Or the fact they are "reinventing" the path library is probably just code sedimentation.

    Best code ever? Of course not. It's a utility pot-pouri on Python, the lowest level of the lowest "who cares" levels, it probably grew organically based on immediate needs over the years. As long as it does the job... Stop overthinking it.

    It's easy to blame stuff on Python since the language sure does appeal to the common denominator. Yet let me guess, a rewrite of this is going to take years and end up with similar crappy code just in a different language because the real issue is probably the idiosyncrasies of the business logic evolving incoherently over the years.

    The real WTF is that management was happy to leave a "mission critical" piece of infra on a sole overworked person who probably was never thanked for doing the job of an entire team. Been there. Ended up burned up and rage quitting.

  • Sandra from InitAg (unregistered) in reply to Ralf

    It's a utility pot-pouri on Python, the lowest level of the lowest "who cares" levels

    I noted in the original submission that this was one of the better files in the project, and I stand by that. Utility potpourri is the smallest of the original programmer's sins, but also the easiest to both understand and anonymize. His philosophy, towards basically everything, was to write it himself unless he had no other choice - he disdained both the standard library and external libs (believing any external dependency to be inherently difficult to manage, which, given that he did Python package management like it was 2002 despite it being 2022, wasn't far off the reality), resulting in vast quantities of duplicated and copy/pasted slop.

    My personal favourite was the C-style error handling - structured, typed exceptions are for morons, apparently; instead, there's a single global problem_handler function that accepts a message and stringly-typed error code, which then gets looked up in a massive lookup table to determine what to log.

    The real WTF is that management was happy to leave a "mission critical" piece of infra on a sole overworked person who probably was never thanked for doing the job of an entire team. Been there. Ended up burned up and rage quitting.

    That's basically what happened to this guy too. They got so used to him treating the software like his own little baby that they started treating him like a piece of furniture, so eventually he left.

Leave a comment on “Brillant Python Programmers”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article