[Ironpython-users] IronPython, Daily Digest 10/28/2013

CodePlex no_reply at codeplex.com
Tue Oct 29 08:22:33 CET 2013


Hi ironpython,

Here's your Daily Digest of new issues for project "IronPython".

In today's digest:ISSUES

1. [New comment] Importing .NET types causes ImportExceptions (zipimport handler)
2. [New issue] help() commands from StdLib fail/hang

----------------------------------------------

ISSUES

1. [New comment] Importing .NET types causes ImportExceptions (zipimport handler)
http://ironpython.codeplex.com/workitem/34602
User sopelt has commented on the issue:

"<p>Thank you for the quick response.</p><p>> this behavior needs to be maintained for compatibility</p><p>So the importer architecture and implementation is specified to that detail?</p><p><br>> just tell the debugger to ignore those exceptions</p><p>I know that Visual Studio's "Just my Code" will help for many situations but we often run into the scenario that we want to see "significant" exceptions occuring in third party libraries.</p><p>> lightweight exceptions</p><p>What do you mean by lightweight exceptions in the context of .NET/DLR/IronPython? Is there a concept for that or do you mean using something like return codes? I don't expect this to be super-easy because the exception seems to be thrown by the zipimporter constructor.</p><p>I am not quite sure why the zipimporter needs to be consulted at all for non-zipfile situations but I must admit that I haven't looked into the spec and the code with too much detail...</p>"-----------------

2. [New issue] help() commands from StdLib fail/hang
http://ironpython.codeplex.com/workitem/34606
User owlmonkey has proposed the issue:

"We incorporate IronPython into our app as a console and it's super handy for reflection of our objects. Some folks like using the stdlib pydoc help commands to get a summary of object methods and usage. This started failing and/or hanging our process when we upgraded to IronPython 2.6.2 and now 2.7.4 so I finally dug into it.

Looks like the problem is in the StdLib, in that it doesn't recognize the "cli" returned from sys.platform in the pydoc module. As a result it chooses a pipedpager which then fails or hangs based on the output length.

Specifically it's in the code that determines what kind of pager to use, for long outputs. It checks for sys.platform to see if it should use a pipe (on unix presumably) or a temporary file or just stream the output directly. What's happening in our system on Windows or on Mono is that sys.platform returns "cli" and the code tries to use a pager that's not really supported. And then the IO.StreamWriter it uses can hang if it buffer overflows. My workaround for now is to add some code to check for a "cli" response to that file and have it return a plainpager instead of a pipedpager. This worked around the problem fully for us.

So when including the StdLib code into the IronPython project, would be super helpful to incorporate some diffs wherever it uses sys.platform based logic to also recognize "cli""
----------------------------------------------



----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.

To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20131029/02fcd93e/attachment.html>


More information about the Ironpython-users mailing list