[Ironpython-users] IronPython, Daily Digest 3/26/2014

[CodePlex]

Hi ironpython,

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

In today's digest:ISSUES

1. [New comment] Enable Frames by default
2. [New comment] add support for pymongo
3. [New comment] add support for pymongo
4. [New comment] add support for pymongo
5. [New comment] add support for pymongo
6. [New comment] add support for pymongo
7. [New comment] add support for pymongo

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

ISSUES

1. [New comment] Enable Frames by default
http://ironpython.codeplex.com/workitem/34263
User vernondcole has commented on the issue:

"<p>A possible alternative would be to use an environment variable:<br>IronPython_Switches="X:FullFrames"</p><p>But even then, Frames should default to "On"<br></p>"-----------------

2. [New comment] add support for pymongo
http://ironpython.codeplex.com/workitem/35075
User jdhardy has commented on the issue:

"<p>datetime probably isn't expecting a long there. Should be easy enough to fix.</p>"-----------------

3. [New comment] add support for pymongo
http://ironpython.codeplex.com/workitem/35075
User vernondcole has commented on the issue:

"<p>This should be fixed in the source, not the runtime, IMHO, for two reasons:<br>First, the explicit Long integer is illegal in Python 3.<br>Second, values of "microsecond" large enough to requir a Long representation exceed the spec of datetime:<br>from "8.1.4. datetime Objects" I quote:</p><p>    The year, month and day arguments are required. tzinfo may be None, or an instance of a tzinfo subclass. The remaining arguments may be integers, in the following ranges:</p><p>        MINYEAR <= year <= MAXYEAR<br>        1 <= month <= 12<br>        1 <= day <= number of days in the given month and year<br>        0 <= hour < 24<br>        0 <= minute < 60<br>        0 <= second < 60<br>        0 <= microsecond < 1000000</p><p>    If an argument outside those ranges is given, ValueError is raised.<br>At most, we should emit a different exception.<br></p>"-----------------

4. [New comment] add support for pymongo
http://ironpython.codeplex.com/workitem/35075
User vernondcole has commented on the issue:

"<p>(Answering my own post) I have cloned the mongo-python-driver from github and will be looking into this. They are supposted to be Python 3 compatible so something is off-color here.</p><p></p>"-----------------

5. [New comment] add support for pymongo
http://ironpython.codeplex.com/workitem/35075
User robden has commented on the issue:

"<p>The code that causes the issue in pymongo is in the bson package in \__init\__.py:</p><p>```<br>def _get_date(data, position, as_class, tz_aware, uuid_subtype, compile_re):<br>    millis = <some code that results in a long><br>    diff = millis % 1000<br>    <some more code><br>    return dt.replace(microscond=diff*1000), position<br>```</p><p>Thus the value of microsecond is a long.  This is not a problem in CPython 2.x.  From the docs for 2.x:<br>```<br>class datetime.datetime(year, month, day[, hour[, minute[, second[, microsecond[, tzinfo]]]]])<br>The year, month and day arguments are required. tzinfo may be None, or an instance of a tzinfo subclass. The remaining arguments may be ints or longs, in the following ranges:<br>```</p><p>Longs are explicitly accepted in 2.x, so I believe they should be accepted by IronPython 2.x.  In Python 3, I suspect the issue will disappear since ints and longs are unified.</p><p>As a test, I forced microseconds into an int (not a good solution, but good enough to test the effects of a real solution), and pymongo worked as expected with no further exceptions, at least for simple inserts, updates, finds, and removes.<br></p>"-----------------

6. [New comment] add support for pymongo
http://ironpython.codeplex.com/workitem/35075
User paweljasinski has commented on the issue:

"<p>fix submitted for review https://github.com/IronLanguages/main/pull/183</p>"-----------------

7. [New comment] add support for pymongo
http://ironpython.codeplex.com/workitem/35075
User robden has commented on the issue:

"<p>Excellent!  This should fix the pymongo issue.  For completeness, should we do the same for all integer keys in replace() and, possibly, for integer keys in the datetime constructor?</p>"
----------------------------------------------



----------------------------------------------
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/20140327/a25e367a/attachment.html>