Is it possible to add extensions to the list of file extensions that are
valid for importing? I am writing an application that I want to associate
.pyt/.pys files with and they are actually Python scripts that will be used
by the application via IronPython. I want to be able to allow importing of
o
Well, perhaps because I don't see the upside in breaking things, either. Where
I see an upside is in keeping people from taking inappropriate dependencies. :)
Making use of IronPython in Action, by the way. One thing that seems to be
missing from the hosting API discussion is talk about the Sc
"Must have a non-empty display name or a a non-empty list of language names"
Note the "a a".
Found while playing around with the hosting APIs.
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.
Note that you will have to set __metaclass__ to ClrMetaclass, not
ClrTypeMetaclass as in DevHawk's sample. I had changed the name of the type.
The old name will cause a NameError, but maybe SL is hiding exceptions. Can you
do "o.GetType().GetFields()" and display that on the page to inspect the
I have just found that the Silverlight binding does not work with this
version of clrtype and/or IronPython 2.6RC2.
I used DevHawk demo [1] and after I added reference to Microsoft.Dynamic
in clrtypemetaclass.py it worked flawlessly. But when I switch to your
version, no items show in the listbo
Leonides Saguisag wrote:
Hi Michael,
It seems to be a bug with IronPython 2.0.x then. I just installed IronPython
2.0.3 and this is what I found:
C:\>"C:\Program Files\IronPython 2.0.3\ipy.exe"
IronPython 2.0.3 (2.0.0.0) on .NET 2.0.50727.3603
Type "help", "copyright", "credits" or "license"
Hi Michael,
It seems to be a bug with IronPython 2.0.x then. I just installed IronPython
2.0.3 and this is what I found:
C:\>"C:\Program Files\IronPython 2.0.3\ipy.exe"
IronPython 2.0.3 (2.0.0.0) on .NET 2.0.50727.3603
Type "help", "copyright", "credits" or "license" for more information.
>>>
Leonides Saguisag wrote:
Hi Michael,
I am using SharpDevelop 3.1 which comes with "2.5.0 (IronPython 2.0.2 (2.0.0.0) on
.NET 2.0.50727.3603)".
Yeah, that's IronPython 2.0 - which is fine but not as good as
IronPython 2.6. ;-)
So this issue is resolved with IronPython 2.6, then?
No
Hi Michael,
I am using SharpDevelop 3.1 which comes with "2.5.0 (IronPython 2.0.2 (2.0.0.0)
on .NET 2.0.50727.3603)".
So this issue is resolved with IronPython 2.6, then?
Thanks!
-- Leo
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpytho
Leonides Saguisag wrote:
Hi Michael,
I just verified the empty string theory that you mentioned and
Python25\lib\codecs.py (comes with the standard library in Python 2.5) has the
following defined:
You're using IronPython 2.0 then?
If I use IronPython 2.6 it correctly reports a text file
Hi Michael,
I just verified the empty string theory that you mentioned and
Python25\lib\codecs.py (comes with the standard library in Python 2.5) has the
following defined:
# UTF-8
BOM_UTF8 = '\xef\xbb\xbf'
So it is not an empty string.
Maybe I am approaching this wrong and you guys can pro
Hmm... I certainly don't suggest that the dynamic languages team
*support* obsolete versions, but in my experience it is 'unusual' for an
open source project to make previously released code / binaries
*completely* unavailable - support notwithstanding.
For Python itself I believe you can down
Leonides Saguisag wrote:
Thank you for taking the time to reply. Any idea why this would happen in
IronPython but not with the standard Python interpreter? What is weirding me
out is that the exact same script behaves differently depending on whether I
use IronPython or the standard Python i
Thank you for taking the time to reply. Any idea why this would happen in
IronPython but not with the standard Python interpreter? What is weirding me
out is that the exact same script behaves differently depending on whether I
use IronPython or the standard Python interpreter.
Thanks!
-- Le
You're right .. the problem *is* a developer taking dependencies on specific
releases. Further, I contend that it's the developer taking dependencies on
experimental releases. That's improper, and why we as an industry label such
things with "alpha", "beta", "RC" and so forth. Each of those a
Leonides Saguisag wrote:
Hi everyone,
I am encountering a weird issue with getting to codecs.BOM_UTF8 to work
correctly. I am using SharpDevelop 3.1.
Here is the test script that I put together:
import sys
sys.path.append(r'D:\Python25\Lib')
import codecs
print sys.version
myfile = open(r'
Hi everyone,
I am encountering a weird issue with getting to codecs.BOM_UTF8 to work
correctly. I am using SharpDevelop 3.1.
Here is the test script that I put together:
import sys
sys.path.append(r'D:\Python25\Lib')
import codecs
print sys.version
myfile = open(r'D:\Temp\text_file_with_utf8
Just because we work for the same company doesn't mean we can convince CodePlex
to do some random work =P
For now, there's a list of supported releases here, for anyone who wants a
shorter list of releases.
http://ironpython.codeplex.com/wikipage?title=SupportedReleaseList. It's linked
to from
Tony Meyer wrote:
I'm not in blanket agreement here. I'd agree for some releases to be valid
dependency points, but things like RCs, betas, obsoleted third-level
versions -- not really.
Couldn't someone in the IronPython team talk to someone in the
CodePlex team and figure out a way for a
> I'm not in blanket agreement here. I'd agree for some releases to be valid
> dependency points, but things like RCs, betas, obsoleted third-level
> versions -- not really.
Couldn't someone in the IronPython team talk to someone in the
CodePlex team and figure out a way for all releases to be pe
Keith J. Farmer wrote:
As for the question at hand, though :)
I'm not in blanket agreement here. I'd agree for some releases to be
valid dependency points, but things like RCs, betas, obsoleted
third-level versions -- not really.
In the first two cases, those are bleeding-edge releases. I
As for the question at hand, though :)
I'm not in blanket agreement here. I'd agree for some releases to be valid
dependency points, but things like RCs, betas, obsoleted third-level versions
-- not really.
In the first two cases, those are bleeding-edge releases. If you take a
dependency
Kay Schluehr wrote:
Hi IronPython list,
I worked along Michael Foords introductory article about embedding
IronPython in Silverlight together with his
"EmbeddingIronPythonSilverlight" project documented here:
http://www.voidspace.org.uk/ironpython/silverlight/embedding_ironpython.shtml
I
Keith J. Farmer wrote:
"making releases that people / projects may have depended on is an unacceptable
cost"
You wanna rephrase that there, Michael? :)
Ha. :-)
making unavailable releases that people
Thanks
Michael
-Original Message-
From: users-boun...@lists.ironpython.com
"making releases that people / projects may have depended on is an unacceptable
cost"
You wanna rephrase that there, Michael? :)
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Monday, November 09,
The restrictions are per-subclass so for example you cannot inherit
from both a list and tuple. The reason here is that list and tuple both
have their own independent layout in memory and there's no relationship
between them. Or in your case it's set and float.
CompileSubclassTypes takes an arbi
Thanks the reply,
Could you clarify slightly what you mean by the Python's normal
restrictions. I was guessing the restriction might be something like:
"When compiling a list of types, if the list contains a class B which
inherits from A then A must be contained in the list."
The interestin
The only restrictions are the normal restrictions that Python has regarding
inheritance. In this case it looks like you're hitting that you cannot
inherit from more than one base type w/ a different layout.
Basically it looks like you're trying to pre-compile the equivalent of:
class c(float, s
Hi,
Are there any restrictions placed on the list of types that can be
passed to CompileSubclassTypes?
We are having issues with a clr.AddReference(DllContainingSubclasses)
being very slow, so are trying to split the compiled subclasses across
multiple dlls to indicate progress between the l
29 matches
Mail list logo