Re: [IronPython] String Replacement
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 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 Behalf Of Lewis Franklin Sent: Tuesday, March 28, 2006 8:09 AM To: users@lists.ironpython.com Subject: [IronPython] String Replacement I encountered a problem working with IronPython the other day and wanted to post to see if anyone else has experienced this problem and if it may be a bug: '%02d' % 1 '01' '%02d' % 12 '012' Expected Result: '%02d' % 12 '12' Lewis Franklin ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] strange behavior with CLR types
The behavior of comparison with CLR types is not consistent. I'm using
beta4 on Windows:
from System import *
UInt64.Parse('0') == 0
False
UInt32.Parse('0') == 0
False
UInt16.Parse('0') == 0
False
Int16.Parse('0') == 0
False
Int32.Parse('0') == 0
True
Int64.Parse('0') == 0
True
-arman
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET Attributes
The usage of decorators on classes is interesting, and is worth a follow up to
the python mailing lists...
There's actually a lot of interesting problems like what you describe below w/
attributes and runtime vs. compile time. For example if we were to do a from
__experimental__ import ... for optional static typing
(http://www.artima.com/weblogs/viewpost.jsp?thread=89161) then we'd have a
similar tension between doing things at runtime vs. compile time - as it's
really still runtime logic that's being added..
For the most part I believe we can get the best of both worlds here. For
example even though we'd be statically compiling types somewhere in the
generated code is still the body used for module initialization. This code
runs at import time just like it would w/ a normal python module.
Likewise there are also still executable class statements (these would turn
into CLR class initializers) and these would run when a class statement
normally would run.
The reason why I mention these is that when these run we can check and see if
the static compiler made the right decisions and fix anything it did wrong at
runtime. To take an example that is simpler than attributes:
class foo(object):
if False:
def bar(self):
print Hello world!
Anyone who tries to call bar on an instance of a foo should get an exception.
The static transformation of that would be into something like this:
class foo {
Dict myDict;
static foo(){
myDict = new Dict();
if(false){
myDict['bar'] = new ReflectedMethod(foo.bar);
}
}
public object bar(){
if(myDict['bar'] == null) throw MissingMemberException();
if(myDict['bar'] == bar) { // or something...
Ops.Print('hello world');
return null;
} else {
return Ops.Call(barFunc);
}
}
}
Attributes here are trickier but could be handled in a similar fashion. But in
this case we'd need to generate a new class at runtime that contains the
correct attributes, and prevent the C# code from getting an instance of the
statically compiled class (e.g. by throwing an exception whenever it gets
created). That means we've effectively pushed ourselves all the way back to
the fully dynamic experience but that's better than being wrong.
In general we don't want to trade off ANY of the runtime facilities of Python
to make this happen. Instead we want to retain all of those capabilities while
generating IL Metadata that allows other statically typed languages to
consume the less-dynamic portions of the language. In other words if a Python
programmer can tell we compiled the code statically at runtime we've made a
mistake.
But doing all of this is a lot of work... There's a reason we don't have it
yet :).
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 Behalf Of Ernst, Nathan
Sent: Tuesday, March 28, 2006 5:42 AM
To: Discussion of IronPython
Subject: Re: [IronPython] .NET Attributes
I wouldn't give up completely on using decorators for classes. True,
Python 2.4 doesn't support them on classes, only functions. I think
consistency should be sought here.
After reading PEP 318 (http://www.python.org/dev/peps/pep-0318/) a
little closer, I noticed that there *are* some examples of using
decorators on classes. (See examples 2 and 5 at the end of the PEP).
While not included in 2.4, I could not find if it has been ruled out as
a later enhancement.
Note that there may be a potential problem using decorator syntax for
attributes. In CPython, a decorator is merely a syntactical shortcut
for applying a function to a function definition. It could be said
that, in IronPython, the attribute is being applied to a function. To
me, this seems kind of confused, as the attribute descriptor now becomes
a special case descriptor for the interpreter to have to handle because
the descriptor is not being called with the function/class definition as
an argument. Instead, the attributes must be compiled into the
generated code.
It is probably not that large of a deal, though. (Just playing devil's
advocate here). 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 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
Re: [IronPython] Updating globals()
What makes running from file work differently than the console? Are there
possibly other similar issues? (Failing from the console while working from
file is the more common issue, isn't it, in CPython?)
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/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanghyeon Seo
Sent: Monday, March 27, 2006 12:26 AM
To: Discussion of IronPython
Subject: [IronPython] Updating globals()
Updating module-level globals() raises AttributeError.
vars = {'a': 1, 'b': 2}
globals().update(vars)
print a, b
Seo Sanghyeon
J. Merrill / Analytical Software Corp
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Updating globals()
When you are running from a module we generate a module type which is a
subclass of CustomDict. That CustomDict stores the field values as static
variables which allows quicker access than requiring a dictionary lookup each
time through (in particular the module gets to just do a ldsfld / stsfld in IL
to get the value, but setting the value from outside of the module is still
relatively expensive).
At the console the dictionary is really just a standard dict object, so of
course that one works!
It turns out that we were missing the update method on the custom dict classes.
We currently run our entire test suite through 2 modes: one mode is generate as
snippets mode which is the same as if you were typing code in at the console.
This mode is optimized to not create new types (which the CLR cannot garbage
collection). This is also the mode that gets used when executing code
dynamically via eval. The other is our normal mode where imported modules get
compiled into real types. This mode is optimized for performance.
We introduced the two-sets of test passes after the console regressions in beta
1. In this case we're just missing some coverage of doing update on the
dictionary returned from globals() so we hadn't seen it.
The final thing for us to review is making sure our custom dictionaries have
ALL the functionality that our normal dictionaries have, and of course we'll do
that as part of fixing this bug (and put in place a test case to catch any
future regressions).
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 Behalf Of J. Merrill
Sent: Tuesday, March 28, 2006 2:59 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Updating globals()
What makes running from file work differently than the console? Are there
possibly other similar issues? (Failing from the console while working from
file is the more common issue, isn't it, in CPython?)
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/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanghyeon Seo
Sent: Monday, March 27, 2006 12:26 AM
To: Discussion of IronPython
Subject: [IronPython] Updating globals()
Updating module-level globals() raises AttributeError.
vars = {'a': 1, 'b': 2}
globals().update(vars)
print a, b
Seo Sanghyeon
J. Merrill / Analytical Software Corp
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] String Replacement
This will be fixed in beta 5 - it turns out if the number was zero padded we would always do the alternate form (ensuring the leading zero was present) which is wrong. 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 Behalf Of Lewis Franklin Sent: Tuesday, March 28, 2006 8:36 AM To: Discussion of IronPython Subject: Re: [IronPython] String Replacement Thanks for the quick response. Since I'm new 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 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 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 Behalf Of Lewis Franklin Sent: Tuesday, March 28, 2006 8:09 AM To: users@lists.ironpython.com Subject: [IronPython] String Replacement I encountered a problem working with IronPython the other day and wanted to post to see if anyone else has experienced this problem and if it may be a bug: '%02d' % 1 '01' '%02d' % 12 '012' Expected Result: '%02d' % 12 '12' Lewis Franklin ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com __ This e-mail has been scanned by MCI Managed Email Content Service, using Skeptic(tm) technology powered by MessageLabs. For more information on MCI's Managed Email Content Service, visit http://www.mci.com. __ ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] os.chdir - An elementary question.
Hello, I have an elementary question. I want to use os.chdir. In IronPython, it seems os.chdir has been disabled: IronPython 1.0.2258 (Beta) on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. import sys sys.path.append(r'C:\Python24\Lib') import os os.chdir(r'C:\tmp') Traceback (most recent call last): File , line 0, in input##339 AttributeError: 'module' object has no attribute 'chdir' os.getcwd() 'C:\\IronPython-1.0-Beta4' Let me know any workaround of it. Thanks in advance. Regards, ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] os.chdir - An elementary question.
2006/3/29, HEMMI, Shigeru [EMAIL PROTECTED]:
I want to use os.chdir.
It's not included in Beta 4, but you can add it easily.
--- IronPython/Modules/nt.cs.orig 2006-03-08 11:11:30.0 +0900
+++ IronPython/Modules/nt.cs2006-03-29 11:48:59.0 +0900
@@ -148,2 +148,7 @@
+[PythonName(chdir)]
+public static void SetCurrentDirectory(string path) {
+Directory.SetCurrentDirectory(path);
+}
+
[PythonName(listdir)]
Open Src\IronPython\Modules\nt.cs and add chdir function as above and
rebuild. IronPython ReadMe includes instruction to rebuild from the
source.
I'm sure ever great IronPython team will fix this in the next release! :-)
Seo Sanghyeon
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] os.chdir - An elementary question.
Thanks, I was able to do it very easily:
IronPython 1.0.2279 (Beta) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
import nt
nt.chdir(r'C:\tmp')
nt.getcwd()
'C:\\tmp'
Best Regards,
2006/3/29, Sanghyeon Seo [EMAIL PROTECTED]:
2006/3/29, HEMMI, Shigeru [EMAIL PROTECTED]:
I want to use os.chdir.
It's not included in Beta 4, but you can add it easily.
--- IronPython/Modules/nt.cs.orig 2006-03-08 11:11:30.0 +0900
+++ IronPython/Modules/nt.cs2006-03-29 11:48:59.0 +0900
@@ -148,2 +148,7 @@
+[PythonName(chdir)]
+public static void SetCurrentDirectory(string path) {
+Directory.SetCurrentDirectory(path);
+}
+
[PythonName(listdir)]
Open Src\IronPython\Modules\nt.cs and add chdir function as above and
rebuild. IronPython ReadMe includes instruction to rebuild from the
source.
I'm sure ever great IronPython team will fix this in the next release! :-)
Seo Sanghyeon
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
