Dan Eloff wrote:
On Wed, Nov 12, 2008 at 4:19 PM, Dino Viehland <[EMAIL PROTECTED]> wrote:
Actually I'd say modifying built-in types is unpythonic - for example you can't do
object.xyz = 42. We could choose to break this rule for types we don't share
between Python & .NET, and it probably wouldn't be a lot of work, but I'm
hesitant to have the two sets of types treated differently.
I'm going to be contrary here and say that modifying built-in types is
not allowed by the current C implementation, but is compatible with
the language and principles that define pythonic. To paraphrase Guido,
there are two main reasons why modifying builtins is disallowed. 1) To
prevent accidental breaking of unrelated code in unexpected ways. 2)
Since builtins are shared between interpreters running in the same
address space, making them mutable would allow code in one interpreter
to affect the other.
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.
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
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
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.ironpythoninaction.com/
_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
