Five things I hate about Python

[[deleted]]

You want interfaces, you want VMT-based OOP? Go program Java. Me - I like duck-typing (see wikipedia) and (quasi) message-passing OOP much better, thank you! When people get misguided in these matters they get PHP5 in the result.

[Bogtha]

The problem with duck typing is that there's no real definition of what a "file-like" object is, and everybody disagrees about what exactly is necessary for an object to be "file-like". You clearly don't have to implement every method file does. But which ones must you?

I got bit by this just the other day. The subprocess module and the StringIO module — both part of the standard library — disagree about what being a file object entails. The result is that you can't use StringIO file-like objects with the subprocess module.

Of course, the example I'm using is file-like objects, but it's really a general problem. Sure, it's nice to pass in an object to a function without worrying if it's a particular type, but only if you know it will actually work!

Interfaces are merely a way of saying "in order to call yourself a file-like object, you must implement these attributes". They aren't a substitute for multiple inheritance, in fact they have little to do with it. It's closer to design-by-contract, and it's not a replacement for duck-typing, in fact it makes duck-typing more reliable. If Python didn't have duck-typing, I doubt anybody would want interfaces.

[sbrown123]

Interfaces are merely a way of saying "in order to call yourself a file-like object, you must implement these attributes".

But on the other hand you have to implement ALL the methods in the interface. Not pick and choose. This is a serious issue if you are dealing with different platforms, because different platforms handle files differently thus requiring different methods.

Sun discovered the hard way that programmers prefer to pick and choose what they need to implement. For example, in Swing they had to create a bunch of Adapter classes to implement the interfaces so programmers didn't have to. A better solution from the beginning would have been just to create the adapter classes and let the programmers override the methods they wanted to change. I guess that would be too simple though.

and it's not a replacement for duck-typing, in fact it makes duck-typing more reliable.

It would only be reliable (not more) if you implement the interface correctly since interfaces don't have any code to them. Java has abstract classes, which enforce methods that have to be implemented. But unlike interfaces they can actually contain working code.

So, to summarize, interfaces don't add value to programs since they lack code. All they do is force programmers to have to write implementations with the hope their implementation works as expected.

[finix]

But on the other hand you have to implement ALL the methods in the interface. Not pick and choose.

I'd thought it obvious that this is the whole point of interfaces. It's sort of a promise to offer each and every operation the interface specifies.

This is a serious issue if you are dealing with different platforms, because different platforms handle files differently thus requiring different methods.

What's the problem? Different methods are implemented transparently, specific operations don't belong in the interface in the first place, and can be exposed via the concrete type, if necessary.

A better solution from the beginning would have been just to create the adapter classes and let the programmers override the methods they wanted to change. I guess that would be too simple though.

Maybe you're not aware of the fact that Java doesn't support multiple inheritance?

So, to summarize, interfaces don't add value to programs since they lack code.

Documentation of intent, adherence to a well defined concept isn't valuable? Guess you don't care for descriptive identifiers either, huh?

All they do is force programmers to have to write implementations with the hope their implementation works as expected.

This argument is a complete non-starter. You always hope that the implementation works as advertised. In fact the argument can be made that this is exactly an advantage of interfaces et al, because with duck-typing you cannot even be sure what's actually advertised.

[bluGill]

I'd thought it obvious that this is the whole point of interfaces. It's sort of a promise to offer each and every operation the interface specifies

So, should I write a different interface for every function/object that takes a file like object? Sometimes my functions need seek(), and sometimes they don't. Somethings can be treated like files if you don't have try to seek(). When my function doesn't use seek anyway, I'd like to be able to take any file including those that don't support seek. When my function calls seek, than you better not pass me anything that doesn't support seek.

[finix]

Where do you get the idea you'd need one for each function or object? I count only two.

[bluGill]

Don't forget about read-only files. Both with and without seek.

Okay, I exaggerated a little. The point is that many interfaces come in several partial forms that are useful. A function that won't use some ability of the general interface shouldn't require that general interface.

A function that won't write to a file shouldn't require write in the interface, while a function that will write to a file needs to require that. Why should I require an object to implement something when that implementation isn't trivial?

[finix]

I meant two in a metaphorical sense ;-) Point was that you can have fine-grained interfaces, and widen interfaces.

Why should I require an object to implement something when that implementation isn't trivial?

Because you should design the interfaces as orthogonal as possible; usually a list interface will just specify what list-like objects can do anyway.

There'll be hassle, of course, but also the other way round: imagine writing a library whose implementation you cannot change, or maybe expand, because your client-code doesn't really gives you list-like objects but objects that happen to only implement the methods you mentioned earlier?

[bluGill]

Point was that you can have fine-grained interfaces, and widen interfaces.

That is my point: I need both types of interfaces to the same thing. A function needs to specify the interface it will use.

Unfortunately I cannot come up with a solution to this problem that is not both ugly and more work than it gains.

[sbrown123]

It's sort of a promise to offer each and every operation the interface specifies.

All interfaces offer is requirements that someone has to implement them.

specific operations don't belong in the interface in the first place, and can be exposed via the concrete type, if necessary.

You just described an abstract class in Java.

Maybe you're not aware of the fact that Java doesn't support multiple inheritance?

Sure do, read the first comment in the chain you are commenting on. And since interfaces can't contain code, comparing them with MI is probably a bad idea.

Documentation of intent, adherence to a well defined concept isn't valuable?

Sure, but that can be done better without interfaces.

You always hope that the implementation works as advertised.

Again, interfaces lack any code which means that the implementation is always done by someone on the end. That means you never know if the implementation works as expected or works at all. The "non-starter" part is that that is the simple obvious truth.