[IronPython] Some thoughts on namespaces, extension methods

Dan Eloff dan.eloff at gmail.com
Thu Nov 13 20:26:21 CET 2008

On Thu, Nov 13, 2008 at 1:40 AM, Curt Hagenlocher <curt at hagenlocher.org> wrote:
> On Thu, Nov 13, 2008 at 12:40 AM, Dan Eloff <dan.eloff at gmail.com> wrote:
>> The first seems to me an extension of the ancient argument that you
>> should not be trusted with fire because you might burn yourself. It's
>> a fud appeal, not an argument.
> Ever used Ruby? ;)

To extend my metaphor, there are, however, good reasons to not be
trusted with napalm.

> Although I was very skeptical at first, I've really grown to
> appreciate the way that C# and VB implement extension methods. By
> using an explicit opt-in to the ones you want, you avoid the hell of
> everyone trying to add their favorite overlapping extensions to
> "string".

That is true. Imagine importing a third party package in Python to
discover it added a dozen new methods to str. Yech.

> Of course, you can generally modify non-C-based classes in the Python
> standard library, but this seems to be much less interesting to the
> average Python dev.  Or at least there's no Pythonic culture of insane
> monkey-patching.

No, because in general it's a bad idea. It is, however, commonly used
in testing situations, and sometimes, after careful thought, by
packages that build on stdlib functionality. Used right, such
functionality is harmless, and it makes some tasks easier. Used wrong,
such functionality is downright evil.

Namespaces and static classes are really like modules, and should be
mutable to be in keeping with Python. But as for monkey patching
types, I don't know that the use cases justify it. If somebody is
having a problem with your library, it's nice to not even have to
consider that it's because he changed list.append to add items to the
front of the list (or worse yet some other idiot did that in another
library that he uses)

Still there may be a way to tackle this from the .NET side rather than
the Python side of things. There is some value to be able to define
extension methods C# style from IronPython, and if implemented in a
similar fashion, it should be harmless.


More information about the Ironpython-users mailing list