If you strongly type handler to a delegate type IronPython should
convert the function to the delegate type on the call. I had meant to
write "EventHandler" in my original sample code but somehow
I ended up using the Python syntax EventHandler[HtmlEventArgs] :)
Yeah, the comment's write, I'm wron
Thanks Dino!
I've got something to at least compile, but I'm getting the error
"ArgumentTypeException: unsupported operand type(s) for +=:
'PythonBrowserEvent' and 'function'". OK, makes sense, it's not finding
InPlaceAdd(Python.Runtime.Method), right? Since I can't link against
IronPython, wh
On 15/02/2010 23:53, Michael Foord wrote:
On 15/02/2010 23:51, Jeff Hardy wrote:
On Mon, Feb 15, 2010 at 4:41 PM, Dino Viehland
wrote:
We could make % on a Unicode literal do something special much like
we're doing for calls to unicode(...). Alternately we could make %
try to invoke __unicode
On 15/02/2010 23:51, Jeff Hardy wrote:
On Mon, Feb 15, 2010 at 4:41 PM, Dino Viehland wrote:
We could make % on a Unicode literal do something special much like
we're doing for calls to unicode(...). Alternately we could make %
try to invoke __unicode__ before __str__ - but that would some
On Mon, Feb 15, 2010 at 4:41 PM, Dino Viehland wrote:
> We could make % on a Unicode literal do something special much like
> we're doing for calls to unicode(...). Alternately we could make %
> try to invoke __unicode__ before __str__ - but that would sometimes
> be wrong. Probably not very oft
We could make % on a Unicode literal do something special much like
we're doing for calls to unicode(...). Alternately we could make %
try to invoke __unicode__ before __str__ - but that would sometimes
be wrong. Probably not very often, it's hard to imagine someone
defining __unicode__ and expec
For anyone attending PyCon, I'll be presenting a poster session entitled
"Behind the Iron Curtain: How Python is Tested at Microsoft". Any ways, one of
the focuses of this session is our old performance lab infrastructure. Not
only will you hear some details about how performance testing is a
On Mon, Feb 15, 2010 at 4:13 PM, Dino Viehland wrote:
> Is the template string really a constant in the case that you care about?
Yeah, it is, thankfully. I doubt there's a ton of cases where it
occurs, and I really hope there aren't any where the format string is
in a variable - I think I'd just
Is the template string really a constant in the case that you care about?
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeff Hardy
Sent: Monday, February 15, 2010 3:12 PM
To: Discussion of IronPython
Subject: Re: [Iron
I found one more issue:
class Foo(object):
def __unicode__(self):
return 'uFoo'
print 'Foo: %s' % Foo()
print u'Foo: %s' % Foo()
>python test_u.py
Foo: <__main__.Foo object at 0x003E8370>
Foo: uFoo
>ipy.exe test_u.py
Foo:
Foo:
See http://docs.python.org/library/stdtypes.html#stri
It's not the tests, it's the infrastructure. Years ago when we were on the
CLR team we wired up everything to run on their perf testing infrastructure.
They've since moved on and we've been running on the old stuff that's been
bit-rotting away. But the Developer Division has some division-wide
i
On Mon, Feb 15, 2010 at 3:57 PM, Dino Viehland wrote:
> This was relatively easy, it was just work once Michael came up with the
> great idea. But I do manage to get plenty of sleep - I just put off other
> mundane but important things on my TODO list like updating our perf
> infrastructure.
Can
This was relatively easy, it was just work once Michael came up with the
great idea. But I do manage to get plenty of sleep - I just put off other
mundane but important things on my TODO list like updating our perf
infrastructure.
-Original Message-
From: users-boun...@lists.ironpython
Works for me - lots more Django tests passing, now. Awesome work,
Dino! (PS: do you even sleep?)
- Jeff
On Mon, Feb 15, 2010 at 10:49 AM, Dino Viehland wrote:
> This is now checked into the Main branch if anyone wants to download,
> compile, and give it a shot.
>
> I'll push it to the 2.6 branc
On 15/02/2010 21:54, Mark Grice wrote:
I am using IronPython within a C# .NET application.
I have a class that the Python code uses, so I create a scope and set
the variable, then execute the engine like this:
private ScriptEngine scptEngine = null;
private ScriptRuntime scptR
I am using IronPython within a C# .NET application.
I have a class that the Python code uses, so I create a scope and set the
variable, then execute the engine like this:
private ScriptEngine scptEngine = null;
private ScriptRuntime scptRuntime = null;
private ScriptScope
Hopefully updating the tokenizer and parser should be fairly obvious. Once
you've done that you'll need to actually implement the operators themselves.
If the implementation of these operators is effectively exactly the same as the
normal binary operators it should be pretty easy - you just ne
Hi,
I'm interested in experimenting with adding new infix operators to
IronPython to support objectwise and elementwise operators. PEP 225
(http://www.python.org/dev/peps/pep-0225/) describes the potential use cases
for such operators. Matlab style matrix operations are the chief example.
Clearly
This is now checked into the Main branch if anyone wants to download, compile,
and give it a shot.
I'll push it to the 2.6 branch post-PyCon.
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Friday
This is an automated email letting you know that sources
have recently been pushed out. You can download these newer
sources directly from
http://ironpython.codeplex.com/SourceControl/changeset/view/63991.
MODIFIED SOURCES
$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/AstMet
On 15/02/2010 16:22, Dino Viehland wrote:
Michael wrote:
Could the namedtuple API be changed to better support IronPython - perhaps an
optional __module__ argument?
That'd be one way to do it - but I'm not sure it helps much compared to just
setting __module__ when you get it back.
Michael wrote:
> Could the namedtuple API be changed to better support IronPython - perhaps an
> optional __module__ argument?
That'd be one way to do it - but I'm not sure it helps much compared to just
setting __module__ when you get it back. It would certainly be more
discoverable though.
On 15/02/2010 16:04, Dino Viehland wrote:
This works if you run with the --X:Frames option. This is because
namedtuple is using sys._getframe to find the calling module name and
setting it on the created class. Alternately you could do this yourself:
Point.__module__ = __name__
You could
This works if you run with the -X:Frames option. This is because namedtuple is
using sys._getframe to find the calling module name and setting it on the
created class. Alternately you could do this yourself:
Point.__module__ = __name__
You could file a bug on this on CodePlex but to fix it we
This assert works in CPython 2.6 and not in IronPython 2.6.1 RC 1 with a failure
in dumps():
from collections import namedtuple
# verify that instances can be pickled
from cPickle import loads, dumps
Point = namedtuple('Point', 'x, y', False)
p = Point(x=10, y=20)
assert p == loads(dumps(p))
_
25 matches
Mail list logo
