Re: [IronPython] Preprocessor directives in IronPython 2.0
Nope. Why do you think you want them? Or rather, what's wrong with this:
debug = False
def Main():
if debug:
print 'DEBUG is set'
else:
print 'DEBUG is not set'
On Mon, Dec 15, 2008 at 5:46 AM, Yash Ganthe yas...@gmail.com wrote:
In C# we can code for conditional compilation such as:
public static void Main()
{
#if DEBUG
Console.WriteLine(DEBUG is defined);
#else
Console.WriteLine(DEBUG is not defined);
#endif
}
Is it possible to do the same in IronPython? Does it support preprocessor
directives?
Thanks,
Yash
___
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] Help contents
Where does IP find the help content for .NET libraries?
I mean, for instance, the output of
help(System.DateTime.ToBoolean)
Does it parse the Help.2 files? If so where does it look
for them? Only under %ALLUSERSPROFILE%\{Program Data}\Microsoft Help?
Regards,
-H.
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] IronPython and file descriptors
Hi, At the moment file.fileno() returns an arbitrary identifier of a python file rather than a true file descriptor. This is semi-blocking the Ironclad port of PIL. Code in PIL gets an integer using fileno() and passes it directly to C code where a call to write() is made. To fix this one would have to patch PIL, IronPython's file objects or the write function provided to C code - none of these feel like a good course of action. When ctypes is ported to IronPython this may create similar problems. Ideally fileno() would return a real file descriptor. Would this be possible? Thanks, Tom Resolver Systems ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython and file descriptors
There's no such thing as a file descriptor number in .NET -- or, for that matter, in Windows itself! :) (The latter is something of a semantic point, of course, as a HANDLE serves something of the same role in Win32 as a file descriptor number does in Unix.) If you have a FileStream, I think you can turn it into a Windows HANDLE by saying IntPtr handle = stream.SafeFileHandle.DangerousGetHandle(); The C library should have a way to convert a HANDLE into a file descriptor, though I wasn't able to identify the function name with a quick google. I don't see a way to get handles for stdin, stdout or stderr, though, except that these ought to be easy to translate by hand. On Mon, Dec 15, 2008 at 8:03 AM, Tom Wright tom.wri...@resolversystems.com wrote: Hi, At the moment file.fileno() returns an arbitrary identifier of a python file rather than a true file descriptor. This is semi-blocking the Ironclad port of PIL. Code in PIL gets an integer using fileno() and passes it directly to C code where a call to write() is made. To fix this one would have to patch PIL, IronPython's file objects or the write function provided to C code - none of these feel like a good course of action. When ctypes is ported to IronPython this may create similar problems. Ideally fileno() would return a real file descriptor. Would this be possible? Thanks, Tom Resolver Systems ___ 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 and file descriptors
Not so: Though admittedly you have to do quite a bit of work to get the file descriptor into .NET. http://msdn.microsoft.com/en-us/library/bdts1c9x(VS.71).aspx To clarify - the C library was written to work with Python (not IronPython) and is not my code. Thanks, Tom Curt Hagenlocher wrote: There's no such thing as a file descriptor number in .NET -- or, for that matter, in Windows itself! :) (The latter is something of a semantic point, of course, as a HANDLE serves something of the same role in Win32 as a file descriptor number does in Unix.) If you have a FileStream, I think you can turn it into a Windows HANDLE by saying IntPtr handle = stream.SafeFileHandle.DangerousGetHandle(); The C library should have a way to convert a HANDLE into a file descriptor, though I wasn't able to identify the function name with a quick google. I don't see a way to get handles for stdin, stdout or stderr, though, except that these ought to be easy to translate by hand. On Mon, Dec 15, 2008 at 8:03 AM, Tom Wright tom.wri...@resolversystems.com mailto:tom.wri...@resolversystems.com wrote: Hi, At the moment file.fileno() returns an arbitrary identifier of a python file rather than a true file descriptor. This is semi-blocking the Ironclad port of PIL. Code in PIL gets an integer using fileno() and passes it directly to C code where a call to write() is made. To fix this one would have to patch PIL, IronPython's file objects or the write function provided to C code - none of these feel like a good course of action. When ctypes is ported to IronPython this may create similar problems. Ideally fileno() would return a real file descriptor. Would this be possible? Thanks, Tom Resolver Systems ___ Users mailing list Users@lists.ironpython.com mailto: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 and file descriptors
Ah, that was the function I was looking for. Sure, the file descriptor exists in the C library under Windows. But the C library is basically doing exactly the same thing as IronPython is; it's maintaining the file descriptor number as an abstraction on top of the HANDLE that the operating system knows about. So we're dealing two similar abstractions with entirely unrelated interfaces: IronPython fd built on top of .NET stream built on top of Windows HANDLE, vs clib fd built directly on top of Windows HANDLE To get from the IronPython fd to a clib fd, you need to translate down the first chain and up the second. On Mon, Dec 15, 2008 at 9:37 AM, Tom Wright tom.wri...@resolversystems.comwrote: Not so: Though admittedly you have to do quite a bit of work to get the file descriptor into .NET. http://msdn.microsoft.com/en-us/library/bdts1c9x(VS.71).aspx To clarify - the C library was written to work with Python (not IronPython) and is not my code. Thanks, Tom Curt Hagenlocher wrote: There's no such thing as a file descriptor number in .NET -- or, for that matter, in Windows itself! :) (The latter is something of a semantic point, of course, as a HANDLE serves something of the same role in Win32 as a file descriptor number does in Unix.) If you have a FileStream, I think you can turn it into a Windows HANDLE by saying IntPtr handle = stream.SafeFileHandle.DangerousGetHandle(); The C library should have a way to convert a HANDLE into a file descriptor, though I wasn't able to identify the function name with a quick google. I don't see a way to get handles for stdin, stdout or stderr, though, except that these ought to be easy to translate by hand. On Mon, Dec 15, 2008 at 8:03 AM, Tom Wright tom.wri...@resolversystems.com mailto:tom.wri...@resolversystems.com wrote: Hi, At the moment file.fileno() returns an arbitrary identifier of a python file rather than a true file descriptor. This is semi-blocking the Ironclad port of PIL. Code in PIL gets an integer using fileno() and passes it directly to C code where a call to write() is made. To fix this one would have to patch PIL, IronPython's file objects or the write function provided to C code - none of these feel like a good course of action. When ctypes is ported to IronPython this may create similar problems. Ideally fileno() would return a real file descriptor. Would this be possible? Thanks, Tom Resolver Systems ___ Users mailing list Users@lists.ironpython.com mailto: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 and file descriptors
Agreed. It is certainly possible with some work to get a file descriptor and pass it to C code. This is not the problem, however. Ironclad's aim (eventually) is to allow *arbitrary* C extensions to work with Ironpython without changing the extensions. Ctypes aim is to allow arbitrary C code to be run by python (possibly in other python libraries which you really don't want to modify). In CPython .fileno() is a file descriptor and some modules use this fact (specifically PIL) by passing file descriptors as integers into C code. I do not know how one can make this code work in IronPython unless .fileno() returns a file descriptor. The game here is not making a particular C library work with IronPython by modifying this library but making as many libraries as possible work without modification. Of course whether this is worthwhile depends on how many libraries rely on this fact. Sorry - I hope this is a little clearer. Tom Curt Hagenlocher wrote: Ah, that was the function I was looking for. Sure, the file descriptor exists in the C library under Windows. But the C library is basically doing exactly the same thing as IronPython is; it's maintaining the file descriptor number as an abstraction on top of the HANDLE that the operating system knows about. So we're dealing two similar abstractions with entirely unrelated interfaces: IronPython fd built on top of .NET stream built on top of Windows HANDLE, vs clib fd built directly on top of Windows HANDLE To get from the IronPython fd to a clib fd, you need to translate down the first chain and up the second. On Mon, Dec 15, 2008 at 9:37 AM, Tom Wright tom.wri...@resolversystems.com mailto:tom.wri...@resolversystems.com wrote: Not so: Though admittedly you have to do quite a bit of work to get the file descriptor into .NET. http://msdn.microsoft.com/en-us/library/bdts1c9x(VS.71).aspx http://msdn.microsoft.com/en-us/library/bdts1c9x%28VS.71%29.aspx To clarify - the C library was written to work with Python (not IronPython) and is not my code. Thanks, Tom Curt Hagenlocher wrote: There's no such thing as a file descriptor number in .NET -- or, for that matter, in Windows itself! :) (The latter is something of a semantic point, of course, as a HANDLE serves something of the same role in Win32 as a file descriptor number does in Unix.) If you have a FileStream, I think you can turn it into a Windows HANDLE by saying IntPtr handle = stream.SafeFileHandle.DangerousGetHandle(); The C library should have a way to convert a HANDLE into a file descriptor, though I wasn't able to identify the function name with a quick google. I don't see a way to get handles for stdin, stdout or stderr, though, except that these ought to be easy to translate by hand. On Mon, Dec 15, 2008 at 8:03 AM, Tom Wright tom.wri...@resolversystems.com mailto:tom.wri...@resolversystems.com mailto:tom.wri...@resolversystems.com mailto:tom.wri...@resolversystems.com wrote: Hi, At the moment file.fileno() returns an arbitrary identifier of a python file rather than a true file descriptor. This is semi-blocking the Ironclad port of PIL. Code in PIL gets an integer using fileno() and passes it directly to C code where a call to write() is made. To fix this one would have to patch PIL, IronPython's file objects or the write function provided to C code - none of these feel like a good course of action. When ctypes is ported to IronPython this may create similar problems. Ideally fileno() would return a real file descriptor. Would this be possible? Thanks, Tom Resolver Systems ___ Users mailing list Users@lists.ironpython.com mailto:Users@lists.ironpython.com mailto:Users@lists.ironpython.com mailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com mailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com mailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com
Re: [IronPython] IronPython and file descriptors
On Mon, Dec 15, 2008 at 11:18 AM, Tom Wright tom.wri...@resolversystems.com wrote: Agreed. It is certainly possible with some work to get a file descriptor and pass it to C code. This is not the problem, however. Ironclad's aim (eventually) is to allow *arbitrary* C extensions to work with Ironpython without changing the extensions. Ctypes aim is to allow arbitrary C code to be run by python (possibly in other python libraries which you really don't want to modify). In CPython .fileno() is a file descriptor and some modules use this fact (specifically PIL) by passing file descriptors as integers into C code. I do not know how one can make this code work in IronPython unless .fileno() returns a file descriptor. The game here is not making a particular C library work with IronPython by modifying this library but making as many libraries as possible work without modification. Of course whether this is worthwhile depends on how many libraries rely on this fact. Sorry - I hope this is a little clearer. Tom How does CPython get the file descriptor for fileno()? Does it just return the HANDLE on Windows? slide ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Preprocessor directives in IronPython 2.0
The one form this is available is with the assert keyword. Assert statements
will be removed in optimized code so you don't have the if debug check. But
they won't let you have the else branch.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Curt Hagenlocher
Sent: Monday, December 15, 2008 6:27 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Preprocessor directives in IronPython 2.0
Nope. Why do you think you want them? Or rather, what's wrong with this:
debug = False
def Main():
if debug:
print 'DEBUG is set'
else:
print 'DEBUG is not set'
On Mon, Dec 15, 2008 at 5:46 AM, Yash Ganthe
yas...@gmail.commailto:yas...@gmail.com wrote:
In C# we can code for conditional compilation such as:
public static void Main()
{
#if DEBUG
Console.WriteLine(DEBUG is defined);
#else
Console.WriteLine(DEBUG is not defined);
#endif
}
Is it possible to do the same in IronPython? Does it support preprocessor
directives?
Thanks,
Yash
___
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
Re: [IronPython] IronPython and file descriptors
I think I understand the motivation pretty well; what I'm saying is that I don't see that this is possible. IronPython has no access to the table being used by the C library to map between Windows HANDLEs and clib file descriptors, so we can't return a clib-compatible fd. Even if we were to return a Windows HANDLE as the fd from IronPython (something which is bad in several ways), this wouldn't be a value that could just be used directly by the C extension through the C library. On Mon, Dec 15, 2008 at 10:18 AM, Tom Wright tom.wri...@resolversystems.com wrote: Agreed. It is certainly possible with some work to get a file descriptor and pass it to C code. This is not the problem, however. Ironclad's aim (eventually) is to allow *arbitrary* C extensions to work with Ironpython without changing the extensions. Ctypes aim is to allow arbitrary C code to be run by python (possibly in other python libraries which you really don't want to modify). In CPython .fileno() is a file descriptor and some modules use this fact (specifically PIL) by passing file descriptors as integers into C code. I do not know how one can make this code work in IronPython unless .fileno() returns a file descriptor. The game here is not making a particular C library work with IronPython by modifying this library but making as many libraries as possible work without modification. Of course whether this is worthwhile depends on how many libraries rely on this fact. Sorry - I hope this is a little clearer. Tom Curt Hagenlocher wrote: Ah, that was the function I was looking for. Sure, the file descriptor exists in the C library under Windows. But the C library is basically doing exactly the same thing as IronPython is; it's maintaining the file descriptor number as an abstraction on top of the HANDLE that the operating system knows about. So we're dealing two similar abstractions with entirely unrelated interfaces: IronPython fd built on top of .NET stream built on top of Windows HANDLE, vs clib fd built directly on top of Windows HANDLE To get from the IronPython fd to a clib fd, you need to translate down the first chain and up the second. On Mon, Dec 15, 2008 at 9:37 AM, Tom Wright tom.wri...@resolversystems.com mailto:tom.wri...@resolversystems.com wrote: Not so: Though admittedly you have to do quite a bit of work to get the file descriptor into .NET. http://msdn.microsoft.com/en-us/library/bdts1c9x(VS.71).aspx http://msdn.microsoft.com/en-us/library/bdts1c9x%28VS.71%29.aspx To clarify - the C library was written to work with Python (not IronPython) and is not my code. Thanks, Tom Curt Hagenlocher wrote: There's no such thing as a file descriptor number in .NET -- or, for that matter, in Windows itself! :) (The latter is something of a semantic point, of course, as a HANDLE serves something of the same role in Win32 as a file descriptor number does in Unix.) If you have a FileStream, I think you can turn it into a Windows HANDLE by saying IntPtr handle = stream.SafeFileHandle.DangerousGetHandle(); The C library should have a way to convert a HANDLE into a file descriptor, though I wasn't able to identify the function name with a quick google. I don't see a way to get handles for stdin, stdout or stderr, though, except that these ought to be easy to translate by hand. On Mon, Dec 15, 2008 at 8:03 AM, Tom Wright tom.wri...@resolversystems.com mailto:tom.wri...@resolversystems.com mailto:tom.wri...@resolversystems.com mailto:tom.wri...@resolversystems.com wrote: Hi, At the moment file.fileno() returns an arbitrary identifier of a python file rather than a true file descriptor. This is semi-blocking the Ironclad port of PIL. Code in PIL gets an integer using fileno() and passes it directly to C code where a call to write() is made. To fix this one would have to patch PIL, IronPython's file objects or the write function provided to C code - none of these feel like a good course of action. When ctypes is ported to IronPython this may create similar problems. Ideally fileno() would return a real file descriptor. Would this be possible? Thanks, Tom Resolver Systems ___ Users mailing list Users@lists.ironpython.com mailto:Users@lists.ironpython.com mailto:Users@lists.ironpython.com mailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Help contents
It seems clear now, thank you.
Reading DocBuilder.cs:GetXPathDocument(..) I assume that if I want
to let our users to be able to get IP console help on our own C#
libraries, we can place the XML docs in a culture subdirectory under
the DLLs install directory, right?
This is generated from the XML document that lives adjacent to the
assembly containing the code. For instance, mscorlib is typically
located someplace like
C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll, so the
XML file is taken from
C:\Windows\Microsoft.NET\Framework\v2.0.50727\en\mscorlib.xml
(assuming CurrentCulture is English).
The source code for this can be found in DocBuilder.cs
On Mon, Dec 15, 2008 at 4:52 AM, Hernán Martínez Foffani
hernan.marti...@ecc.es wrote:
Where does IP find the help content for .NET libraries?
I mean, for instance, the output of
help(System.DateTime.ToBoolean)
Does it parse the Help.2 files? If so where does it look
for them? Only under %ALLUSERSPROFILE%\{Program Data}\Microsoft
Help?
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython and file descriptors
Presumably CPython is linking against msvcrt and is using the C abstraction rather than calling the Win32 APIs which return handles directly. As Curt said the biggest problem for us is that .NET does not expose C file descriptors. Therefore we could fix this by P/Invoking out to msvcrt. For users on other platforms we'd need to either add support for their platform or hope that their handles == C runtime file descriptors. For something like fileno maybe this is ok because it's an interop point only - or are there any non-interop uses of fileno in the world? What do people think of this? This would be the 1st place where we would add a P/Invoke so I'd want to tread lightly and make sure this is really the right thing to do. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Slide Sent: Monday, December 15, 2008 10:21 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython and file descriptors On Mon, Dec 15, 2008 at 11:18 AM, Tom Wright tom.wri...@resolversystems.com wrote: Agreed. It is certainly possible with some work to get a file descriptor and pass it to C code. This is not the problem, however. Ironclad's aim (eventually) is to allow *arbitrary* C extensions to work with Ironpython without changing the extensions. Ctypes aim is to allow arbitrary C code to be run by python (possibly in other python libraries which you really don't want to modify). In CPython .fileno() is a file descriptor and some modules use this fact (specifically PIL) by passing file descriptors as integers into C code. I do not know how one can make this code work in IronPython unless .fileno() returns a file descriptor. The game here is not making a particular C library work with IronPython by modifying this library but making as many libraries as possible work without modification. Of course whether this is worthwhile depends on how many libraries rely on this fact. Sorry - I hope this is a little clearer. Tom How does CPython get the file descriptor for fileno()? Does it just return the HANDLE on Windows? slide ___ 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] Help contents
If you have only one version/culture, I believe you can just place the XML
doc in the same directory as the DLL.
On Mon, Dec 15, 2008 at 10:45 AM, Hernán Martínez Foffani
hernan.marti...@ecc.es wrote:
It seems clear now, thank you.
Reading DocBuilder.cs:GetXPathDocument(..) I assume that if I want
to let our users to be able to get IP console help on our own C#
libraries, we can place the XML docs in a culture subdirectory under
the DLLs install directory, right?
This is generated from the XML document that lives adjacent to the
assembly containing the code. For instance, mscorlib is typically
located someplace like
C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll, so the
XML file is taken from
C:\Windows\Microsoft.NET\Framework\v2.0.50727\en\mscorlib.xml
(assuming CurrentCulture is English).
The source code for this can be found in DocBuilder.cs
On Mon, Dec 15, 2008 at 4:52 AM, Hernán Martínez Foffani
hernan.marti...@ecc.es wrote:
Where does IP find the help content for .NET libraries?
I mean, for instance, the output of
help(System.DateTime.ToBoolean)
Does it parse the Help.2 files? If so where does it look
for them? Only under %ALLUSERSPROFILE%\{Program Data}\Microsoft
Help?
___
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 and file descriptors
I guess I'm too much of a purist when it comes to managed code. But it would make me sad to P/Invoke by default for this purpose, even if Mono compatibility is the only real counterargument I can muster. On Mon, Dec 15, 2008 at 10:49 AM, Dino Viehland di...@microsoft.com wrote: Presumably CPython is linking against msvcrt and is using the C abstraction rather than calling the Win32 APIs which return handles directly. As Curt said the biggest problem for us is that .NET does not expose C file descriptors. Therefore we could fix this by P/Invoking out to msvcrt. For users on other platforms we'd need to either add support for their platform or hope that their handles == C runtime file descriptors. For something like fileno maybe this is ok because it's an interop point only - or are there any non-interop uses of fileno in the world? What do people think of this? This would be the 1st place where we would add a P/Invoke so I'd want to tread lightly and make sure this is really the right thing to do. -Original Message- From: users-boun...@lists.ironpython.com [mailto: users-boun...@lists.ironpython.com] On Behalf Of Slide Sent: Monday, December 15, 2008 10:21 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython and file descriptors On Mon, Dec 15, 2008 at 11:18 AM, Tom Wright tom.wri...@resolversystems.com wrote: Agreed. It is certainly possible with some work to get a file descriptor and pass it to C code. This is not the problem, however. Ironclad's aim (eventually) is to allow *arbitrary* C extensions to work with Ironpython without changing the extensions. Ctypes aim is to allow arbitrary C code to be run by python (possibly in other python libraries which you really don't want to modify). In CPython .fileno() is a file descriptor and some modules use this fact (specifically PIL) by passing file descriptors as integers into C code. I do not know how one can make this code work in IronPython unless .fileno() returns a file descriptor. The game here is not making a particular C library work with IronPython by modifying this library but making as many libraries as possible work without modification. Of course whether this is worthwhile depends on how many libraries rely on this fact. Sorry - I hope this is a little clearer. Tom How does CPython get the file descriptor for fileno()? Does it just return the HANDLE on Windows? slide ___ 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
[IronPython] Determine the classes/interfaces a Python implements
I have a Python script that creates a class within it. This Python class is derived off of a class, or interface, I made in C# - something like: class MyClass(Test.MainForm.IScript): ... Now, back in C#, I have gotten access to MyClass by: object myclass = someScope.GetVariable(MyClass); Is there a way to determine either: a) what classes/interfaces MyClass implements OR b) if it implements a specific class/interface I want to know if the object myclass is supposed to implement Test.MainForm.IScript or not. I don't want to create an instance of MyClass as this would cause problems, executing things I'm not ready to execute. Also, related but not as important, implementing an interface (as above) doesn't cause any compiler errors if I'm missing functions - is there a way to enforce this? Thanks, Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython and file descriptors
2008/12/15 Dino Viehland di...@microsoft.com Presumably CPython is linking against msvcrt and is using the C abstraction rather than calling the Win32 APIs which return handles directly. As Curt said the biggest problem for us is that .NET does not expose C file descriptors. Therefore we could fix this by P/Invoking out to msvcrt. For users on other platforms we'd need to either add support for their platform or hope that their handles == C runtime file descriptors. For something like fileno maybe this is ok because it's an interop point only - or are there any non-interop uses of fileno in the world? What do people think of this? This would be the 1st place where we would add a P/Invoke so I'd want to tread lightly and make sure this is really the right thing to do. Well, some way of doing this is needed if certain Python C extensions are to work with Ironclad. Perhaps a global or per engine setting that allows file handles to be associated with a C descriptor. Users of Ironclad could switch it on if they wished and take the consequences. Michael Foord -Original Message- From: users-boun...@lists.ironpython.com [mailto: users-boun...@lists.ironpython.com] On Behalf Of Slide Sent: Monday, December 15, 2008 10:21 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython and file descriptors On Mon, Dec 15, 2008 at 11:18 AM, Tom Wright tom.wri...@resolversystems.com wrote: Agreed. It is certainly possible with some work to get a file descriptor and pass it to C code. This is not the problem, however. Ironclad's aim (eventually) is to allow *arbitrary* C extensions to work with Ironpython without changing the extensions. Ctypes aim is to allow arbitrary C code to be run by python (possibly in other python libraries which you really don't want to modify). In CPython .fileno() is a file descriptor and some modules use this fact (specifically PIL) by passing file descriptors as integers into C code. I do not know how one can make this code work in IronPython unless .fileno() returns a file descriptor. The game here is not making a particular C library work with IronPython by modifying this library but making as many libraries as possible work without modification. Of course whether this is worthwhile depends on how many libraries rely on this fact. Sorry - I hope this is a little clearer. Tom How does CPython get the file descriptor for fileno()? Does it just return the HANDLE on Windows? slide ___ 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] Determine the classes/interfaces a Python implements
Hi Jeff, Probably the easiest way of doing this is to define a Python function that uses issubtype. You can use this as a delegate from the C# side (warning untested): ScriptScope scope = engine.CreateScope(); ScriptSource imports = engine.CreateScriptSourceFromString(from System import ISomething, SourceCodeKind.Staatements); imports.Execute(scope); ScriptSource source = engine.CreateScriptSourceFromString(lambda x: issubtype(x, ISomething), SourceCodeKind.Expression); Funcobject, bool Implements = (scope)source.Execute(scope); bool result = Implements(some_object); Note that issubtype will barf if you give it anything other than a type, so it may make more sense to define a function with exception handling and pull it out of the scope instead. HTH Michael Foord Jeff Slutter wrote: I have a Python script that creates a class within it. This Python class is derived off of a class, or interface, I made in C# - something like: class MyClass(Test.MainForm.IScript): ... Now, back in C#, I have gotten access to MyClass by: object myclass = someScope.GetVariable(MyClass); Is there a way to determine either: a) what classes/interfaces MyClass implements OR b) if it implements a specific class/interface I want to know if the object myclass is supposed to implement Test.MainForm.IScript or not. I don't want to create an instance of MyClass as this would cause problems, executing things I'm not ready to execute. Also, related but not as important, implementing an interface (as above) doesn't cause any compiler errors if I'm missing functions - is there a way to enforce this? Thanks, Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Determine the classes/interfaces a Python implements
2008/12/16 Michael Foord fuzzy...@voidspace.org.uk: Probably the easiest way of doing this is to define a Python function that uses issubtype. You can use this as a delegate from the C# side (warning untested): You mean issubclass... -- Seo Sanghyeon ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Determine the classes/interfaces a Python implements
You should call PythonOps.IsSubClass and pass in the PythonType and the interface you want to compare it with. The interface can be either a .NET type object or another Python type object (or a tuple, etc...) The not raising on missing functions is a feature :) You could build a meta-class which would look at the incoming arguments and validate that all of the methods in an interface are implemented. That shouldn't be too hard - probably just seomthing like: assert (set(dir(someInterface)) set(newTypeDict)) == set(dir(someInterface)) -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeff Slutter Sent: Monday, December 15, 2008 12:15 PM To: Discussion of IronPython Subject: [IronPython] Determine the classes/interfaces a Python implements I have a Python script that creates a class within it. This Python class is derived off of a class, or interface, I made in C# - something like: class MyClass(Test.MainForm.IScript): ... Now, back in C#, I have gotten access to MyClass by: object myclass = someScope.GetVariable(MyClass); Is there a way to determine either: a) what classes/interfaces MyClass implements OR b) if it implements a specific class/interface I want to know if the object myclass is supposed to implement Test.MainForm.IScript or not. I don't want to create an instance of MyClass as this would cause problems, executing things I'm not ready to execute. Also, related but not as important, implementing an interface (as above) doesn't cause any compiler errors if I'm missing functions - is there a way to enforce this? Thanks, Jeff ___ 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] Determine the classes/interfaces a Python implements
Can you open a feature request on CodePlex? It's certainly an interesting idea to ponder and I'm leaning towards it but there's lots of details to be gotten right. Do you know if this needs to work w/ sockets as well? (There's also the question of can we make it work with sockets? :)) There'll be a bunch of places we need to update (nt, socket, file, select, etc...) so I think it'll have to wait until 2.1 instead of coming in a minor update like 2.0.1. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Monday, December 15, 2008 1:20 PM To: Discussion of IronPython Subject: Re: [IronPython] Determine the classes/interfaces a Python implements Hi Jeff, Probably the easiest way of doing this is to define a Python function that uses issubtype. You can use this as a delegate from the C# side (warning untested): ScriptScope scope = engine.CreateScope(); ScriptSource imports = engine.CreateScriptSourceFromString(from System import ISomething, SourceCodeKind.Staatements); imports.Execute(scope); ScriptSource source = engine.CreateScriptSourceFromString(lambda x: issubtype(x, ISomething), SourceCodeKind.Expression); Funcobject, bool Implements = (scope)source.Execute(scope); bool result = Implements(some_object); Note that issubtype will barf if you give it anything other than a type, so it may make more sense to define a function with exception handling and pull it out of the scope instead. HTH Michael Foord Jeff Slutter wrote: I have a Python script that creates a class within it. This Python class is derived off of a class, or interface, I made in C# - something like: class MyClass(Test.MainForm.IScript): ... Now, back in C#, I have gotten access to MyClass by: object myclass = someScope.GetVariable(MyClass); Is there a way to determine either: a) what classes/interfaces MyClass implements OR b) if it implements a specific class/interface I want to know if the object myclass is supposed to implement Test.MainForm.IScript or not. I don't want to create an instance of MyClass as this would cause problems, executing things I'm not ready to execute. Also, related but not as important, implementing an interface (as above) doesn't cause any compiler errors if I'm missing functions - is there a way to enforce this? Thanks, Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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] Determine the classes/interfaces a Python implements
(Dino clearly meant this to be a reply to the other thread with respect to C file descriptors. :) On Mon, Dec 15, 2008 at 1:24 PM, Dino Viehland di...@microsoft.com wrote: Can you open a feature request on CodePlex? It's certainly an interesting idea to ponder and I'm leaning towards it but there's lots of details to be gotten right. Do you know if this needs to work w/ sockets as well? (There's also the question of can we make it work with sockets? :)) There'll be a bunch of places we need to update (nt, socket, file, select, etc...) so I think it'll have to wait until 2.1 instead of coming in a minor update like 2.0.1. -Original Message- From: users-boun...@lists.ironpython.com [mailto: users-boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Monday, December 15, 2008 1:20 PM To: Discussion of IronPython Subject: Re: [IronPython] Determine the classes/interfaces a Python implements Hi Jeff, Probably the easiest way of doing this is to define a Python function that uses issubtype. You can use this as a delegate from the C# side (warning untested): ScriptScope scope = engine.CreateScope(); ScriptSource imports = engine.CreateScriptSourceFromString(from System import ISomething, SourceCodeKind.Staatements); imports.Execute(scope); ScriptSource source = engine.CreateScriptSourceFromString(lambda x: issubtype(x, ISomething), SourceCodeKind.Expression); Funcobject, bool Implements = (scope)source.Execute(scope); bool result = Implements(some_object); Note that issubtype will barf if you give it anything other than a type, so it may make more sense to define a function with exception handling and pull it out of the scope instead. HTH Michael Foord Jeff Slutter wrote: I have a Python script that creates a class within it. This Python class is derived off of a class, or interface, I made in C# - something like: class MyClass(Test.MainForm.IScript): ... Now, back in C#, I have gotten access to MyClass by: object myclass = someScope.GetVariable(MyClass); Is there a way to determine either: a) what classes/interfaces MyClass implements OR b) if it implements a specific class/interface I want to know if the object myclass is supposed to implement Test.MainForm.IScript or not. I don't want to create an instance of MyClass as this would cause problems, executing things I'm not ready to execute. Also, related but not as important, implementing an interface (as above) doesn't cause any compiler errors if I'm missing functions - is there a way to enforce this? Thanks, Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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 and file descriptors
Dino Viehland wrote: (now I’ve replied to the correct thread…) Can you open a feature request on CodePlex? It's certainly an interesting idea to ponder and I'm leaning towards it but there's lots of details to be gotten right. Do you know if this needs to work w/ sockets as well? (There's also the question of can we make it work with sockets? :)) There'll be a bunch of places we need to update (nt, socket, file, select, etc...) so I think it'll have to wait until 2.1 instead of coming in a minor update like 2.0.1. Tom will have to comment on whether it is needed for sockets as well. Not yet I guess. :-) Tom created an issue on Codeplex - I've added a comment to that: http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=20242 Michael *From:* users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] *On Behalf Of *Michael Foord *Sent:* Monday, December 15, 2008 12:53 PM *To:* Discussion of IronPython *Subject:* Re: [IronPython] IronPython and file descriptors 2008/12/15 Dino Viehland di...@microsoft.com mailto:di...@microsoft.com Presumably CPython is linking against msvcrt and is using the C abstraction rather than calling the Win32 APIs which return handles directly. As Curt said the biggest problem for us is that .NET does not expose C file descriptors. Therefore we could fix this by P/Invoking out to msvcrt. For users on other platforms we'd need to either add support for their platform or hope that their handles == C runtime file descriptors. For something like fileno maybe this is ok because it's an interop point only - or are there any non-interop uses of fileno in the world? What do people think of this? This would be the 1st place where we would add a P/Invoke so I'd want to tread lightly and make sure this is really the right thing to do. Well, some way of doing this is needed if certain Python C extensions are to work with Ironclad. Perhaps a global or per engine setting that allows file handles to be associated with a C descriptor. Users of Ironclad could switch it on if they wished and take the consequences. Michael Foord -Original Message- From: users-boun...@lists.ironpython.com mailto:users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com mailto:users-boun...@lists.ironpython.com] On Behalf Of Slide Sent: Monday, December 15, 2008 10:21 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython and file descriptors On Mon, Dec 15, 2008 at 11:18 AM, Tom Wright tom.wri...@resolversystems.com mailto:tom.wri...@resolversystems.com wrote: Agreed. It is certainly possible with some work to get a file descriptor and pass it to C code. This is not the problem, however. Ironclad's aim (eventually) is to allow *arbitrary* C extensions to work with Ironpython without changing the extensions. Ctypes aim is to allow arbitrary C code to be run by python (possibly in other python libraries which you really don't want to modify). In CPython .fileno() is a file descriptor and some modules use this fact (specifically PIL) by passing file descriptors as integers into C code. I do not know how one can make this code work in IronPython unless .fileno() returns a file descriptor. The game here is not making a particular C library work with IronPython by modifying this library but making as many libraries as possible work without modification. Of course whether this is worthwhile depends on how many libraries rely on this fact. Sorry - I hope this is a little clearer. Tom How does CPython get the file descriptor for fileno()? Does it just return the HANDLE on Windows? slide ___ Users mailing list Users@lists.ironpython.com mailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com mailto: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 -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Compiled dlls and builtin modules
I think this behavior is currently by design because we're using sys.meta_path which does take precedence over the built-in modules. We could switch to using sys.path_hooks in 2.1 or 3.0 if the consensus is this behavior in undesirable (which would also give control over when pre-compiled modules take precedence over other places on sys.path). Personally I'm +0 to make the change but this would probably break the other recently reported behavior w/ combinations on disk as .py files precompiled files :) From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Glenn Jones Sent: Friday, December 12, 2008 8:27 AM To: Discussion of IronPython Subject: [IronPython] Compiled dlls and builtin modules Hi all, We are compiling the python standard library (so it can be ngend when it is shipped with Resolver One) and we've discovered that modules in the dll take precedence over builtins. We noticed this because re and socket are included in the standard Lib directory (installed with IPy2) and when we ran against the dll built from the Lib, importing them failed. We have removed the following files from the standard library (and we may have to remove some others): socket, copy_reg, re, sre_compile, sre_constants, sre_parse (the sre_* were referenced in re) A better solution would be for builtin modules to take precedence over modules in referenced assemblies. As an experiment, we created a datetime module that just printed that it was being imported. When we included it in a dll and referenced it, it replaced the builtin datetime. Glenn Orestis ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Compiled dlls and builtin modules
Dino Viehland wrote: I think this behavior is currently by design because we’re using sys.meta_path which does take precedence over the built-in modules. We could switch to using sys.path_hooks in 2.1 or 3.0 if the consensus is this behavior in undesirable (which would also give control over when pre-compiled modules take precedence over other places on sys.path). Personally I’m +0 to make the change but this would probably break the other recently reported behavior w/ combinations on disk as .py files precompiled files J Another suggestion is that you stop including these unneeded modules in the version of the standard library shipped with the IronPython 2 installer. Michael *From:* users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] *On Behalf Of *Glenn Jones *Sent:* Friday, December 12, 2008 8:27 AM *To:* Discussion of IronPython *Subject:* [IronPython] Compiled dlls and builtin modules Hi all, We are compiling the python standard library (so it can be ngend when it is shipped with Resolver One) and we've discovered that modules in the dll take precedence over builtins. We noticed this because re and socket are included in the standard Lib directory (installed with IPy2) and when we ran against the dll built from the Lib, importing them failed. We have removed the following files from the standard library (and we may have to remove some others): socket, copy_reg, re, sre_compile, sre_constants, sre_parse (the sre_* were referenced in re) A better solution would be for builtin modules to take precedence over modules in referenced assemblies. As an experiment, we created a datetime module that just printed that it was being imported. When we included it in a dll and referenced it, it replaced the builtin datetime. Glenn Orestis ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Compiled dlls and builtin modules
Sounds waaay too easy :P. In the long run, I'd prefer that we implement only the C part of these modules and share the Python part with CPython. But this is not only a potentially breaking change, it also would require modification to the standard library for at least the socket module. On Mon, Dec 15, 2008 at 3:04 PM, Michael Foord fuzzy...@voidspace.org.ukwrote: Dino Viehland wrote: I think this behavior is currently by design because we're using sys.meta_path which does take precedence over the built-in modules. We could switch to using sys.path_hooks in 2.1 or 3.0 if the consensus is this behavior in undesirable (which would also give control over when pre-compiled modules take precedence over other places on sys.path). Personally I'm +0 to make the change but this would probably break the other recently reported behavior w/ combinations on disk as .py files precompiled files J Another suggestion is that you stop including these unneeded modules in the version of the standard library shipped with the IronPython 2 installer. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Invalid construct in DLR's MSBuild file?
This looks like a problem in quite a few of our csproj files. Could you open up a bug report on CodePlex for this? Thanks, -Curt On Wed, Dec 10, 2008 at 2:39 AM, Seo Sanghyeon sanx...@gmail.com wrote: Hello, now I am trying to use xbuild (open source implementation of MSBuild language) to build IronPython, and the first error (after instrumenting the source to make it clear what the error is) is this: $ xbuild Microsoft.Scripting.ExtensionAttribute.csproj XBuild Engine Version 0.1 Mono, Version 2.3.0.0 Copyright (C) Marek Sieradzki 2005. All rights reserved. ConditionParser failed to parse $(SilverlightBuild) != 'true' Unhandled Exception: Microsoft.Build.BuildEngine.InvalidProjectFileException: The requested feature is not implemented. --- System.NotImplementedException: The requested feature is not implemented. at Microsoft.Build.BuildEngine.ConditionParser.ParseFactorExpression () [0x0] at Microsoft.Build.BuildEngine.ConditionParser.ParseRelationalExpression () [0x0] at Microsoft.Build.BuildEngine.ConditionParser.ParseBooleanOr () [0x0] at Microsoft.Build.BuildEngine.ConditionParser.ParseBooleanAnd () [0x0] at Microsoft.Build.BuildEngine.ConditionParser.ParseBooleanExpression () [0x0] at Microsoft.Build.BuildEngine.ConditionParser.ParseExpression () [0x0] at Microsoft.Build.BuildEngine.ConditionParser.ParseCondition (System.String condition) [0x0] --- End of inner exception stack trace --- at Microsoft.Build.BuildEngine.Project.DoLoad (System.IO.TextReader textReader) [0x0] at Microsoft.Build.BuildEngine.Project.Load (System.String projectFileName) [0x0] at Mono.XBuild.CommandLine.MainClass.Execute () [0x0] According to MSDN, MSBuild Conditions http://msdn.microsoft.com/en-us/library/7szfhaft.aspx conditions should be of the form 'stringA' != 'stringB', where single quotes are not required for simple alphanumeric strings or boolean values. Is $(SilverlightBuild) this case? If it isn't, shouldn't it be quoted as '$(SilverlightBuild)'? If I manually change this condition to be quoted (I also note, all other uses of $(SilverlightBuild) is actually quoted in this file), xbuild builds this assembly successfully. Even if this is actually valid (then I argue documentation is confusing), I think it would be a good idea to quote this anyway. -- 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
Re: [IronPython] Compiled dlls and builtin modules
Yeah, it's funny, I thought we were supposed to have done that for at least some of them. Maybe these were just missed, but I agree we should definitely do at least that. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Monday, December 15, 2008 3:04 PM To: Discussion of IronPython Subject: Re: [IronPython] Compiled dlls and builtin modules Dino Viehland wrote: I think this behavior is currently by design because we're using sys.meta_path which does take precedence over the built-in modules. We could switch to using sys.path_hooks in 2.1 or 3.0 if the consensus is this behavior in undesirable (which would also give control over when pre-compiled modules take precedence over other places on sys.path). Personally I'm +0 to make the change but this would probably break the other recently reported behavior w/ combinations on disk as .py files precompiled files J Another suggestion is that you stop including these unneeded modules in the version of the standard library shipped with the IronPython 2 installer. Michael *From:* users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] *On Behalf Of *Glenn Jones *Sent:* Friday, December 12, 2008 8:27 AM *To:* Discussion of IronPython *Subject:* [IronPython] Compiled dlls and builtin modules Hi all, We are compiling the python standard library (so it can be ngend when it is shipped with Resolver One) and we've discovered that modules in the dll take precedence over builtins. We noticed this because re and socket are included in the standard Lib directory (installed with IPy2) and when we ran against the dll built from the Lib, importing them failed. We have removed the following files from the standard library (and we may have to remove some others): socket, copy_reg, re, sre_compile, sre_constants, sre_parse (the sre_* were referenced in re) A better solution would be for builtin modules to take precedence over modules in referenced assemblies. As an experiment, we created a datetime module that just printed that it was being imported. When we included it in a dll and referenced it, it replaced the builtin datetime. Glenn Orestis ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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] Issue about string.upper and string.lower
I've actually looked at this not too long ago and I think your proposal of calling the Invariant functions is the correct solution. I was looking at a few things: This bug http://bugs.python.org/issue1528802, the 3.0 decimal.py module, and also just using Turkish I at the command prompt. If you follow the comments the bug says: String upper and lower conversion are locale dependent and implemented by the underlying libc, whereas Unicode upper/lower conversion is not and only depends on the Unicode character database. That's a pretty clear statement that we shouldn't be using the current locale for our upper/lower string conversions. It wouldn't surprise me if that breaks something somewhere because we won't be doing locale dependent conversions on what someone expects to its type to be str not unicode but in this case I think it'd be better to be consistent with the Unicode side of Python as that's our future. As for the decimal module it doesn't change from 2.x to 3.0. So .upper() apparently doesn't have this problem when CPython switches to Unicode strings. Or at least no one's hit it, and when they do I think the resolution would be the same as 1528802. Finally at the command prompt I could never get CPython to do a culture-sensitive operation. I hadn't fully convinced myself on that part though because I hadn't yet escalated to a Turkish install of the OS running IronPython. But I'm still pretty confident we're at fault and we should change our lower/upper implementation. Obviously the change is easy but I'll do a full test pass to see if it breaks anything. I also think calling ToUpper to get non-Pythonic results is easy enough (I actually think it's kind of better this way - it saves typing out the framework friendly ToUpperInvariant :)). From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Glenn Jones Sent: Friday, December 12, 2008 7:27 AM To: Discussion of IronPython Subject: [IronPython] Issue about string.upper and string.lower Hello everybody, We ran across http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13629 (turkish collation issues) today while trying to port Resolver One to IronPython 2.0. This is in a test that tries to import decimal while in the turkish locale (it was actually reported by a user!). It does an .upper on a string with an 'i', and that doesn't give the expected results. This is a very big issue because all the python code out there expects string transformations to be locale-independent, and there may be strange bugs in strange places. Is mapping .upper and .lower to ToUpperInvariant and ToLowerInvariant an acceptable solution? People that want to do locale-dependent transformations can always use the .NET specific ToUpper/ToLower. We can work around the decimal being unimportable by hacking it, but clearly this is not a general solution. We will report other modules that might fail from this as we find them. Thanks, Glenn and Orestis ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
