[IronPython] .Net attributes/decorators

[Hank Fay]

Thanks for the explanation.  I like the "opt in" idea -- taken to its
fullest, that could allow .Net-style decorators on an opt-in module basis,
could it not?   And I see the point about the "many platforms in one
codebase" approach you describe as a way of enabling the larger Python
community.  By pursuing both approaches, the many-in-one and the opt-in to
the fullest, I think IPy can continue to fulfill what I understand now to
have been the original goal, of serving the Python community, while also
providing an enticing alternative to static .Net languages for
non-Pythonistas looking for a more comfortable home.

In the meantime, I know where to go when I get stuck on how to use
ClrType.py to use .Net attributes. You probably know where I can go, too,
but we're probably thinking of different places. <s>

thanks again,

Hank

On Tue, May 18, 2010 at 4:50 PM, Dino Viehland <dinov at microsoft.com> wrote:

>  The answer is kind of both.  When it comes to the core language grammar
> we are (and I believe will always be) an equivalent set.  That’s rather
> important in that any code which is .NET specific can still be parsed by
> other Python implementations and therefore you can do various if I’m running
> on IronPython do this else if I’m on Jython do that or if I’m on CPython do
> something else – which is a fairly common pattern and even shows up in the
> standard library.  When it comes to the various builtin types we intend to
> be a superset but that superset is only available after the user has
> specifically opted in to IronPython.
>
>
>
> So let’s look at some examples how this has played out.  To add generic
> support we used Python’s existing indexing support rather than adding
> parsing support for something like Dictionary<int, int> which would have
> matched C#.  But at the same time we don’t want to modify the core objects
> too much – for example a future version of CPython could choose to add
> indexing support to built-in functions to add some new feature of their
> own.  Therefore our built-in functions which are generic are actually a
> subtype of the normal built-in function type and add indexing.  Our normal
> built-in functions don’t support indexing (types/generic types actually
> still need this treatment of not having indexing by default but I haven’t
> gotten around to fixing that one yet).
>
>
>
> And of course we try and make sure that all of the extensions that we do
> offer are only available on an opt-in basis and that opt-in basis is
> per-module rather than tainting all code in the interpreter.  That enables
> some code to be Python specific and other code to be Ipy specific.  That’s
> done via “import clr” (or importing any other .NET namespace actually) which
> makes any additional attributes that we’ve added to types available (for
> example __clrtype__ is not visible until you do an import clr).  That
> enables us to expose things which are .NET specific but still allows pure
> Python code to run without seeing anything change – so for example if some
> code as doing dir() it’s not going to freak out because there’s some
> unexpected attributes.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Hank Fay
> *Sent:* Tuesday, May 18, 2010 11:11 AM
> *To:* Discussion of IronPython
> *Subject:* [IronPython] .Net attributes/decorators
>
>
>
> In reviewing the discussion of .Net decorators in the list (thank you
> Google Groups), I did not come across a discussion of what I saw as the
> central issue: is IronPython to be a Superset of Python (every Python
> program will run in IronPython, not every IronPython program will run in
> Python), or is IronPython to be an equivalent set (every Python program will
> run in IPy, and every IPy will run in Python).
>
>
>
> Has there been a discernment on this issue?
>
>
>
> For me, coming from a non-Python world, it makes sense to view IPy as a
> superset of Python.  This perspective would, e.g., allow the use of .Net
> decorators on classes (which in turn would facilitate returning .Net
> objects).  I've read about the ways of using __clrtype__ to do this in a
> Pythonic manner.  My interest is in simplicity and clarity in my
> programs, rather than maintaining two-way compatibility (which I could not
> port to Python, in any case, for a .Net program using .Net features).
>
>
>
> thanks,
>
>
>
> Hank Fay
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20100519/f00cfb0d/attachment.html>