Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I get the feeling that overloading the division operator for paths is a really bad idea for clarity... To someone who is unfamiliar with the path.py package, it looks like you're trying to divide some sort of object by a string.

Not to mention the fact that, in his code, he aliased path to p, so it's even more confusing as to what is going on there.



Yeah, not the best example I think. This code is not bad at all:

    filepath = os.path.join('.', 'test_dirs)
    os.makedirs(filepath)
    with open(os.path.join(filepath, 'test.txt'), 'w') as f:
        f.write('hello world')
And it's actually obvious what happens with the file handle after write. I'm not sure if it's still open or not at the end of his example really. I wouldn't be surprised by his example in ruby code (overloading with magic functionality), but in python that just looks weird...


It does make the code a lot clearer to read. There are a lot of other python packages that overload specific operators/magic functions to aid readability. For example, numpy arrays overload the slice operator to great effect.

Also, on the same topic, what about using the '+' operator with strings and lists/tuples for concatenation? Or the '|', '&' and '^' operator for sets (which I have to admit I never use because I can never remember which is which)?


> It does make the code a lot clearer to read.

If, and only if, you're familiar with how the path library works. I had to shift mental contexts away from python and into shell to understand that it was a "shortcut" for os.path.join(). The division operator is not typically associated with path joining in programming languages.

Frankly, it's not really offering any greater level of abstraction for paths; just shortcuts. You still have to call makedirs, open, write, etc. I don't find the minute improvements to os.path.join that terribly compelling.


I agree. I inherited some code that did this and it was not immediately obvious what was going on. I thought the variables being used where numbers, and I was very confused.


I guess its a terrible thing for a dynamic language like Python. boost::filesystem::path has been overloading the '/' operator all along.




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

Search: