[IronPython] Some thoughts on namespaces, extension methods

[Michael Foord]

Dan Eloff wrote:
> 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.
>   
Hmmm... specifying in a project that extension methods from this library 
I use are ok but from the other library aren't sounds like a recipe for 
complexity.

> 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.
>
>   
Agreed, I'd much rather see zipimport and zlib support for example.

Michael
> -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
>>
>>     
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog