The Daily WTF: Curious Perversions in Information Technology

smitty_one_each · 2005-08-01 Reply Admin

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

def __hash__(self):

 """Return a hash of path"""
 return hash(self.base)

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

However, it seems repetitive.

2005-08-01 Reply Admin

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

2005-08-01 Reply Admin

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

Miszou · 2005-08-01 Reply Admin

C++ already has one.

Miszou · 2005-08-01 Reply Admin

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)]

JohnO · 2005-08-01 Reply Admin

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?

podperson · 2005-08-01 Reply Admin

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?

JamesCurran · 2005-08-01 Reply Admin

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 "punctuator". Some punctuators are operators (* << ^) but others aren't (: ; {})

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:

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

And it would compile & run with the expected results.

2005-08-01 Reply Admin

travisowens:
__________underscores______________make___________code__________more________________readable

omygodyourerighticompletelygetyoursarcasmtheseunderscoresservenopurposeatallwhatacaseofeducationalexaggerationplzteachmeareallanguagelikethatglorifiedassembler

2005-08-01 Reply Admin

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?

phelyan · 2005-08-01 Reply Admin

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?

2005-08-02 Reply Admin

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.

2005-08-03 Reply Admin

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.

2005-08-07 Reply Admin

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.

Operator Overloading Overload

Leave a comment on “Operator Overloading Overload”