os.strerror is not implemented. Something as simple as the following woud work:
import os
import errno
def strerror(code):
if code == errno.ENOENT:
return 'No such file or directory'
elif code == errno.EACCES:
return 'Permission denied'
else:
return 'Unknown
Following program prints different result between CPython and IronPython:
def f(): pass
print type(f).__module__
CPython: __builtin__
IronPython: property# __module__ on function
This breaks codes which assume __module__ is a string.
--
Seo Sanghyeon
Hi!
IronPython has poor support of COM techno. In particular, IP can not use
dynamic COM servers (perhaps because they do not have TLB?).
Now, cPython is good to create dynamic COM servers (see Python Programming
on Win32, page 219 +).
Thus, ironPython is bad, to use the COM servers made
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/54926.
MODIFIED SOURCES
Or there's always:
import nt
import errno
for x in dir(errno):
val = getattr(errno, x)
if type(val) is int:
print ('case PythonErrorNumber.%s: return ' + nt.strerror(val) +
';') % x
:)
-Original Message-
From: users-boun...@lists.ironpython.com
I have developed a Silverlight application that uses IronPython to
dynamically generate and execute a script. The script is dependent on
data supplied by the user and can be computationally expensive so it's
run on a separate thread. I need an option for the user to abort the
script in case it
Looks like this is because type.__module__ is not a data descriptor.
I believe I have a fix.
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Seo Sanghyeon
Sent: Wednesday, June 17, 2009 3:04 AM
To: Discussion of
What is the status of referencing IPy libraries compiled to dlls by other
CLR languages? Google turned up that as of 1.1 you had to use the
embedding/hosting api's, since the dlls were not compatible with say C#
assemblies. There were allusions made to this being changed.
I would think that you would always need the DLR at least because of
the references that the compiled dlls would have.
On Wed, Jun 17, 2009 at 4:45 PM, Justin Regelejregel...@gmail.com wrote:
What is the status of referencing IPy libraries compiled to dlls by other
CLR languages? Google turned
Justin Regele wrote:
What is the status of referencing IPy libraries compiled to dlls by
other CLR languages? Google turned up that as of 1.1 you had to use
the embedding/hosting api's, since the dlls were not compatible with
say C# assemblies. There were allusions made to this being changed.
There are so many different .NET versions -- I suppose that somewhere in
msdn there is an explanation of the differences -- but I have often wondered
why IronPython used 2.0 when 3.5 is available. Just idle curiosity, I don't
really care, but if there are significant new features, will IronPython
Good point!
On Wed, Jun 17, 2009 at 5:12 PM, Michael Foord fuzzy...@voidspace.org.ukwrote:
Curt Hagenlocher wrote:
...except through the hosting API *and through the new C# dynamic
functionality in .NET 4.0*.
And how do you get to the classes to use them with the new dynamic
This brings up another question I've encountered. My understanding was that
IPy had problems with 3.5, and so I have been targeting 2.0. But when I try
to reference the IronPython and Microsoft.Scripting assemblies, Visual
Studio says I need 3.5
On Wed, Jun 17, 2009 at 6:05 PM, Curt Hagenlocher
Hi All,
This is not a SPAM. It's a one time message to all...
This may be wrong place to introduce my blog.
If you are interested in technical knowledge sharing and wanted to know
about new software's and more,
Just visit
http://www.aloysiusjegan.com/blog/
If you find this blog will be useful
14 matches
Mail list logo
