On Thu, Nov 13, 2008 at 12:40 AM, Dan Eloff <[EMAIL PROTECTED]> wrote:
>
> The first seems to me an extension of the ancient argument that you
> should not be trusted with fire because you might burn yourself. It's
> a fud appeal, not an argument.
Ever used Ruby? ;)
Although I was very skeptical
These sound good. Can you file them on CodePlex, please?
On Thu, Nov 13, 2008 at 3:32 AM, Vernon Cole <[EMAIL PROTECTED]> wrote:
> Some time back contributors to this forum were invited to suggest which
> Python3k and Python 2.6 functions were most important to implement in the
> next IronPython
I don't think either of those would cause such a large difference. I/O should
be the same. Two other differences I've noticed but again I wouldn't expect
them to matter. The first is a lack of [STAThread] attribute on Main. The 2nd
is you don't need the ScriptRuntime runtime = Python.CreateR
Some time back contributors to this forum were invited to suggest which
Python3k and Python 2.6 functions were most important to implement in the
next IronPython.
I downloaded Python 2.6 and Python3.0RC2 today and started hacking at making
adodbapi work in Python 3. (Now that it works in Iron, py
Interesting points... we do currently share types for built-in types between
objects. But we could still have per-ScriptRuntime extensions for them. We
actually support this today w/ our ExtensionTypeAttribute (which you could use
to do this but you'd need to write the extensions in C#). But
On Wed, Nov 12, 2008 at 4:19 PM, Dino Viehland <[EMAIL PROTECTED]> wrote:
> Actually I'd say modifying built-in types is unpythonic - for example you
> can't do object.xyz = 42. We could choose to break this rule for types we
> don't share between Python & .NET, and it probably wouldn't be a lot
I set the ModuleBuiltins compiler option but the behavior is the same. The
only difference from the command line is that I am calling a python function
from the DLR, and on the command line I am just calling the method from
__main__. Do you think could be an issue? The other thing is that the
py
Actually I'd say modifying built-in types is unpythonic - for example you can't
do object.xyz = 42. We could choose to break this rule for types we don't
share between Python & .NET, and it probably wouldn't be a lot of work, but I'm
hesitant to have the two sets of types treated differently.
I was doing some cross WPF/Silverlight work, and invariably I had to
pepper the code with if sys.platform == 'silverlight' use silverlight
api, else use different wpf api for the same task. That approach goes
back to C and beyond, and is unpythonic. Refactoring to create a
common api for dealing wi
Thanks Dino, that's a great explanation. Now I know where to use each
of the AddReference methods. Thanks also for the debugging tips, I
managed to figure out what the problem was, I specified x86 platform
(thinking silverlight is exclusively 32bit) but you have to leave it
as Any CPU or the assemb
The only thing that immediately pops out at me as being different is we also
set ModuleOptions.ModuleBuiltins in the command line case - but I wouldn't
expect it to make such a large difference. But try setting that option as well
and let's see what happens.
From: [EMAIL PROTECTED] [mailto:[EM
Thanks. Performance improved, but still over two minutes. Here is the
latest code:
static void Main(string[] args)
{
ScriptRuntime runtime = Python.CreateRuntime();
ScriptEngine engine = Python.CreateEngine();
ScriptSource source =
engine.Create
Oh, sorry, I missed a step... You'll need to call
ScriptEngine.GetCompilerOptions(). Cast that to a PythonCompilerOptions, and
then do options.Module |= ModuleOptions.Optimized; Finally do
source.Compile(options) and then it should give you the optimized code.
From: [EMAIL PROTECTED] [mailto
Thanks!.
I was able to get the default scope from CompiledCode, but I am still
getting the same performance. Here is the latest code :
static void Main(string[] args)
{
ScriptRuntime runtime = Python.CreateRuntime();
ScriptEngine engine = Python.CreateEngine
AddReference(str) will first try Assembly.Load and then try
Assembly.LoadWithPartialName - this should mean that trying w/ the strong name
won't do anything because LoadWithPartialName will do that for you. This is
kind of the one-stop shopping for loading assemblies in the GAC or the app
base
CompiledCode exposes the default scope it executes in via the DefaultScope
property. So hold onto the result of source.Compile and after executing the
code you can grab the scope and use it to get your variable.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wilfredo Lugo
Sent:
Thanks.
But then If I don't use my defined scope, how I could fill my function
delegate?
Right now I am using :
Microsoft.Func func =
scope.GetVariable>("interpolate_start");
If I use engine.GetVariables() I still need to pass a ScriptScope
to it. How do I get the default scope (from ScriptEngi
Instead of doing:
ScriptScope scope = engine.CreateScope();
Console.WriteLine(DateTime.Now);
source.Execute(scope);
do:
source.Compile().Execute()
and your code should then run in an optimized default scope for the code - just
like it does at
There's half a dozen add reference methods in the clr module, I'm
guessing they all have their differences, but I'm not really sure why
you would use one over the other. I generally try AddReference first,
if that doesn't work I try it using the strong name, failing that I
fall back to AddReference
I run the script directly from ipy.exe and it basically behaves pretty
similar to python.exe (it always took one second more, but I could live with
that). Here is the output:
$ date +%M:%S;./ipy.exe interpolate.py;date +%M:%S
17:36
WARNING: desired starting time (Tue Jan 01 00:00:21 2008) prior t
How does python.exe compare directly to ipy.exe? That is, try running "date
+%M:%S;ipy.exe interpolate.py;date +%M:%S" instead of using the DLR hosting
APIs.
Thanks,
Dave
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wilfredo Lugo
Sent: Wednesday, November 12, 2008 8:32 AM
To:
Hi All,
I have a Python interpolation script which basically reads data from a file
and perform a linear interpolation of the data present on the file. I have
been using this script for some time. Right now I am working on a C#
application that also performs linear interpolation, so I decided to
2008/11/12 Michael Foord <[EMAIL PROTECTED]>:
> In general it is great - IronPython samples *should* follow PEP 8 as much as
> possible (how come Ruby guys got nice method aliasing and we didn't by the
> way? Hmm... maybe excessive aliasing isn't Pythonic).
I agree. IronRuby's "rubification" of me
23 matches
Mail list logo
