[IronPython] Writing new modules

[Nick Bastin]

On Aug 17, 2004, at 3:36 AM, Garth T Kidd wrote:

> There's a real tension between IronPython as a Python-syntax language
> relying on the common runtime, and IronPython as something that lets 
> you run
> arbitary Python code under dotNet. Depending on the project, I might 
> want
> either or both of those behaviours, and there's a certain chunk of the
> Python standard library (string methods come to mind) I want even in a
> "pure" dotNet project.
>
> The warnings framework might help here: expose list.Add, but detect it 
> being
> used and warn people that their code won't work in cPython or Jython. 
> If
> they don't mind the non-portability, they can easily filter out the
> warnings. If they do, at least their code will work until they 
> remember the
> Pythonic method.

The performance hit in this situation would be unacceptable in many 
circumstances.  You don't want your program filtering out warnings as a 
normal course of operations, especially when the warnings are issued a 
lot (which they presumably could be).

> Some diehard dotNet shops might potentially insist that there be a
> corresponding way of having warnings issued on calls to list.append ("I
> don't mind you using that weird-ass language, but at least use the 
> methods
> the other blokes understand!"), but for the time being I'd a) pray that
> doesn't become a real issue, and b) plan on leaving those warnings 
> disabled
> by default.

I'd like to have Python be a first-class CLR language, but I'm not 
willing to fundamentally change the core language to get that.  If 
dotNet people don't like list.append(), they can use some other 
language.  That's the whole point of the CLR.

--
Nick