• (cs)

    I don't forsee the value of (for example)

    I don't forsee the value of (for example)

       

    <FONT size=+0>def</FONT> __hash__(<FONT size=+0>self</FONT>):        

        <FONT size=+0>"""Return a hash of path"""</FONT>
        return hash(<FONT size=+0>self</FONT>.base)

    I suppose we can say, '100% of functions documented'.

    I suppose we can say, '100% of functions documented'.

    However, it seems repetitive.

    However, it seems repetitive.

  • Masklinn (unregistered) in reply to WTFer
    <!--StartFragment --> Oh god, how did he manage to do that to Python code
    WTFer:
    And of course if we are talking of the ugly curiosities of C we can never forget the Duff Device.

    The duff device is actually not really "C" and not really ugly. It also works in Javascript for example (with very nice results in some browsers) and is merely the (ab)use of switch/case fallthrough for easy optimisation purposes (when you have crappy compilers that can't optimize shit).
    loneprogrammer:
    All the people trying to plug their favorite language need to shut up.

    The only language that matters is binary code.  Everything else is just shorthand for it.

    SuperZap for the win :D
    lucio:
    People are just too lazy to go and find out. And this was an easy one, for there's a link to http://docs.python.org/lib/module-os.path.html [:D]

    Sometimes the Java/C# confusion comes along. I usually set them apart by methodName (Java) instead of MethodName (.NET), when possible.


    Uh, part of the WTF is that he actually used os.path to build his devilish device. You see, as in using a tool to build a bigger tool doing exactly the same thing but in a more complicated, less readable and less optimized way

  • Masklinn (unregistered) in reply to travisowens

    travisowens:
    __________underscores______________make___________code__________more________________readable

    These are actually Python built-in private methods.

    You are not supposed to call them directly (ever), as they usually have operators or built-in functions associated to them

  • (cs) in reply to dhromed

    C++ already has one.

  • (cs) in reply to dhromed

    dhromed:
    How about defining a WTF operator, that looks like this:

    ...

    C++ already has one.

    // So that's the difference between reply and quote [^o)]

  • (cs) in reply to Masklinn
    Anonymous:

    travisowens:
    __________underscores______________make___________code__________more________________readable

    These are actually Python built-in private methods.

    You are not supposed to call them directly (ever), as they usually have operators or built-in functions associated to them

    If Python is such a great language and you're not supposed to call them, ever, then why in the hell are you allowed to call them, ever?

  • (cs) in reply to YAFO

    Aside from the principle of least surprise being violated (I mean path("a").b.c + "d" = "a/b/c/d", etc.) this implementation actively prevents you from doing things you probably want and need to do with path names (such as append file extensions to them: path("My Documents/Thesis") + ".doc" does not have the effect you might (a) want and (b) expect). Nor will this do what one of the commands I often implement in any language does: catpath("this/", "/that") -> "this/that" ... yes indeed path("this/") + "/that" -> "this//that". So in essence the path object is less useful than a standard string.

    The interesting question is ... where might this actually save you some typing?

  • (cs) in reply to Miszou
    Miszou:

    dhromed:
    How about defining a WTF operator, that looks like this:

    ...
    C++ already has one.

    Um.... Technically, that's not an operator in C++.   (It doesn't perform any operation).  The ISO C Standard refers to it as a "<FONT face="Times New Roman">punctuator".  Some <FONT face="Times New Roman">punctuators are operators (* << ^) but others aren't (: ; {})</FONT></FONT>

    <FONT face="Times New Roman"><FONT face="Times New Roman">Now, the funny thing is, in the early days of Borland C (back when it was called "Turbo C"), it was an operator of sorts.   You could wrote completely illegal code like:</FONT></FONT>

    void MyPrintf(char* format,  ...)
    {
            printf(format, ...);
    }

    And it would compile & run with the expected results.

    <FONT face="Times New Roman"><FONT face="Times New Roman"> 

    </FONT></FONT>
  • thisismyname (unregistered) in reply to travisowens
    travisowens:
    __________underscores______________make___________code__________more________________readable

    omygodyourerighticompletelygetyoursarcasmtheseunderscoresservenopurposeatallwhatacaseofeducationalexaggerationplzteachmeareallanguagelikethatglorifiedassembler
  • asdf (unregistered) in reply to JohnO
    JohnO:
    Anonymous:

    travisowens:
    __________underscores______________make___________code__________more________________readable

    These are actually Python built-in private methods.

    You are not supposed to call them directly (ever), as they usually have operators or built-in functions associated to them

    If Python is such a great language and you're not supposed to call them, ever, then why in the hell are you allowed to call them, ever?



    Special cases aren't special enough to break the rules.
    Although practicality beats purity.

    How can one define what one cannot call, ever?
  • (cs) in reply to JamesCurran
    JamesCurran:
    Anonymous:
    Anonymous:
    phelyan:

    What gets me is the fact that he actually uses os.path.join in the code...

    That would be because he can't assume that he needs to use "/".


    *sigh* os.path.join() is os independent.... which means that you use it exactly when you can't assume how you'll be creating paths..... did you miss the post that said that?

    um... Whom are you talking to?  You are just repeating the same point Anonymous just made......

    What I meant was, the original post pointed out that the original developer should have used os.path.join() instead of creating such a convoluted construct. And I was pointing out that, yes, the original developer knew about it because he used it in his code that was posted above. So if he did, then isn't it even more of a WTF that he still coded what he did?

  • Hank Miller (unregistered) in reply to JohnO
    JohnO:
    Anonymous:

    These are actually Python built-in private methods.

    You are not supposed to call them directly (ever), as they usually have operators or built-in functions associated to them

    If Python is such a great language and you're not supposed to call them, ever, then why in the hell are you allowed to call them, ever?



    Read that closely.  He said you are not supposed to call them DIRECTLY, not that are are not supposed to call them.  
    Much like in C++ you never do: 
    foo.operator+(bar);

    instead you write

    foo+bar;
    python allows you to override getting member variables, so you can do
    foo = bar.baz()
    and have foo become /bar/baz.     However, just because you can doesn't mean you should.   
  • Bob (unregistered) in reply to Hank Miller

    The name mangling is just a convention

    init always fires when a class is instantiated, add overrides the "+", can you guess what mult does?

    dict is a reference to the namespace dictionary.... basically, two underscores either side denote a 'special' method or attribute.

    A single underscore prepended - ie. def _foo() is the usual indication of a private method/attribute.

    Python has a philosophy of "we're all consenting adults". If someone releases a module, the normal functions are not likely to change dramatically overnight, so you can trust that your brand new programme which relies on module X  is not going to break on the next release of X.

    However, convention is - we make not guarantees for _ denoted methods. They're internal, call 'em if you want, we'd rather you didn't, they may not be there next release.

    If you're calling a lot of 'private' methods/attributes, you doing it unpythonically.



  • Tobias Brox (unregistered) in reply to Jake P
    Anonymous:
    Ok, I'll bite and defend this one.

    The general idea isn't too bad.  If they get rid of __getattr__ and replace __add__ with __div__, they get a program where operator overloading actually makes some sense.  At the very least, it makes paths more readable:


    I can see another reason for doing this; libraries in python is usually imported like:

    import my.own.library

    which corresponds to the file "my/own/library.py"

    Thus, at least the __getattr__ can make some sense for readability - but I guess I agree that this class is overengineered, particularly if it's just used for replacing a function call 4 places in the code :-)

    If I was to guess, this code is written by some freshman that has just learned about python-__magics__ and thinks operator overloading is a cool thing.  I could have done similar things some years ago.
  • (nodebb)

    cool

    Addendum 2024-07-01 21:02: As a student of marketing, keeping up with the latest trends and theories while completing numerous case studies was overwhelming. I found myself needing extra help to manage my workload, so I turned to https://royalwriter.co.uk/ . Their writers provided insightful and well-researched essays that captured the essence of modern marketing strategies. This service allowed me to focus on practical projects and internships while maintaining my academic performance.

Leave a comment on “Operator Overloading Overload”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article