[IronPython] clr.CompileSubclassTypes restrictions on list of types
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 loading of these dlls. However, when trying to compile a partial list of types we get the following error: Traceback (most recent call last): File c:\buildshare\gitrepo\precompile_subclasses.py, line 40, in c:\buildsha re\gitrepo\precompile_subclasses.py TypeError: : can only extend one CLI or builtin type, not both Microsoft.Scripti ng.Runtime.Extensible`1[[System.Double, mscorlib, Version=2.0.0.0, Culture=neutr al, PublicKeyToken=b77a5c561934e089]] (for IronPython.Runtime.Types.PythonType) and IronPython.Runtime.SetCollection (for IronPython.Runtime.Types.PythonType) Any help is much appreciated, Tom ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] clr.CompileSubclassTypes restrictions on list of types
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, set): pass Which isn't legal in Python so my guess is there is an issue w/ the way you split them up. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Tom Wright Sent: Tuesday, November 10, 2009 9:39 AM To: Discussion of IronPython Subject: [IronPython] clr.CompileSubclassTypes restrictions on list of types 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 loading of these dlls. However, when trying to compile a partial list of types we get the following error: Traceback (most recent call last): File c:\buildshare\gitrepo\precompile_subclasses.py, line 40, in c:\buildsha re\gitrepo\precompile_subclasses.py TypeError: : can only extend one CLI or builtin type, not both Microsoft.Scripti ng.Runtime.Extensible`1[[System.Double, mscorlib, Version=2.0.0.0, Culture=neutr al, PublicKeyToken=b77a5c561934e089]] (for IronPython.Runtime.Types.PythonType) and IronPython.Runtime.SetCollection (for IronPython.Runtime.Types.PythonType) Any help is much appreciated, Tom ___ 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] clr.CompileSubclassTypes restrictions on list of types
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 interesting thing here is that the call to CompileSubclassTypes works when we pass it one huge list of types, but not when we call if repeatedly with smaller lists. Thanks Tom Dino Viehland wrote: 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, set): pass Which isn't legal in Python so my guess is there is an issue w/ the way you split them up. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Tom Wright Sent: Tuesday, November 10, 2009 9:39 AM To: Discussion of IronPython Subject: [IronPython] clr.CompileSubclassTypes restrictions on list of types 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 loading of these dlls. However, when trying to compile a partial list of types we get the following error: Traceback (most recent call last): File c:\buildshare\gitrepo\precompile_subclasses.py, line 40, in c:\buildsha re\gitrepo\precompile_subclasses.py TypeError: : can only extend one CLI or builtin type, not both Microsoft.Scripti ng.Runtime.Extensible`1[[System.Double, mscorlib, Version=2.0.0.0, Culture=neutr al, PublicKeyToken=b77a5c561934e089]] (for IronPython.Runtime.Types.PythonType) and IronPython.Runtime.SetCollection (for IronPython.Runtime.Types.PythonType) Any help is much appreciated, Tom ___ 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 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] clr.CompileSubclassTypes restrictions on list of types
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 arbitrary number of parameters and those can be either a type (which gets compiled) or they can be a tuple of types which specify the collection of base types. The latter form is generally useful for including .NET interfaces. So clr.CompileSubclassTypes(foo, (set, float)) will fail as this is specifying that you want 1 class which inherits from both set and float. But you can do clr.CompileSubclassTypes(foo, set, float) and this specifies what you want 2 types, one that inherits from set and float. Or you can do: clr.CompileSubclassTypes(foo, (set, ), (float, )) and again that'll work because it's specifying 2 different base types. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Tom Wright Sent: Tuesday, November 10, 2009 10:08 AM To: Discussion of IronPython Subject: Re: [IronPython] clr.CompileSubclassTypes restrictions on list of types 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 interesting thing here is that the call to CompileSubclassTypes works when we pass it one huge list of types, but not when we call if repeatedly with smaller lists. Thanks Tom Dino Viehland wrote: 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, set): pass Which isn't legal in Python so my guess is there is an issue w/ the way you split them up. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Tom Wright Sent: Tuesday, November 10, 2009 9:39 AM To: Discussion of IronPython Subject: [IronPython] clr.CompileSubclassTypes restrictions on list of types 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 loading of these dlls. However, when trying to compile a partial list of types we get the following error: Traceback (most recent call last): File c:\buildshare\gitrepo\precompile_subclasses.py, line 40, in c:\buildsha re\gitrepo\precompile_subclasses.py TypeError: : can only extend one CLI or builtin type, not both Microsoft.Scripti ng.Runtime.Extensible`1[[System.Double, mscorlib, Version=2.0.0.0, Culture=neutr al, PublicKeyToken=b77a5c561934e089]] (for IronPython.Runtime.Types.PythonType) and IronPython.Runtime.SetCollection (for IronPython.Runtime.Types.PythonType) Any help is much appreciated, Tom ___ 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 ___ 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] IronPython 2.6 RC 1 Release Hidden
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, 2009 1:47 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.6 RC 1 Release Hidden Jimmy Schementi wrote: I agree, but I think the desire it to keep that Releases list clean. Otherwise it would have every release ever in there. It's a CodePlex limitation that there is no way to hide those releases from that list, while still keeping the links active. I understand the motivation, but making releases that people / projects may have depended on is an unacceptable cost in my opinion. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython 2.6 RC 1 Release Hidden
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 [mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Monday, November 09, 2009 1:47 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.6 RC 1 Release Hidden Jimmy Schementi wrote: I agree, but I think the desire it to keep that Releases list clean. Otherwise it would have every release ever in there. It's a CodePlex limitation that there is no way to hide those releases from that list, while still keeping the links active. I understand the motivation, but making releases that people / projects may have depended on is an unacceptable cost in my opinion. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Fail to execute import System on Silverlight embedded interpreter
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 added the following two lines to the source code
source = pe.CreateScriptSourceFromString(import System,
SourceCodeKind.Statements);
source.Execute(scope);
This worked all well with the given built and the shipped assemblies.
Yesterday I downloaded the DLR dlr-34133, built it and replaced the
assemblies of the EmbeddingIronPython... project with the latest
SilverlightDebug ones. Running the code
again I get following import error:
System.NullReferenceException wurde nicht von Benutzercode behandelt.
Message=Der Objektverweis wurde nicht auf eine Objektinstanz
festgelegt.
StackTrace:
bei
Microsoft.Scripting.Silverlight.DynamicApplication.get_BaseUri()
bei
Microsoft.Scripting.Silverlight.DynamicApplication.MakeUri(Uri
baseUri, Uri relativeUri)
bei
Microsoft.Scripting.Silverlight.HttpVirtualFilesystem.GetFileInternal(Object
baseUri, Uri relativeUri)
bei
Microsoft.Scripting.Silverlight.BrowserVirtualFilesystem.GetFileInternal(Object
storageUnit, String relativePath)
bei
Microsoft.Scripting.Silverlight.BrowserVirtualFilesystem.GetFile(Object
storageUnit, String relativePath)
bei
Microsoft.Scripting.Silverlight.BrowserVirtualFilesystem.GetFile(String
relativePath)
bei Microsoft.Scripting.Silverlight.BrowserPAL.FileExists(String
path)
bei IronPython.Runtime.Importer.LoadModuleFromSource(CodeContext
context, String name, String path)
bei
IronPython.Runtime.Importer.LoadPackageFromSource(CodeContext context,
String name, String path)
bei IronPython.Runtime.Importer.LoadFromDisk(CodeContext
context, String name, String fullName, String str)
bei IronPython.Runtime.Importer.ImportFromPathHook(CodeContext
context, String name, String fullName, List path, Func`5 defaultLoader)
bei IronPython.Runtime.Importer.ImportFromPath(CodeContext
context, String name, String fullName, List path)
bei IronPython.Runtime.Importer.ImportTopAbsolute(CodeContext
context, String name)
bei IronPython.Runtime.Importer.ImportModule(CodeContext
context, Object globals, String modName, Boolean bottom, Int32 level)
bei IronPython.Modules.Builtin.__import__(CodeContext context,
String name, Object globals, Object locals, Object fromlist, Int32 level)
InnerException:
Apparently, pre-loading assemblies in the loop
foreach (string name in new string[] { mscorlib, System,
System.Windows, System.Windows.Browser, System.Net })
{
runtime.LoadAssembly(runtime.Host.PlatformAdaptationLayer.LoadAssembly(name));
}
had no effect and IronPython attempts to load the 'System' module from
the disk as a Python module. The standard import
routine import clr; clr.AddReference(System); import System causes
the same problem. I'm puzzled.
I've had horrible problems with imports in Silverlight when using
embedded IronPython and didn't really get any good answers I'm afraid. :-(
Michael
Regards, Kay
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.ironpythoninaction.com/
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython 2.6 RC 1 Release Hidden
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 on them, expect to bleed. In the latter case, I wouldn't expect API differences, or other breaking changes unless they represented critical bug fixes. Again, I wouldn't want to support a dependency upon something horribly broken. In light of the above, then, I'd propose keeping the following versions: max(x).y.max(z)[.max(b)] and strongly consider keeping: [max(x)-1].y.max(z)[.max(b)] From: users-boun...@lists.ironpython.com on behalf of Michael Foord Sent: Tue 11/10/2009 11:25 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.6 RC 1 Release Hidden 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 [mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Monday, November 09, 2009 1:47 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.6 RC 1 Release Hidden Jimmy Schementi wrote: I agree, but I think the desire it to keep that Releases list clean. Otherwise it would have every release ever in there. It's a CodePlex limitation that there is no way to hide those releases from that list, while still keeping the links active. I understand the motivation, but making releases that people / projects may have depended on is an unacceptable cost in my opinion. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.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
Re: [IronPython] IronPython 2.6 RC 1 Release Hidden
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. If you take a dependency on them, expect to bleed. The problem is that if a developer has used (and depended on) APIs in a specific release of IronPython then the person who bleeds is likely to be an end user rather than the developer (who may have moved onto other things without updating their project). I don't have a problem with relegating obsolete releases to a small corner, but making them unavailable altogether is a high cost. Michael In the latter case, I wouldn't expect API differences, or other breaking changes unless they represented critical bug fixes. Again, I wouldn't want to support a dependency upon something horribly broken. In light of the above, then, I'd propose keeping the following versions: max(x).y.max(z)[.max(b)] and strongly consider keeping: [max(x)-1].y.max(z)[.max(b)] *From:* users-boun...@lists.ironpython.com on behalf of Michael Foord *Sent:* Tue 11/10/2009 11:25 AM *To:* Discussion of IronPython *Subject:* Re: [IronPython] IronPython 2.6 RC 1 Release Hidden 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 [mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Monday, November 09, 2009 1:47 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.6 RC 1 Release Hidden Jimmy Schementi wrote: I agree, but I think the desire it to keep that Releases list clean. Otherwise it would have every release ever in there. It's a CodePlex limitation that there is no way to hide those releases from that list, while still keeping the links active. I understand the motivation, but making releases that people / projects may have depended on is an unacceptable cost in my opinion. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.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 -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython 2.6 RC 1 Release Hidden
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 permanently available without them cluttering up lists that most people would see? i.e. links to alpha (etc) versions would still work, and you could create a list of all releases, but normal users browsing the site would only see the latest (and latest major-1) version? Cheers, Tony ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython 2.6 RC 1 Release Hidden
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 all releases to be permanently available without them cluttering up lists that most people would see? i.e. links to alpha (etc) versions would still work, and you could create a list of all releases, but normal users browsing the site would only see the latest (and latest major-1) version? I think this has been fixed already on the IronPython codeplex site (releases unhidden). All the best, Michael Cheers, Tony ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Weird issue with codecs.BOM_UTF8
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_bom.txt', 'r')
lines = myfile.readlines()
myfile.close()
if lines[0].startswith(codecs.BOM_UTF8):
print ('UTF-8 BOM detected!')
else:
print ('UTF-8 BOM not detected!')
myfile = open(r'D:\Temp\text_file_without_utf8_bom.txt', 'r')
lines = myfile.readlines()
myfile.close()
if lines[0].startswith(codecs.BOM_UTF8):
print ('UTF-8 BOM detected!')
else:
print ('UTF-8 BOM not detected!')
If I run the executable that I get from SharpDevelop this is what I get:
bin\Debug Test.exe
2.5.0 ()
UTF-8 BOM detected!
UTF-8 BOM detected!
But if I run the same script using the standard python interpreter, this is
what I get:
bin\Debug D:\Python25\python.exe ..\..\Program.py
2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)]
UTF-8 BOM detected!
UTF-8 BOM not detected!
The script works correctly with the standard python interpreter but for some
reason is not working right with IronPython.
Any ideas what is going wrong?
Thanks!
Best regards,
-- Leo
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Weird issue with codecs.BOM_UTF8
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'D:\Temp\text_file_with_utf8_bom.txt', 'r')
lines = myfile.readlines()
myfile.close()
if lines[0].startswith(codecs.BOM_UTF8):
print ('UTF-8 BOM detected!')
else:
print ('UTF-8 BOM not detected!')
myfile = open(r'D:\Temp\text_file_without_utf8_bom.txt', 'r')
lines = myfile.readlines()
myfile.close()
if lines[0].startswith(codecs.BOM_UTF8):
print ('UTF-8 BOM detected!')
else:
print ('UTF-8 BOM not detected!')
If I run the executable that I get from SharpDevelop this is what I get:
bin\Debug Test.exe
2.5.0 ()
UTF-8 BOM detected!
UTF-8 BOM detected!
But if I run the same script using the standard python interpreter, this is
what I get:
bin\Debug D:\Python25\python.exe ..\..\Program.py
2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)]
UTF-8 BOM detected!
UTF-8 BOM not detected!
The script works correctly with the standard python interpreter but for some
reason is not working right with IronPython.
Any ideas what is going wrong?
I'm not in a position to check right now, but this could happen if
codes.UTF8_BOM is set to the empty string.
Michael
Thanks!
Best regards,
-- Leo
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.ironpythoninaction.com/
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython 2.6 RC 1 Release Hidden
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 the main codeplex page, so I'm sure people will find it. We could also just depend on Michael archiving them and link to his list. =) -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Tony Meyer Sent: Tuesday, November 10, 2009 12:37 PM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.6 RC 1 Release Hidden 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 permanently available without them cluttering up lists that most people would see? i.e. links to alpha (etc) versions would still work, and you could create a list of all releases, but normal users browsing the site would only see the latest (and latest major-1) version? Cheers, Tony ___ 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] IronPython 2.6 RC 1 Release Hidden
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 are warning signs of this may change, and you shouldn't depend on it yet. The low-level point releases, of course, represent (in theory) non-API fixes, and so the only dependency taken in those cases should not break, unless the dependency was on broken behavior in which case the end-user is more likely than not being sloppy. I have no qualms about them bleeding in that case. The years-long-betas of the *nix community notwithstanding, I'd as soon we stick to our guns regarding such things. Having to maintain (ie, support) n different versions is a tremendous burden. I myself had to maintain (no exaggeration) about 3 dozen different versions of the *same* product at one job, but there were other reasons that came to be. Would an image of a giant Monty Python foot stomping on the prior versions, with the caption the version you are requesting has been obsoleted and is no longer supported -- use at your own risk be an acceptable approach? :) From: users-boun...@lists.ironpython.com on behalf of Michael Foord Sent: Tue 11/10/2009 12:34 PM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.6 RC 1 Release Hidden 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. If you take a dependency on them, expect to bleed. The problem is that if a developer has used (and depended on) APIs in a specific release of IronPython then the person who bleeds is likely to be an end user rather than the developer (who may have moved onto other things without updating their project). I don't have a problem with relegating obsolete releases to a small corner, but making them unavailable altogether is a high cost. Michael In the latter case, I wouldn't expect API differences, or other breaking changes unless they represented critical bug fixes. Again, I wouldn't want to support a dependency upon something horribly broken. In light of the above, then, I'd propose keeping the following versions: max(x).y.max(z)[.max(b)] and strongly consider keeping: [max(x)-1].y.max(z)[.max(b)] *From:* users-boun...@lists.ironpython.com on behalf of Michael Foord *Sent:* Tue 11/10/2009 11:25 AM *To:* Discussion of IronPython *Subject:* Re: [IronPython] IronPython 2.6 RC 1 Release Hidden 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 [mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Monday, November 09, 2009 1:47 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.6 RC 1 Release Hidden Jimmy Schementi wrote: I agree, but I think the desire it to keep that Releases list clean. Otherwise it would have every release ever in there. It's a CodePlex limitation that there is no way to hide those releases from that list, while still keeping the links active. I understand the motivation, but making releases that people / projects may have depended on is an unacceptable cost in my opinion. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.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 -- http://www.ironpythoninaction.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
Re: [IronPython] Weird issue with codecs.BOM_UTF8
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!
-- Leo
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: 2009?11?10? 13:17
To: Discussion of IronPython
Subject: Re: [IronPython] Weird issue with codecs.BOM_UTF8
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'D:\Temp\text_file_with_utf8_bom.txt', 'r') lines =
myfile.readlines()
myfile.close()
if lines[0].startswith(codecs.BOM_UTF8):
print ('UTF-8 BOM detected!')
else:
print ('UTF-8 BOM not detected!')
myfile = open(r'D:\Temp\text_file_without_utf8_bom.txt', 'r') lines =
myfile.readlines()
myfile.close()
if lines[0].startswith(codecs.BOM_UTF8):
print ('UTF-8 BOM detected!')
else:
print ('UTF-8 BOM not detected!')
If I run the executable that I get from SharpDevelop this is what I get:
bin\Debug Test.exe
2.5.0 ()
UTF-8 BOM detected!
UTF-8 BOM detected!
But if I run the same script using the standard python interpreter, this is
what I get:
bin\Debug D:\Python25\python.exe ..\..\Program.py
2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)]
UTF-8 BOM detected!
UTF-8 BOM not detected!
The script works correctly with the standard python interpreter but for some
reason is not working right with IronPython.
Any ideas what is going wrong?
I'm not in a position to check right now, but this could happen if
codes.UTF8_BOM is set to the empty string.
Michael
Thanks!
Best regards,
-- Leo
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.ironpythoninaction.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
Re: [IronPython] Weird issue with codecs.BOM_UTF8
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 interpreter.
Well, if codecs.BOM_UTF8 is set to the empty string (you didn't say if
you have tried this yet?) then it would be due to a bug in IronPython
somewhere - but at least you would know what was causing it.
If it is the empty string, purely speculating, it could be due to the
way the .NET framework treats the BOM at the start of strings. Pure
speculation though - that might not be the problem at all or it could be
caused by something entirely different.
In .NET it would be more normal to check for the BOM with bytes, as by
the time you have a string you have (usually) decoded already.
IronPython 2.X is a bit odd for the .NET framework in this respect.
Michael
Thanks!
-- Leo
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: 2009?11?10? 13:17
To: Discussion of IronPython
Subject: Re: [IronPython] Weird issue with codecs.BOM_UTF8
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'D:\Temp\text_file_with_utf8_bom.txt', 'r') lines =
myfile.readlines()
myfile.close()
if lines[0].startswith(codecs.BOM_UTF8):
print ('UTF-8 BOM detected!')
else:
print ('UTF-8 BOM not detected!')
myfile = open(r'D:\Temp\text_file_without_utf8_bom.txt', 'r') lines =
myfile.readlines()
myfile.close()
if lines[0].startswith(codecs.BOM_UTF8):
print ('UTF-8 BOM detected!')
else:
print ('UTF-8 BOM not detected!')
If I run the executable that I get from SharpDevelop this is what I get:
bin\Debug Test.exe
2.5.0 ()
UTF-8 BOM detected!
UTF-8 BOM detected!
But if I run the same script using the standard python interpreter, this is
what I get:
bin\Debug D:\Python25\python.exe ..\..\Program.py
2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)]
UTF-8 BOM detected!
UTF-8 BOM not detected!
The script works correctly with the standard python interpreter but for some
reason is not working right with IronPython.
Any ideas what is going wrong?
I'm not in a position to check right now, but this could happen if
codes.UTF8_BOM is set to the empty string.
Michael
Thanks!
Best regards,
-- Leo
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.ironpythoninaction.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
--
http://www.ironpythoninaction.com/
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython 2.6 RC 1 Release Hidden
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 download the sources for version 0.9.1, but it isn't much of a maintenance burden these days... I don't see an upside to hiding code (or 'breaking things' as I like to put it) in quite the same way you do. :-) All the best, Michael Keith J. Farmer wrote: 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 are warning signs of this may change, and you shouldn't depend on it yet. The low-level point releases, of course, represent (in theory) non-API fixes, and so the only dependency taken in those cases should not break, unless the dependency was on broken behavior in which case the end-user is more likely than not being sloppy. I have no qualms about them bleeding in that case. The years-long-betas of the *nix community notwithstanding, I'd as soon we stick to our guns regarding such things. Having to maintain (ie, support) n different versions is a tremendous burden. I myself had to maintain (no exaggeration) about 3 dozen different versions of the *same* product at one job, but there were other reasons that came to be. Would an image of a giant Monty Python foot stomping on the prior versions, with the caption the version you are requesting has been obsoleted and is no longer supported -- use at your own risk be an acceptable approach? :) *From:* users-boun...@lists.ironpython.com on behalf of Michael Foord *Sent:* Tue 11/10/2009 12:34 PM *To:* Discussion of IronPython *Subject:* Re: [IronPython] IronPython 2.6 RC 1 Release Hidden 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. If you take a dependency on them, expect to bleed. The problem is that if a developer has used (and depended on) APIs in a specific release of IronPython then the person who bleeds is likely to be an end user rather than the developer (who may have moved onto other things without updating their project). I don't have a problem with relegating obsolete releases to a small corner, but making them unavailable altogether is a high cost. Michael In the latter case, I wouldn't expect API differences, or other breaking changes unless they represented critical bug fixes. Again, I wouldn't want to support a dependency upon something horribly broken. In light of the above, then, I'd propose keeping the following versions: max(x).y.max(z)[.max(b)] and strongly consider keeping: [max(x)-1].y.max(z)[.max(b)] *From:* users-boun...@lists.ironpython.com on behalf of Michael Foord *Sent:* Tue 11/10/2009 11:25 AM *To:* Discussion of IronPython *Subject:* Re: [IronPython] IronPython 2.6 RC 1 Release Hidden 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 [mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Monday, November 09, 2009 1:47 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.6 RC 1 Release Hidden Jimmy Schementi wrote: I agree, but I think the desire it to keep that Releases list clean. Otherwise it would have every release ever in there. It's a CodePlex limitation that there is no way to hide those releases from that list, while still keeping the links active. I understand the motivation, but making releases that people / projects may have depended on is an unacceptable cost in my opinion. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list
Re: [IronPython] Weird issue with codecs.BOM_UTF8
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 provide me with an
alternative way of doing this. I am trying to read a file and determine if the
file is encoded in UTF-8 or not. The approach I took was to use python's
built-in open function to read the text file into an array of strings and check
if the first line starts with the UTF-8 byte order mark by using
line.startswith(codecs.BOM_UTF8). As I noted below, this works fine in Python
2.5 but in IronPython it just keeps saying it found a UTF-8 BOM even though
there is none present.
Thanks!
-- Leo
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: 2009?11?10? 13:32
To: Discussion of IronPython
Subject: Re: [IronPython] Weird issue with codecs.BOM_UTF8
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 interpreter.
Well, if codecs.BOM_UTF8 is set to the empty string (you didn't say if you have
tried this yet?) then it would be due to a bug in IronPython somewhere - but at
least you would know what was causing it.
If it is the empty string, purely speculating, it could be due to the way the
.NET framework treats the BOM at the start of strings. Pure speculation though
- that might not be the problem at all or it could be caused by something
entirely different.
In .NET it would be more normal to check for the BOM with bytes, as by the time
you have a string you have (usually) decoded already.
IronPython 2.X is a bit odd for the .NET framework in this respect.
Michael
Thanks!
-- Leo
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: 2009?11?10? 13:17
To: Discussion of IronPython
Subject: Re: [IronPython] Weird issue with codecs.BOM_UTF8
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'D:\Temp\text_file_with_utf8_bom.txt', 'r') lines =
myfile.readlines()
myfile.close()
if lines[0].startswith(codecs.BOM_UTF8):
print ('UTF-8 BOM detected!')
else:
print ('UTF-8 BOM not detected!')
myfile = open(r'D:\Temp\text_file_without_utf8_bom.txt', 'r') lines =
myfile.readlines()
myfile.close()
if lines[0].startswith(codecs.BOM_UTF8):
print ('UTF-8 BOM detected!')
else:
print ('UTF-8 BOM not detected!')
If I run the executable that I get from SharpDevelop this is what I get:
bin\Debug Test.exe
2.5.0 ()
UTF-8 BOM detected!
UTF-8 BOM detected!
But if I run the same script using the standard python interpreter, this is
what I get:
bin\Debug D:\Python25\python.exe ..\..\Program.py
2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)]
UTF-8 BOM detected!
UTF-8 BOM not detected!
The script works correctly with the standard python interpreter but for some
reason is not working right with IronPython.
Any ideas what is going wrong?
I'm not in a position to check right now, but this could happen if
codes.UTF8_BOM is set to the empty string.
Michael
Thanks!
Best regards,
-- Leo
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.ironpythoninaction.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
--
http://www.ironpythoninaction.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
Re: [IronPython] Weird issue with codecs.BOM_UTF8
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 as not starting
with the BOM:
import codecs
codecs.BOM_UTF8
u'\xef\xbb\xbf'
lines = open('foo.txt').readlines()
lines
['foo']
lines[0].startswith(codecs.BOM_UTF8)
False
All the best,
Michael Foord
# UTF-8
BOM_UTF8 = '\xef\xbb\xbf'
So it is not an empty string.
Maybe I am approaching this wrong and you guys can provide me with an
alternative way of doing this. I am trying to read a file and determine if the
file is encoded in UTF-8 or not. The approach I took was to use python's
built-in open function to read the text file into an array of strings and check
if the first line starts with the UTF-8 byte order mark by using
line.startswith(codecs.BOM_UTF8). As I noted below, this works fine in Python
2.5 but in IronPython it just keeps saying it found a UTF-8 BOM even though
there is none present.
Thanks!
-- Leo
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: 2009?11?10? 13:32
To: Discussion of IronPython
Subject: Re: [IronPython] Weird issue with codecs.BOM_UTF8
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 interpreter.
Well, if codecs.BOM_UTF8 is set to the empty string (you didn't say if you have
tried this yet?) then it would be due to a bug in IronPython somewhere - but at
least you would know what was causing it.
If it is the empty string, purely speculating, it could be due to the way the
.NET framework treats the BOM at the start of strings. Pure speculation though
- that might not be the problem at all or it could be caused by something
entirely different.
In .NET it would be more normal to check for the BOM with bytes, as by the time you have a string you have (usually) decoded already.
IronPython 2.X is a bit odd for the .NET framework in this respect.
Michael
Thanks!
-- Leo
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: 2009?11?10? 13:17
To: Discussion of IronPython
Subject: Re: [IronPython] Weird issue with codecs.BOM_UTF8
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'D:\Temp\text_file_with_utf8_bom.txt', 'r') lines =
myfile.readlines()
myfile.close()
if lines[0].startswith(codecs.BOM_UTF8):
print ('UTF-8 BOM detected!')
else:
print ('UTF-8 BOM not detected!')
myfile = open(r'D:\Temp\text_file_without_utf8_bom.txt', 'r') lines =
myfile.readlines()
myfile.close()
if lines[0].startswith(codecs.BOM_UTF8):
print ('UTF-8 BOM detected!')
else:
print ('UTF-8 BOM not detected!')
If I run the executable that I get from SharpDevelop this is what I get:
bin\Debug Test.exe
2.5.0 ()
UTF-8 BOM detected!
UTF-8 BOM detected!
But if I run the same script using the standard python interpreter, this is
what I get:
bin\Debug D:\Python25\python.exe ..\..\Program.py
2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)]
UTF-8 BOM detected!
UTF-8 BOM not detected!
The script works correctly with the standard python interpreter but for some
reason is not working right with IronPython.
Any ideas what is going wrong?
I'm not in a position to check right now, but this could happen if
codes.UTF8_BOM is set to the empty string.
Michael
Thanks!
Best regards,
-- Leo
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.ironpythoninaction.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
--
http://www.ironpythoninaction.com/
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
Re: [IronPython] Weird issue with codecs.BOM_UTF8
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.ironpython.com] On Behalf Of Michael Foord
Sent: 2009?11?10? 14:05
To: Discussion of IronPython
Subject: Re: [IronPython] Weird issue with codecs.BOM_UTF8
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 as not starting with
the BOM:
import codecs
codecs.BOM_UTF8
u'\xef\xbb\xbf'
lines = open('foo.txt').readlines() lines ['foo']
lines[0].startswith(codecs.BOM_UTF8)
False
All the best,
Michael Foord
# UTF-8
BOM_UTF8 = '\xef\xbb\xbf'
So it is not an empty string.
Maybe I am approaching this wrong and you guys can provide me with an
alternative way of doing this. I am trying to read a file and determine if
the file is encoded in UTF-8 or not. The approach I took was to use python's
built-in open function to read the text file into an array of strings and
check if the first line starts with the UTF-8 byte order mark by using
line.startswith(codecs.BOM_UTF8). As I noted below, this works fine in
Python 2.5 but in IronPython it just keeps saying it found a UTF-8 BOM even
though there is none present.
Thanks!
-- Leo
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: 2009?11?10? 13:32
To: Discussion of IronPython
Subject: Re: [IronPython] Weird issue with codecs.BOM_UTF8
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 interpreter.
Well, if codecs.BOM_UTF8 is set to the empty string (you didn't say if you
have tried this yet?) then it would be due to a bug in IronPython somewhere -
but at least you would know what was causing it.
If it is the empty string, purely speculating, it could be due to the way the
.NET framework treats the BOM at the start of strings. Pure speculation
though - that might not be the problem at all or it could be caused by
something entirely different.
In .NET it would be more normal to check for the BOM with bytes, as by the
time you have a string you have (usually) decoded already.
IronPython 2.X is a bit odd for the .NET framework in this respect.
Michael
Thanks!
-- Leo
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael
Foord
Sent: 2009?11?10? 13:17
To: Discussion of IronPython
Subject: Re: [IronPython] Weird issue with codecs.BOM_UTF8
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'D:\Temp\text_file_with_utf8_bom.txt', 'r') lines =
myfile.readlines()
myfile.close()
if lines[0].startswith(codecs.BOM_UTF8):
print ('UTF-8 BOM detected!')
else:
print ('UTF-8 BOM not detected!')
myfile = open(r'D:\Temp\text_file_without_utf8_bom.txt', 'r') lines
=
myfile.readlines()
myfile.close()
if lines[0].startswith(codecs.BOM_UTF8):
print ('UTF-8 BOM detected!')
else:
print ('UTF-8 BOM not detected!')
If I run the executable that I get from SharpDevelop this is what I get:
bin\Debug Test.exe
2.5.0 ()
UTF-8 BOM detected!
UTF-8 BOM detected!
But if I run the same script using the standard python interpreter, this is
what I get:
bin\Debug D:\Python25\python.exe ..\..\Program.py
2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit
(Intel)]
UTF-8 BOM detected!
UTF-8 BOM not detected!
The script works correctly with the standard python interpreter but for
some reason is not working right with IronPython.
Any ideas what is going wrong?
I'm not in a position to check right now, but this could happen if
codes.UTF8_BOM is set to the empty string.
Michael
Thanks!
Best regards,
-- Leo
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.ironpythoninaction.com/
___
Users mailing list
Re: [IronPython] Weird issue with codecs.BOM_UTF8
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 idea. I can't reproduce the problem with IronPython 2.6 though. Try
installing IronPython 2 and seeing what happens from the interactive
interpreter (whether you can reproduce the problem or not). It is
*possible* that it's caused by the way SharpDevelop generates its
executables, but that's highly unlikely to be the cause of the problem.
All the best,
Michael Foord
Thanks!
-- Leo
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: 2009?11?10? 14:05
To: Discussion of IronPython
Subject: Re: [IronPython] Weird issue with codecs.BOM_UTF8
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 as not starting with
the BOM:
import codecs
codecs.BOM_UTF8
u'\xef\xbb\xbf'
lines = open('foo.txt').readlines() lines ['foo']
lines[0].startswith(codecs.BOM_UTF8)
False
All the best,
Michael Foord
# UTF-8
BOM_UTF8 = '\xef\xbb\xbf'
So it is not an empty string.
Maybe I am approaching this wrong and you guys can provide me with an
alternative way of doing this. I am trying to read a file and determine if the
file is encoded in UTF-8 or not. The approach I took was to use python's
built-in open function to read the text file into an array of strings and check
if the first line starts with the UTF-8 byte order mark by using
line.startswith(codecs.BOM_UTF8). As I noted below, this works fine in Python
2.5 but in IronPython it just keeps saying it found a UTF-8 BOM even though
there is none present.
Thanks!
-- Leo
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: 2009?11?10? 13:32
To: Discussion of IronPython
Subject: Re: [IronPython] Weird issue with codecs.BOM_UTF8
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 interpreter.
Well, if codecs.BOM_UTF8 is set to the empty string (you didn't say if you have
tried this yet?) then it would be due to a bug in IronPython somewhere - but at
least you would know what was causing it.
If it is the empty string, purely speculating, it could be due to the way the
.NET framework treats the BOM at the start of strings. Pure speculation though
- that might not be the problem at all or it could be caused by something
entirely different.
In .NET it would be more normal to check for the BOM with bytes, as by the time you have a string you have (usually) decoded already.
IronPython 2.X is a bit odd for the .NET framework in this respect.
Michael
Thanks!
-- Leo
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael
Foord
Sent: 2009?11?10? 13:17
To: Discussion of IronPython
Subject: Re: [IronPython] Weird issue with codecs.BOM_UTF8
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'D:\Temp\text_file_with_utf8_bom.txt', 'r') lines =
myfile.readlines()
myfile.close()
if lines[0].startswith(codecs.BOM_UTF8):
print ('UTF-8 BOM detected!')
else:
print ('UTF-8 BOM not detected!')
myfile = open(r'D:\Temp\text_file_without_utf8_bom.txt', 'r') lines
=
myfile.readlines()
myfile.close()
if lines[0].startswith(codecs.BOM_UTF8):
print ('UTF-8 BOM detected!')
else:
print ('UTF-8 BOM not detected!')
If I run the executable that I get from SharpDevelop this is what I get:
bin\Debug Test.exe
2.5.0 ()
UTF-8 BOM detected!
UTF-8 BOM detected!
But if I run the same script using the standard python interpreter, this is
what I get:
bin\Debug D:\Python25\python.exe ..\..\Program.py
2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit
(Intel)]
UTF-8 BOM detected!
UTF-8 BOM not detected!
The script works correctly with the standard python interpreter but for some
reason is not working right with IronPython.
Any ideas what is going wrong?
I'm
Re: [IronPython] Weird issue with codecs.BOM_UTF8
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.
import sys
sys.path.append(r'D:\Python25\lib')
import codecs
lines = open(r'D:\Temp\text_file_without_utf8_bom.txt', 'r').readlines()
print lines
['This is a text file without a UTF-8 BOM.\n', 'Line 2\n', 'Line 3']
lines[0].startswith(codecs.BOM_UTF8)
True
^Z
C:\
It returned 'True' even though the text file did not have a UTF-8 BOM.
Contrasted with standard Python 2.5:
C:\ D:\Python25\python.exe
Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)] on
win32
Type help, copyright, credits or license for more information.
import sys
import codecs
lines = open(r'D:\Temp\text_file_without_utf8_bom.txt', 'r').readlines()
print lines
['This is a text file without a UTF-8 BOM.\n', 'Line 2\n', 'Line 3']
lines[0].startswith(codecs.BOM_UTF8)
False
^Z
C:\
So it looks like there was a bug in IronPython 2.0.x with regards to the
handling of codecs.BOM_UTF8 that now appears to be fixed in IronPython 2.6.
Does that sound like a fair assessment?
Thanks!
-- Leo
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: 2009?11?10? 14:30
To: Discussion of IronPython
Subject: Re: [IronPython] Weird issue with codecs.BOM_UTF8
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 idea. I can't reproduce the problem with IronPython 2.6 though. Try
installing IronPython 2 and seeing what happens from the interactive
interpreter (whether you can reproduce the problem or not). It is
*possible* that it's caused by the way SharpDevelop generates its executables,
but that's highly unlikely to be the cause of the problem.
All the best,
Michael Foord
Thanks!
-- Leo
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: 2009?11?10? 14:05
To: Discussion of IronPython
Subject: Re: [IronPython] Weird issue with codecs.BOM_UTF8
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 as not starting with
the BOM:
import codecs
codecs.BOM_UTF8
u'\xef\xbb\xbf'
lines = open('foo.txt').readlines() lines ['foo']
lines[0].startswith(codecs.BOM_UTF8)
False
All the best,
Michael Foord
# UTF-8
BOM_UTF8 = '\xef\xbb\xbf'
So it is not an empty string.
Maybe I am approaching this wrong and you guys can provide me with an
alternative way of doing this. I am trying to read a file and determine if
the file is encoded in UTF-8 or not. The approach I took was to use
python's built-in open function to read the text file into an array of
strings and check if the first line starts with the UTF-8 byte order mark by
using line.startswith(codecs.BOM_UTF8). As I noted below, this works fine
in Python 2.5 but in IronPython it just keeps saying it found a UTF-8 BOM
even though there is none present.
Thanks!
-- Leo
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael
Foord
Sent: 2009?11?10? 13:32
To: Discussion of IronPython
Subject: Re: [IronPython] Weird issue with codecs.BOM_UTF8
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 interpreter.
Well, if codecs.BOM_UTF8 is set to the empty string (you didn't say if you
have tried this yet?) then it would be due to a bug in IronPython somewhere
- but at least you would know what was causing it.
If it is the empty string, purely speculating, it could be due to the way
the .NET framework treats the BOM at the start of strings. Pure speculation
though - that might not be the problem at all or it could be caused by
something entirely different.
In .NET it would be more normal to check for the BOM with bytes, as by the
time you have a string you have (usually) decoded already.
IronPython 2.X is a bit odd for the .NET framework in this respect.
Michael
Re: [IronPython] Weird issue with codecs.BOM_UTF8
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 for more information.
import sys
sys.path.append(r'D:\Python25\lib')
import codecs
lines = open(r'D:\Temp\text_file_without_utf8_bom.txt', 'r').readlines()
print lines
['This is a text file without a UTF-8 BOM.\n', 'Line 2\n', 'Line 3']
lines[0].startswith(codecs.BOM_UTF8)
True
^Z
C:\
It returned 'True' even though the text file did not have a UTF-8 BOM.
Contrasted with standard Python 2.5:
C:\ D:\Python25\python.exe
Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)] on
win32
Type help, copyright, credits or license for more information.
import sys
import codecs
lines = open(r'D:\Temp\text_file_without_utf8_bom.txt', 'r').readlines()
print lines
['This is a text file without a UTF-8 BOM.\n', 'Line 2\n', 'Line 3']
lines[0].startswith(codecs.BOM_UTF8)
False
^Z
C:\
So it looks like there was a bug in IronPython 2.0.x with regards to the
handling of codecs.BOM_UTF8 that now appears to be fixed in IronPython 2.6.
Does that sound like a fair assessment?
Looks to me like you are right. If the code that checks for the BOM is
in your code rather than a library module then you'll have to find
another way to do the check I'm afraid. (Or upgrade to IronPython 2.6 of
course.)
All the best,
Michael Foord
Thanks!
-- Leo
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: 2009?11?10? 14:30
To: Discussion of IronPython
Subject: Re: [IronPython] Weird issue with codecs.BOM_UTF8
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 idea. I can't reproduce the problem with IronPython 2.6 though. Try
installing IronPython 2 and seeing what happens from the interactive
interpreter (whether you can reproduce the problem or not). It is
*possible* that it's caused by the way SharpDevelop generates its executables,
but that's highly unlikely to be the cause of the problem.
All the best,
Michael Foord
Thanks!
-- Leo
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: 2009?11?10? 14:05
To: Discussion of IronPython
Subject: Re: [IronPython] Weird issue with codecs.BOM_UTF8
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 as not starting with
the BOM:
import codecs
codecs.BOM_UTF8
u'\xef\xbb\xbf'
lines = open('foo.txt').readlines() lines ['foo']
lines[0].startswith(codecs.BOM_UTF8)
False
All the best,
Michael Foord
# UTF-8
BOM_UTF8 = '\xef\xbb\xbf'
So it is not an empty string.
Maybe I am approaching this wrong and you guys can provide me with an
alternative way of doing this. I am trying to read a file and determine if the
file is encoded in UTF-8 or not. The approach I took was to use python's
built-in open function to read the text file into an array of strings and check
if the first line starts with the UTF-8 byte order mark by using
line.startswith(codecs.BOM_UTF8). As I noted below, this works fine in Python
2.5 but in IronPython it just keeps saying it found a UTF-8 BOM even though
there is none present.
Thanks!
-- Leo
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael
Foord
Sent: 2009?11?10? 13:32
To: Discussion of IronPython
Subject: Re: [IronPython] Weird issue with codecs.BOM_UTF8
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 interpreter.
Well, if codecs.BOM_UTF8 is set to the empty string (you didn't say if you have
tried this yet?) then it would be due to a bug in IronPython somewhere - but at
least you would know what was causing it.
If it is the empty string, purely speculating, it could be due to the way the
.NET framework treats the BOM at the start of strings.
Re: [IronPython] .NET attributes for methods
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 listbox. By the way - I have seen a commit message you have added support for interfaces - nice! ;-) -- -- Lukáš [1] http://cid-0d9bc809858885a4.skydrive.live.com/self.aspx/DevHawk%20Content/IronPython%20Stuff/^_^_clrtype^_^_/SL%20databinding%20demo.zip http://cid-0d9bc809858885a4.skydrive.live.com/self.aspx/DevHawk%20Content/IronPython%20Stuff/%5E_%5E_clrtype%5E_%5E_/SL%20databinding%20demo.zip Shri Borde wrote: The following files extend DevHawk's blog and adds support for typed methods with attributes. It will be available as part of the samples released with the 2.6 RTM (over the next month). Do let us know if it works for you. Also, I would be curious to know what scenario you need method attributes for (other than DllImport for pinvokes)... -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky Sent: Thursday, October 22, 2009 10:37 AM To: Discussion of IronPython Subject: [IronPython] .NET attributes for methods Hi, I have read all DewHawk blogposts about .Net attributes in IronPython via __clrtype__ metaclass (http://devhawk.net/CategoryView,category,__clrtype__.aspx). He describes how to add attributes to classes but not to methods. Is there any example how to add attributes to a method. It looks like method generation is necessary (like for getter and setter or in http://www.voidspace.org.uk/python/weblog/arch_d7_2007_03_10.shtml#e659) but this is kind of deep magic for me... Thanks. -- -- Lukáš ___ 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 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes for methods
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 object and also make sure that no exceptions were thrown? From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky Sent: Tuesday, November 10, 2009 2:59 PM To: Discussion of IronPython Subject: Re: [IronPython] .NET attributes for methods 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 listbox. By the way - I have seen a commit message you have added support for interfaces - nice! ;-) -- -- Lukáš [1] http://cid-0d9bc809858885a4.skydrive.live.com/self.aspx/DevHawk%20Content/IronPython%20Stuff/^_^_clrtype^_^_/SL%20databinding%20demo.ziphttp://cid-0d9bc809858885a4.skydrive.live.com/self.aspx/DevHawk%20Content/IronPython%20Stuff/%5E_%5E_clrtype%5E_%5E_/SL%20databinding%20demo.zip Shri Borde wrote: The following files extend DevHawk's blog and adds support for typed methods with attributes. It will be available as part of the samples released with the 2.6 RTM (over the next month). Do let us know if it works for you. Also, I would be curious to know what scenario you need method attributes for (other than DllImport for pinvokes)... -Original Message- From: users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky Sent: Thursday, October 22, 2009 10:37 AM To: Discussion of IronPython Subject: [IronPython] .NET attributes for methods Hi, I have read all DewHawk blogposts about .Net attributes in IronPython via __clrtype__ metaclass (http://devhawk.net/CategoryView,category,__clrtype__.aspx). He describes how to add attributes to classes but not to methods. Is there any example how to add attributes to a method. It looks like method generation is necessary (like for getter and setter or in http://www.voidspace.org.uk/python/weblog/arch_d7_2007_03_10.shtml#e659) but this is kind of deep magic for me... Thanks. -- -- Lukáš ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.commailto: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] TYPO: in exception message
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.com
Re: [IronPython] IronPython 2.6 RC 1 Release Hidden
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 ScriptRuntimeSetup classes. Might be worth a posting or two. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Tuesday, November 10, 2009 1:32 PM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.6 RC 1 Release Hidden 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 download the sources for version 0.9.1, but it isn't much of a maintenance burden these days... I don't see an upside to hiding code (or 'breaking things' as I like to put it) in quite the same way you do. :-) All the best, Michael Keith J. Farmer wrote: 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 are warning signs of this may change, and you shouldn't depend on it yet. The low-level point releases, of course, represent (in theory) non-API fixes, and so the only dependency taken in those cases should not break, unless the dependency was on broken behavior in which case the end-user is more likely than not being sloppy. I have no qualms about them bleeding in that case. The years-long-betas of the *nix community notwithstanding, I'd as soon we stick to our guns regarding such things. Having to maintain (ie, support) n different versions is a tremendous burden. I myself had to maintain (no exaggeration) about 3 dozen different versions of the *same* product at one job, but there were other reasons that came to be. Would an image of a giant Monty Python foot stomping on the prior versions, with the caption the version you are requesting has been obsoleted and is no longer supported -- use at your own risk be an acceptable approach? :) *From:* users-boun...@lists.ironpython.com on behalf of Michael Foord *Sent:* Tue 11/10/2009 12:34 PM *To:* Discussion of IronPython *Subject:* Re: [IronPython] IronPython 2.6 RC 1 Release Hidden 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. If you take a dependency on them, expect to bleed. The problem is that if a developer has used (and depended on) APIs in a specific release of IronPython then the person who bleeds is likely to be an end user rather than the developer (who may have moved onto other things without updating their project). I don't have a problem with relegating obsolete releases to a small corner, but making them unavailable altogether is a high cost. Michael In the latter case, I wouldn't expect API differences, or other breaking changes unless they represented critical bug fixes. Again, I wouldn't want to support a dependency upon something horribly broken. In light of the above, then, I'd propose keeping the following versions: max(x).y.max(z)[.max(b)] and strongly consider keeping: [max(x)-1].y.max(z)[.max(b)] *From:* users-boun...@lists.ironpython.com on behalf of Michael Foord *Sent:* Tue 11/10/2009 11:25 AM *To:* Discussion of IronPython *Subject:* Re: [IronPython] IronPython 2.6 RC 1 Release Hidden 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 [mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Monday, November 09, 2009 1:47 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.6 RC 1 Release Hidden Jimmy Schementi wrote: I agree, but I think the desire it to keep that Releases list clean. Otherwise it would have every release ever in there. It's a CodePlex limitation that there is no way to hide those releases from that list, while
[IronPython] Different file extension import?
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 other modules, but would still like them to have .pyt/.pys for the file extension. Thanks, slide -- slide-o-blog http://slide-o-blog.blogspot.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
