[IronPython] Some thoughts on namespaces, extension methods

[Dan Eloff]

On Tue, Nov 18, 2008 at 6:55 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> Hmmm... the topic has been discussed by the Python developers in the past,
> and there is a pretty solid consensus that being able to modify the built-in
> types is 'crazy'. I think you would find that a significant proportion of
> the community would believe that allowing the modification of built-in types
> is not Pythonic and that IronPython was changing Python if it allowed this.
>
> Brushing aside Guido's concerns as FUD (even if you disagree - and I'm
> agnostic on this particular topic) is unlikely to be seen as a valid
> argument either...
> I don't think that this is an implementation detail of
> CPython but a conscious decision (although performance of attribute lookup
> and memory savings for the built-in types as each instance doesn't require
> an instance dictionary are likely to be part of the reason for this
> implementation decision in CPython - but by no means the only reason).
>
> Although monkey patching has been beloved in the Ruby community there has
> been interesting push-back in recent months.
>
> Extension methods in C# are an interesting language feature. This is one
> area where static-typing is helpful as you can get early warning of
> incompatible extensions (and with method overloading can even multiple
> extension methods with the same name but different signatures I guess). It
> would still be a *problem* if you wanted to use two libraries that both
> tried to extend types using the same extension method names, but at least
> you would get warned about it rather than simply having runtime madness.
>
> Michael

All good valid points.

It seems to me that there's little harm in allowing ruby style
modifying of builtin types in a given project, provided the code (or
more specifically the modifications) are not visible outside of the
project. If you want to add an index() method to tuple, in your own
codebase, go ahead. On small projects where developers can all
interact with each other, they will work out what should be added to
the builtins and what should stay as seperate methods. It also makes
some test scenarios easier where it's difficult to use mock objects.
I'd argue that here the potential for good outweighs the bad. Nobody
but the developers are exposed to any harmful side effects, and the
developers will act in their own self-interest to ensure the
extensions have a net positive impact. Resolver, or at least the parts
that are isolated from user's code, is a good example of this kind of
project.

Currently I think most of this (excluding testing usage) is possible
if you write the extensions in C#. Perhaps that is the way it should
stay. CPython has often taken the approach that "advanced"
functionality should stay in the C API, and if developers really need
it, then having to write C won't be an unreasonable hurdle.

However, library code should not use these kinds of extensions at all.
It would be a mess if a library's extensions could be visible to other
python code and or libraries. I don't think the typical Python's
gentlemans agreement is enough to prevent this kind of nightmare. This
scenario should not be allowed, period.

Perhaps one way this could be accomplished is to introduce an option
-X:MutableBuiltins to enable this. Libraries, which are not
executable, cannot rely on having that option present, and so cannot
modify builtins. Developers can on an individiual project basis, and
only if it is deemed "a good idea", turn the feature on.

Again, if extending builtins from C# is possible (I haven't tried this
yet), then this would be very low priority. There are so many things
I'd rather see in IronPython.

-Dan









>
>> The second is a very real concern.
>> Would changes to namespaces, static classes, monkey patching types etc
>> be visible across what should be isolated script engines? It doesn't
>> have to be that way, but like CPython we might well decide the
>> perfomance/complexity tradeoff involved in isolating mutable types is
>> not worth it.
>>
>> Essentially this is an implementation artifact of CPython, and like
>> reference counting or the GIL, it is not something that IronPython has
>> to copy.
>>
>> I'm interested what people have to say about this.
>>
>> -Dan
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>
>
> --
> http://www.ironpythoninaction.com/
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>