Updating module-level globals() raises AttributeError.
vars = {'a': 1, 'b': 2}
globals().update(vars)
print a, b
Seo Sanghyeon
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
2006/3/27, Sanghyeon Seo <[EMAIL PROTECTED]>:
> Updating module-level globals() raises AttributeError.
This happens only when run from the file. Interactive console is fine.
Seo Sanghyeon
___
users mailing list
users@lists.ironpython.com
http://lists.ir
Hello Seo,
On Windows XP, it runs without a problem.
Greets, Rene Olsthoorn.
On 3/27/06, Sanghyeon Seo <[EMAIL PROTECTED]> wrote:
> Updating module-level globals() raises AttributeError.
>
> vars = {'a': 1, 'b': 2}
> globals().update(vars)
> print a, b
>
> Seo Sanghyeon
> ___
2006/3/27, Rene Olsthoorn <[EMAIL PROTECTED]>:
> On Windows XP, it runs without a problem.
Strange, I can reproduce this on Windows XP too.
Seo Sanghyeon
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ir
Hi,
When there will be support for .NET Attributes in IronPython?
Is there any way currently to mark my class as Serializable?
--
Andrzej
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Thanks for the bug report Seo. I can repro this on our current builds and have
filed the bug. I think we'll be able to get this one fixed for beta 5.
Do you want to help develop Dynamic languages on CLR?
(http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1
Did you run it at the console or from a file you imported?
IronPython will actually use different underlying CLR dictionary objects
depending on how the code gets compiled (which is the reason why this compiles
in one spot but not another).
Do you want to help develop Dynamic languages on CLR?
This is a tough problem... There are two issues here. But the executive
summary here is I'd say the earliest you should *expect* to see this is 1.1,
but if (somehow) we end up with some extra time we might have something in the
1.0 timeframe (but don't hold your breath!).
The first issue here
On the topic of decorators and integrating with .NET, it seems that in order to keep IronPython as close to CPython, it would be a good idea to consider adding .NET specific pieces as a "library" instead of an addition to the language. That way people could write python code that works in IronPytho
This is great feedback…. And yet another
way we could consider doing this would be something whacky with metaclasses
where we had an “attribute-aware” metaclass or something like that…
But it demonstrates the difficulty in adding support for features like this and
the reason we need to tr
For the purposes of consistency, the attribute decorators would need to apply
everywhere an attribute is able to exist in .NET: types, members, etc.
In the case of Serializable, merely subclassing ISerializable isn't necessarily
the best way, since a class can be decorated with SerializableAtt
Hi
I'm using mono 1.1.13.4 and calls to IronPython 1.0 Beta 4 cause a segv.
What version of IronPython works??
Mathew
** (/home/myeates/mono-1.1.13.4/lib/xsp/1.0/xsp.exe:20873): WARNING **:
The class System.Collections.Generic.IDictionary`2 could not be loaded,
used in mscorlib, Version=2.
1.1.13.4 should work with IronPython, but you seem to be running it inside xsp,
which is a net 1.1 app. Try using 'xsp2'.
Zoltan
On 3/27/06, Mathew Yeates <[EMAIL PROTECTED]> wrote:
> Hi
> I'm using mono 1.1.13.4 and calls to IronPython 1.0 Beta 4 cause a segv.
> What ver
My only point is that new decorators shouldn't be included unless they are available in the language. I know Guido said something about them at PyCon but I can't remember what :)I have no problems with decorators by the way. Cherrypy (a web framework/library) uses a decorator-ish syntax, so if impl
2006/3/28, Dino Viehland <[EMAIL PROTECTED]>:
The second problem is also just as tough, but it's completely
different. How do you even express an attribute on a class? There's
no Python syntax for this so we'd have to add something new. It'd be
great if we could use decorators here, but they don
2006/3/28, Sanghyeon Seo <[EMAIL PROTECTED]>:
> I like __attributes__ solution.
As pointed out already, decorators can't be used with classes as of
2.4. But __attributes__ can be attached to classes or functions.
I agree that decorators would be nice. Perhaps something like the
following in clr m
I like this too... It's interesting that while the syntax isn't exactly the
same for giving both classes & functions attributes they are both getting that
information in the same way. I was previously worried about the differences
between classes & functions but I think this brings it all toge
17 matches
Mail list logo
