But there is one limitation to this - you cannot currently override protected
methods or access protected fields when subclassing. We should have that fixed
for the next release.
From: [EMAIL PROTECTED] On Behalf Of Martin Maly
Sent: Saturday, December
Hello IronPython community,
We?ve just released the newest version of IronPython ? 0.9.6. This is most
likely the last Alpha version of IronPython before the end of the year when we
play to release IronPython 1.0 Beta 1. This build includes many bug fixes for
issues reported to us by the
Title: [IronPython] New proposed exception model for IronPython
Its an extremely interesting idea and
one that I personally like. Being the new guy Ill want to hear Jim and
Martins input too J.
Ultimately theres no reason why we
couldnt either expose supplementary dictionaries that
#BeginMapException CliException1 PythonException3
...
#EndMapException CliException1
From:
[EMAIL PROTECTED] on behalf of Dino Viehland
Sent: Thu 12/15/2005 3:40 PM
To: Discussion of IronPython
Subject: Re: [IronPython] New
proposed exception model for IronPython
Its
Thanks for the bug report. We know
the string formatter is currently lacking but weve been treating it as a
lower priority and have been extending it on an as-needed basis. But now
that youve brought this to our attention we should be able to get this
one fixed for the next release.
:01 PM
To: Discussion of IronPython
Subject: Re: [IronPython] how to change default encoding of string and file
at runtime?
On Tue, Dec 27, 2005 at 04:57:32PM -0800, Dino Viehland wrote:
This is an interesting issue... If I take your same code and run it
on CPython it raises an exception
We've actually already made a change for the next release to be fully
compatible with the warnings test here. The wiki is just a little out of date
right now.
We've switched the exceptions over to using old-style classes and also improved
the interop story between Python exceptions and CLR
Thanks for the bug report - it seems likely we can get this one in for the next
release.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanghyeon Seo
Sent: Wednesday, December 28, 2005 10:01 PM
To: users@lists.ironpython.com
Subject: [IronPython]
Good catch... Another solution might be for us to implement ntmath as a
built-in module that delegates to the BCL's path functionality which should get
it right on a per-platform basis (or have cli recognized as it's own platform
and have a clipath.py that does the right thing).
I'll add this
Its a command line option: X:TabCompletion
enables it.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of jeff sacksteder
Sent: Friday, December 30, 2005
8:50 AM
To: Discussion of IronPython
Subject: [IronPython] tab
completion?
In the demo video, it appears
PM
To: Discussion of IronPython
Subject: Re: [IronPython] Method overload
Couldn't I use the [] syntax to tell IP what .Net type to use for eachparameter? (Where is there a good description of the [] syntax?)
At 01:05 PM 1/9/2006, Dino Viehland wrote
The [] syntax is for generic types
This looks like a bug (or two). We currently don't allow you to override
reflected methods on a per-instance basis (or at least the C# side won't see
it).
We also don't allow you to construct bound ReflectedMethod's in the manner that
you'd like. Currently we only really expect the
Thanks for the bug report - we hadn't seen this one before. We'll get this
fixed for the next beta release.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oonuki Makoto
Sent: Monday, January 16, 2006 6:48 PM
To: users@lists.ironpython.com
Subject:
The correct answer for this is to use the codecs module (or the _codecs
built-in module). Unfortunately we don't have that implemented yet so for the
time being you will have to use the .NET Framework (System.Text.Encoding should
do the trick).
I'll add codecs to our list for beta 3 -
Another option that should work is:
class ClickListener:
def trigger(self, source, args):
print ...
a = ClickListener()
b = a.trigger
triggerButton.Click += b
triggerButton.Click -= b
What you're experiencing is the fact that trigger is actually just a callable
It's just an oversight - We're not setting sys.argv in
PythonEngine.ExecuteCompiled, so we just need to do:
engine.sys.argv = List.Make(Environment.GetCommandLineArgs());
then you should get the arguments.
Thanks for the report - I'll get a bug opened on it for beta 3.
Jim, Martin and I discussed this today and we're looking at providing some
array creation functionality via the clr module. This will be different from
jarray in that you'll be able to use the raw CLR arrays w/o a wrapper. We
would then make slicing work on arrays by making them appear as
Thanks for the bug report - we actually still have a little cleanup to do in
the area of built-in functions, but it's great to have this one extra edge case
on the radar before we get there. I've filed the bug in our database but I'm
not entirely sure when we'll get to this one, but hopefully
Doh! Yep, I sure did.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J. Merrill
Sent: Tuesday, February 07, 2006 10:11 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Using IronPython classes in C#...
At 12:00 PM 2/7/2006, Dino Viehland wrote
Thanks for the bug report, I'll get it filed and it seems like we should be
able to get this one fixed for the next release.
This is just a problem with displaying the actual value to its full precision.
For example:
print '%g' % (eval('123.456E-19')*2)
Prints:
2.46912e-17
so the value is
Our VSIP teams SDK includes a sample
that integrates IronPython into VS. Aaron Marten has blogged about this here: http://blogs.msdn.com/aaronmar/ -
but I dont think its quite as easy as downloading a IronPython
Express SKU just yet
I also dont know if we have all the
niceties you want
The way you'll want to make an array is:
import System
System.Array.CreateInstance(System.Char, 3)
Where 3 is the number of elements in the array.
In the first case we're auto-marshalling your list into a byte[] array but we
auto-marshal in a zero-length byte array (because you gave us a
Soon indeed! We've got it fixed for the beta 3 release.
Do you want to help develop Dynamic languages on CLR?
(http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
This should work as you're doing it (the only curiosity I see is the
backslashes instead of the forward slashes). I'll need to investigate this one
and get back to you later today.
Do you want to help develop Dynamic languages on CLR?
The reason this is happening is due to the . in the filename - we end up seeing
that as an extension and the assembly load request comes in w/o the .DLL so we
don't try appending .DLL to do the load. It looks like we need to do that no
matter what. You can fix this by just removing the if
interface method?
Would it be reasonable to use syntax
this.DataGridView1[ISupportInitialize].BeginInit
to do the equivalent of casting to an interface in IP?
At 11:55 AM 2/16/2006, Dino Viehland wrote
The issue here is that the interface's methods are marked private, but are
exposed publicly via
There were a couple of bugs w/ assembly loading in beta 3.
As a work around you should be able to do:
import System
clr.AddReference(System.Reflection.Assembly.Load('System.Xml'))
clr.AddReference(System.Reflection.Assembly.LoadFrom('System.Xml'))
Because its written in C++ theyd
need to provide bindings for IronPython in addition to CPython. We dont
support the CPython plug-in interface so we wouldnt just work w/ it.
That means that basically theres no way itll work right now.
Do
you want to help develop Dynamic languages on
Thanks for the bug report - I've filed this one and we should be able to get it
fixed for beta 4.
Do you want to help develop Dynamic languages on CLR?
(http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
-Original Message-
From: [EMAIL
-DC1B43134038)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Thursday, February 23, 2006 2:23 PM
To: Discussion of IronPython
Subject: Re: [IronPython] New User
The tkinter module requires that we implement the _tkinter module in the
IronPython
What is throwing when you're trying to get __doc__ from it? In general all
methods and types should have __doc__ strings.The methods should include
all the possible overloads in the doc string. The types currently will
generally only have 'no documentation available'.
But one possibility
The first bug will be fixed in beta 4 - we've done a bunch of cleanup around
the file class to make it all around more compatible with CPython. That not
only includes fixing binary mode but also fixing universal new line mode to be
much more compatible. FYI beta 4 should be available real
Hello IronPython Community,
We have just released IronPython 1.0 Beta 4. This is yet
another release focusing primarily on fixing bugs. Since the beta 3 release
weve cut our active number of bugs in half. Unfortunately we
didnt get to review the PythonEngine APIs in this release but
We support some of these but not all of them right now. Currently these should
work:
__add__, __sub__, __pow__, __mul__, __floordiv__, __div__, __truediv__,
__mod__, __lshift__, __rshift__, __and__, __or__, __xor__, __lt__, __gt__,
__le__, __ge__, __eq__, and __ne__ and all of the r and i
You should be able to do:
import System
a = System.IO.FileStream('abc', System.IO.FileMode.Create)
file(a)
file 'F:\Product\IronPython\IronPython\abc', w+
That should work w/ a network stream as well, but the filename will show up as
nul in that case.
Do you want to help develop Dynamic
Thanks for the bug report Seo, we'll look into getting it 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-DC1B43134038)
-Original Message-
From: [EMAIL PROTECTED]
Strange, we pass the atexit test Ill
open a bug on this for us to look into.
Do
you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
From: [EMAIL PROTECTED]
[mailto:[EMAIL
Ultimately we want to replace gotdotnet.com w/ something that will enable this
but unfortunately we're still a couple of months away from doing that (at the
earliest).
Do you want to help develop Dynamic languages on CLR?
We do actually want to do a site redesign (and it's a known issue in our bug
database :) ) but it's just a matter of getting the resources to do so.
We'll get it updated before 1.0, but I'm not sure how much before 1.0 we'll get
it done.
Do you want to help develop Dynamic languages on CLR?
of IronPython
Subject: Re: [IronPython] TypeError: unbound method open must be called with
On 3/20/06, Dino Viehland [EMAIL PROTECTED] wrote:
but then we finally blow up because we don't support startfile on the os
module:
Thanks Dino. I was wondering about that.
webbrowser.open_new
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?
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
of Python, whatever can be done to work with the massive
amount of libraries will be the most beneficial.
I apologize if this is already addressed. I am thinking about issues such as
these from a python programmer's perspective.
Great work!
Eric
On 3/27/06, Dino
Viehland [EMAIL PROTECTED
Definitely a bug, I don't think we've seen this one before... Thanks for the
report.
I've got it filed in our bug database... I'm not sure if this will be in beta
5 or not as we're quickly nearing the time for another release but if the fix
is simple we'll try and get it in.
Do you want
). Despite this, I still like the decorator syntax.
-Nathan
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Monday, March 27, 2006 11:45 PM
To: Discussion of IronPython
Subject: Re: [IronPython] .NET Attributes
I like this too... It's
?)
At 11:30 AM 3/27/2006, Dino Viehland wrote
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
to this list and filing
bugs for IronPython, is there a place I can see the status or should I
just scan the release notes with each beta release to see when this gets
fixed?
Lewis
Dino Viehland wrote:
Definitely a bug, I don't think we've seen this one before... Thanks for
the report.
I've got
Are you running on Mono or Rotor on a Unix OS? If so we re-name nt to be unix
there.
Do you want to help develop Dynamic languages on CLR?
(http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
-Original Message-
From: [EMAIL PROTECTED]
-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathew Yeates
Sent: Wednesday, March 29, 2006 1:09 PM
To: Discussion of IronPython
Subject: Re: [IronPython] can't import nt
I'm running mono on Linux. I just tried import unix and that didnt
work either
Mathew
Dino Viehland
to see when this gets
fixed?
Lewis
Dino Viehland wrote:
Definitely a bug, I don't think we've seen this one before... Thanks for
the report.
I've got it filed in our bug database... I'm not sure if this will be in
beta 5 or not as we're quickly nearing the time for another release
There are two features that are required to support ASP.NET: CodeDom static
type compilation.
We have a pretty good implementation of CodeDom at this point. It is mostly
sufficient for both ASP.NET's code gen purposes as well as the VS WinForms
designer. It's probably less sufficient for
For double click / enter you should be able to right click on the script, see
Opens with on the General tab, select the Change button to the right, click
the Browse button on the bottom of the Open With dialog that opens, and then
find IronPythonConsole.exe in the file open dialog that comes
Title: Software Mind
Sorry Szymon, I believe this is my fault. We
did receive your report but somehow it didnt make it into a bug. Ive
got the bug opened now, and well fix this before beta 6. Again, sorry
for the delay on this.
Do
you want to help develop Dynamic languages on CLR?
At the console there's an easy workaround:
zip = zip
p = ((1,2),)
zip(*(p*10))
[(1, 1, 1, 1, 1, 1, 1, 1, 1, 1), (2, 2, 2, 2, 2, 2, 2, 2, 2, 2)]
zip(*(p*10))
[(1, 1, 1, 1, 1, 1, 1, 1, 1, 1), (2, 2, 2, 2, 2, 2, 2, 2, 2, 2)]
Unfortunately that doesn't help you in a module where we'll always
Title: Software Mind
Well, the goal is to keep the betas #s down
to just a single digit With releases every 3 weeks that should
give you some idea
Do
you want to help develop Dynamic languages on CLR?
This is the code the VSIP SDK generates w/
the IronPython integration sample:
self._menuStrip1 = System.Windows.Forms.MenuStrip()
self._fileToolStripMenuItem = System.Windows.Forms.ToolStripMenuItem()
self._menuStrip1.SuspendLayout()
self.SuspendLayout()
#
# menuStrip1
#
Thanks for following up on these Seo... They're all in the bug database and
we'll try and get them all fixed for beta 6.
Do you want to help develop Dynamic languages on CLR?
(http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
-Original
Posting new bugs is great! Thanks for reporting this.
I'll get this one filed away but it sounds sufficiently weird that it will
require some investigation before we know what's actually going on here.
Do you want to help develop Dynamic languages on CLR?
The issue here is w/ the timing of starting up the Winforms thread and
returning control back to your module. This will be fixed in beta 6, but you
can make the change to winforms.py yourself by adding the marked 4 lines:
from System.Drawing import Size
from System.Windows.Forms import Form,
This should work:
import clr
import System.Reflection
clr.AddReference(System.Reflection.Assembly.LoadFrom('/code/dlls/Microsoft.Office.Interop.PowerPoint.dll'));
clr.AddReference(System.Reflection.Assembly.LoadFrom('/code/dlls/office.dll));
import Microsoft.Office.Interop.PowerPoint as
Well, CPython at least still enforces the padding, even if it's ignoring the
invalid characters.
Here's Seo's repro 'simplified' to go straight to binascii (just to get to the
root API):
import binascii
binascii.a2b_base64('%')
''
And then sending a valid character, invalid padding:
Thanks for the bug report, we've got this one filed and should get it fixed for
beta 6.
Do you want to help develop Dynamic languages on CLR?
(http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
-Original Message-
From: [EMAIL
Thanks for the bug report. It
actually appears to be a bug in our method call logic, and is definitely and
interesting corner case.
In this case we think make_prop is a
method on the class DataType and we think when you call it with cls.()
that we should add cls in as the first instance
Thanks for the bug report, I've got it filed in our bug database.
My guess is that we'll be able to get this fixed for beta 6.
Do you want to help develop Dynamic languages on CLR?
(http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
You should be able to set Multiselect on
the FileOpenDialog to enable choosing of more than one file (although that may
not be exactly what youre wanting).
Unfortunately we dont have a way to
define the CommandMethod from Python because we dont yet support static
compilation custom
I've just got around to looking at this, and the repro isn't working for me on
beta 5. I've created a.py and b.py:
a.py:
from b import BClass
class AClass:
pass
b.py:
from a import AClass
class BClass:
pass
and then I get:
IronPython 1.0.2280 (Beta) on .NET 2.0.50727.32
Copyright
:, threadtime
On 3/31/06, Dino Viehland [EMAIL PROTECTED] wrote:
Hello IronPython Community,
We have just released IronPython 1.0 Beta 5. This release focuses primarily
on improving IronPython's performance. In this area we've reduced working
set and startup type by optimizing methods
That is related - for beta 6 we've actually added a large test set that
compares CPython IronPython results for comparing large numbers of types (and
classes pretending to be types) to make sure we get this nailed down, and this
appears to be one of the issues we've fixed while doing that.
Do
IronPython is slower to get things going the first time (because we end up
compiling to IL and then JITing the code); it's after that when we really start
to shine.
The first time you run this we will take longer to execute it, but if you do it
a second time we'll report zero. When I run it
This could be an order of finalization issue - if you let things shut down
entirely then all the finalizers in the system would be eligible to be run at
once. But if you dispose of the MetadataEditor by hand anything it depends
upon won't have its finalizer run yet.
At shutdown time the CLR
I believe most of what you're experiencing is the cost of being dynamic,
although we certainly have a lot of room for improvement here...
I looked at this under the profiler and there is some sillyness in IronPython
that can yield a ~10% perf gain on this micro benchmark (for example in place
.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Dino Viehland
Sent: Monday 17 April 2006 16:58
To: Discussion
of IronPython
Subject: Re: [IronPython] Are two
PythonEngine instances connected?
Yes, right now we unfortunately have some
shared state between them. Were not entirely
Trimble)
On 4/17/06, Dino Viehland [EMAIL PROTECTED] wrote:
Changing the code to do j = j + xyz yields about a 25% perf
improvement for me though.
Thanks for looking into this Dino. Oddly, I get the opposite result
for this case! I ran the test 3x with j = j + and 3x with j +=. I
got:
j = j
Yes, I would think the likelihood would be the two types being the same :) But
currently we check for int, BigInteger, and complex before we check for double
for some reason... it's just silly.
We don't currently do any magic w/ literals to treat them specially... They
just become objects
Yep, and this will be in beta 6. It was also reported to the www.gotdotnet.com
bug database a while ago.
Do you want to help develop Dynamic languages on CLR?
(http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
-Original Message-
: Wednesday, April 19, 2006 10:41 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Speed test
On 4/19/06, Dino Viehland [EMAIL PROTECTED] wrote:
Interop w/ C# shouldn't really cost you that much - it should actually be
able to give you speed gains as you fall back into the static world...
Do
, April 19, 2006 3:27 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Speed test
On 4/19/06, Dino Viehland [EMAIL PROTECTED] wrote:
If in initializeDB you comment out:
ipEngine1.SetVariable(pred_file, predfile);
ipEngine1.Execute(@db.load_predicates_file
Thanks for the report. This is another issue we've already fixed for beta 6 -
inheriting from a mix of new-style classes as well as old-style classes.
This was part of a large cleanup around __metaclass__ defined at the module
scope, support for __metaclass__ being a function, support for
Hello IronPython Community,
We have just released
IronPython 1.0 Beta 6. This release focuses primarily on fixing bugs and
improving compatibility with CPython. Major cleanups includes supporting
__metaclass__ at the module level, using __mro__ for new-style class method
resolution,
The speed improvements you're seeing here are likely the usage of our Reflect
Optimizer for all C# methods now. This gives a huge speed improvement in the
time it takes to call arbitrary C# code (previously we only optimized methods
in IronPython, as the optimizer was not able to handle a
Yes, we're aware of this - Current plan is to update the webpage before 1.0
final.
Do you want to help develop Dynamic languages on CLR?
(http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
-Original Message-
From: [EMAIL PROTECTED]
Thanks for the report Seo, we'll get this one fixed for the next release.
Do you want to help develop Dynamic languages on CLR?
(http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL
Again, thanks for the bug report (and thanks for keeping them coming!).
We should get this one fixed for beta 7.
Do you want to help develop Dynamic languages on CLR?
(http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
-Original
Thanks for the bug report. It’s
definitely broken although it’s not yet clear why (we translate this into the
appropriate .NET string formatting code which should work). I’ll open a
bug and it seems like we should be able to get this one fixed for beta 7.
Do
you want to help develop
We keep them separated to try and avoid
Python-isms in the IronMath library. Wed really like to see the
day when all languages have some shared concept of a BigInteger and Complex,
unfortunately these types are not available in the BCL.
Do
you want to help develop Dynamic languages on
On the recursion limits: Until beta 6 IronPython didn't have proper support
for limiting recursion depth. There was some minor support there, but it
wasn't right.
In beta 6 we have full support for limiting recursion depth, but by default we
allow infinite recursion. If the user explicitly
I suspect you're hitting cross-app domain issues. A quick search shows that
you need to have your assemblies in a bin directory for ASP.NET to find them,
but IronPython is going to generate its snippets.dll somewhere else (usually
the current working directory).
One thing you could try, not
You're on the right track. You'll probably want to create a seperate thread
for the PythonEngine to run on, and then whenever you get a write to your
stream you can just do a Control.Invoke onto your UI thread to update the
current output.
I was playing around w/ this around the 0.9.4
Thanks for the bug report Seo! I've got this one filed and hopefully we can
get to it for beta 7.
Do you want to help develop Dynamic languages on CLR?
(http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
-Original Message-
From: [EMAIL
Yep, you're correct - SystemState is currently a singleton for the entire
process. We'll actually have this fixed in beta 7 where the system state is
stored in a hidden spot in the module and we'll flow it as one module imports
another. That'll result in a set of modules being independent and
)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Szymon Kobalczyk
Sent: Thursday, April 27, 2006 10:10 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Generated IL is always using the standard input,
output and error streams.
Dino Viehland napisał
I've also opened a bug for supporting __getslice__ in IronPython.
Do you want to help develop Dynamic languages on CLR?
(http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL
Thanks for the bug report, we'll fix this for beta 7.
Do you want to help develop Dynamic languages on CLR?
(http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
It looks like we've actually got that one fixed for the upcoming beta 7. But
thanks for reporting it, and certainly keep them coming if you notice any more.
Do you want to help develop Dynamic languages on CLR?
Yep, we shouldn't be trying the conversion in this case, we'll get rid of this
feature. Thanks for the report.
Do you want to help develop Dynamic languages on CLR?
(http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
-Original Message-
There's a bug in beta 5 and beta 6 where we can sometimes fail to call the
correct derived method. You can work around the bug in many cases w/:
Class MyForm(Form):
def __init__(self):
self.OnKeyUp = self.OnKeyUp
def OnKeyUp(self, e):
...
This is something that were slowly
working on but may not have done in time for v1.0. We do have some compiler support
in IronPython, but the assemblies arent usable from C#. The challenge
here is mapping a highly dynamic language like Python into a world that C# can
see w/o altering the
Thanks for the bug report. This is due to the enabling of our optimized code
paths for all calls into C#. I'll get a bug on this one filed and it should be
fixed for beta 7 (tentatively scheduled for later this week).
Do you want to help develop Dynamic languages on CLR?
It's an implementation detail which may change in future versions.
There's a OrderedDict in the Python cookbook though that should work w/ IP.
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/438823
Do you want to help develop Dynamic languages on CLR?
1 - 100 of 1614 matches
Mail list logo
