From: SourceForge.net <no...@so...> - 2007-10-22 02:11:13
|
Patches item #1817565, was opened at 2007-10-21 19:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=1817565&group_id=12867 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Byron Foster (byronf) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for [1816134] passing dictionaries to java Initial Comment: This patch provides an implementation for the java.util.Map interface on the PyDictionary object. This allows passing a dictionary created in Jython to java methods. The patch provides associated wrapper classes so that the dictionary can be manipulated in java, and the changes will be reflected in Jython. This patch applies to Trunk, It also looks like it will apply to 2.2.1 but there's a little conflict around the imports. There patch adds two additional files: src/org/python/core/Dict2JavaTest - for unit tests in java code (had to do this because some tests can't be run in jython). Lib/test/test_dict2java.py - Jython unit testing script. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=1817565&group_id=12867 |
From: SourceForge.net <no...@so...> - 2007-10-24 20:00:11
|
Patches item #1817565, was opened at 2007-10-21 19:11 Message generated for change (Comment added) made by byronf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=1817565&group_id=12867 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Byron Foster (byronf) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for [1816134] passing dictionaries to java Initial Comment: This patch provides an implementation for the java.util.Map interface on the PyDictionary object. This allows passing a dictionary created in Jython to java methods. The patch provides associated wrapper classes so that the dictionary can be manipulated in java, and the changes will be reflected in Jython. This patch applies to Trunk, It also looks like it will apply to 2.2.1 but there's a little conflict around the imports. There patch adds two additional files: src/org/python/core/Dict2JavaTest - for unit tests in java code (had to do this because some tests can't be run in jython). Lib/test/test_dict2java.py - Jython unit testing script. ---------------------------------------------------------------------- >Comment By: Byron Foster (byronf) Date: 2007-10-24 13:00 Message: Logged In: YES user_id=110327 Originator: YES Added set functionality to values and keySet methods so that the collection returned is backed by PyDictionary. File Added: dict2java.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=1817565&group_id=12867 |
From: SourceForge.net <no...@so...> - 2007-12-02 00:42:42
|
Patches item #1817565, was opened at 2007-10-21 21:11 Message generated for change (Comment added) made by cgroves You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=1817565&group_id=12867 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Byron Foster (byronf) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for [1816134] passing dictionaries to java Initial Comment: This patch provides an implementation for the java.util.Map interface on the PyDictionary object. This allows passing a dictionary created in Jython to java methods. The patch provides associated wrapper classes so that the dictionary can be manipulated in java, and the changes will be reflected in Jython. This patch applies to Trunk, It also looks like it will apply to 2.2.1 but there's a little conflict around the imports. There patch adds two additional files: src/org/python/core/Dict2JavaTest - for unit tests in java code (had to do this because some tests can't be run in jython). Lib/test/test_dict2java.py - Jython unit testing script. ---------------------------------------------------------------------- >Comment By: Charles Groves (cgroves) Date: 2007-12-01 19:42 Message: Logged In: YES user_id=1174327 Originator: NO The internal view collections of PyMapEntrySet and PyMapKeyValSet are both expecting to extend PyMapSet, but there is no such class in the patch. I'm guessing PyMapCollection was supposed to be renamed to PyMapSet? Those two classes also need to implement Set to be acceptable as return values from keySet and entrySet, so perhaps PyMapSet was supposed to implement Set? From a cursory examining, it seems like PyMapCollection/Set could be greatly simplified by extending AbstractSet rather than implementing the whole interface on its own. Many of the implemented methods could just go away. The iterator implementation is identical between the two Set classes, so it should be shared in the super class. Unless there's a name conflict, a Java class should be imported with an import statement and just its short name should be used in the code. I see the full use of java.util.Iterator. I'd move the values method down into the Map implementation section now that it belongs there. It'd be better to move Dict2JavaTest into Lib/src/javatests so it's separated out with the tests. Tests using unittest.TestCases are much preferred to a list of asserts as in test_dict2java.py. With a list of asserts, the first test failure means the rest of the tests aren't run which makes it harder to track down errors. I haven't run the tests yet since this doesn't compile, but if you'll fix the first few errors I can run the tests and really evaluate the patch. The suboptimal use of asserts isn't a deal breaker, it'd just be nice if it were fixed. ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-10-24 15:00 Message: Logged In: YES user_id=110327 Originator: YES Added set functionality to values and keySet methods so that the collection returned is backed by PyDictionary. File Added: dict2java.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=1817565&group_id=12867 |
From: SourceForge.net <no...@so...> - 2007-12-05 06:07:20
|
Patches item #1817565, was opened at 2007-10-21 19:11 Message generated for change (Comment added) made by byronf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=1817565&group_id=12867 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Byron Foster (byronf) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for [1816134] passing dictionaries to java Initial Comment: This patch provides an implementation for the java.util.Map interface on the PyDictionary object. This allows passing a dictionary created in Jython to java methods. The patch provides associated wrapper classes so that the dictionary can be manipulated in java, and the changes will be reflected in Jython. This patch applies to Trunk, It also looks like it will apply to 2.2.1 but there's a little conflict around the imports. There patch adds two additional files: src/org/python/core/Dict2JavaTest - for unit tests in java code (had to do this because some tests can't be run in jython). Lib/test/test_dict2java.py - Jython unit testing script. ---------------------------------------------------------------------- >Comment By: Byron Foster (byronf) Date: 2007-12-04 23:07 Message: Logged In: YES user_id=110327 Originator: YES File Added: dict2java_v2.patch ---------------------------------------------------------------------- Comment By: Charles Groves (cgroves) Date: 2007-12-01 17:42 Message: Logged In: YES user_id=1174327 Originator: NO The internal view collections of PyMapEntrySet and PyMapKeyValSet are both expecting to extend PyMapSet, but there is no such class in the patch. I'm guessing PyMapCollection was supposed to be renamed to PyMapSet? Those two classes also need to implement Set to be acceptable as return values from keySet and entrySet, so perhaps PyMapSet was supposed to implement Set? From a cursory examining, it seems like PyMapCollection/Set could be greatly simplified by extending AbstractSet rather than implementing the whole interface on its own. Many of the implemented methods could just go away. The iterator implementation is identical between the two Set classes, so it should be shared in the super class. Unless there's a name conflict, a Java class should be imported with an import statement and just its short name should be used in the code. I see the full use of java.util.Iterator. I'd move the values method down into the Map implementation section now that it belongs there. It'd be better to move Dict2JavaTest into Lib/src/javatests so it's separated out with the tests. Tests using unittest.TestCases are much preferred to a list of asserts as in test_dict2java.py. With a list of asserts, the first test failure means the rest of the tests aren't run which makes it harder to track down errors. I haven't run the tests yet since this doesn't compile, but if you'll fix the first few errors I can run the tests and really evaluate the patch. The suboptimal use of asserts isn't a deal breaker, it'd just be nice if it were fixed. ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-10-24 13:00 Message: Logged In: YES user_id=110327 Originator: YES Added set functionality to values and keySet methods so that the collection returned is backed by PyDictionary. File Added: dict2java.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=1817565&group_id=12867 |
From: SourceForge.net <no...@so...> - 2007-12-05 06:26:34
|
Patches item #1817565, was opened at 2007-10-21 19:11 Message generated for change (Comment added) made by byronf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=1817565&group_id=12867 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Byron Foster (byronf) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for [1816134] passing dictionaries to java Initial Comment: This patch provides an implementation for the java.util.Map interface on the PyDictionary object. This allows passing a dictionary created in Jython to java methods. The patch provides associated wrapper classes so that the dictionary can be manipulated in java, and the changes will be reflected in Jython. This patch applies to Trunk, It also looks like it will apply to 2.2.1 but there's a little conflict around the imports. There patch adds two additional files: src/org/python/core/Dict2JavaTest - for unit tests in java code (had to do this because some tests can't be run in jython). Lib/test/test_dict2java.py - Jython unit testing script. ---------------------------------------------------------------------- >Comment By: Byron Foster (byronf) Date: 2007-12-04 23:26 Message: Logged In: YES user_id=110327 Originator: YES File Added: dict2java_v2.patch ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-12-04 23:07 Message: Logged In: YES user_id=110327 Originator: YES File Added: dict2java_v2.patch ---------------------------------------------------------------------- Comment By: Charles Groves (cgroves) Date: 2007-12-01 17:42 Message: Logged In: YES user_id=1174327 Originator: NO The internal view collections of PyMapEntrySet and PyMapKeyValSet are both expecting to extend PyMapSet, but there is no such class in the patch. I'm guessing PyMapCollection was supposed to be renamed to PyMapSet? Those two classes also need to implement Set to be acceptable as return values from keySet and entrySet, so perhaps PyMapSet was supposed to implement Set? From a cursory examining, it seems like PyMapCollection/Set could be greatly simplified by extending AbstractSet rather than implementing the whole interface on its own. Many of the implemented methods could just go away. The iterator implementation is identical between the two Set classes, so it should be shared in the super class. Unless there's a name conflict, a Java class should be imported with an import statement and just its short name should be used in the code. I see the full use of java.util.Iterator. I'd move the values method down into the Map implementation section now that it belongs there. It'd be better to move Dict2JavaTest into Lib/src/javatests so it's separated out with the tests. Tests using unittest.TestCases are much preferred to a list of asserts as in test_dict2java.py. With a list of asserts, the first test failure means the rest of the tests aren't run which makes it harder to track down errors. I haven't run the tests yet since this doesn't compile, but if you'll fix the first few errors I can run the tests and really evaluate the patch. The suboptimal use of asserts isn't a deal breaker, it'd just be nice if it were fixed. ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-10-24 13:00 Message: Logged In: YES user_id=110327 Originator: YES Added set functionality to values and keySet methods so that the collection returned is backed by PyDictionary. File Added: dict2java.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=1817565&group_id=12867 |
From: SourceForge.net <no...@so...> - 2007-12-05 06:27:52
|
Patches item #1817565, was opened at 2007-10-21 19:11 Message generated for change (Comment added) made by byronf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=1817565&group_id=12867 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Byron Foster (byronf) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for [1816134] passing dictionaries to java Initial Comment: This patch provides an implementation for the java.util.Map interface on the PyDictionary object. This allows passing a dictionary created in Jython to java methods. The patch provides associated wrapper classes so that the dictionary can be manipulated in java, and the changes will be reflected in Jython. This patch applies to Trunk, It also looks like it will apply to 2.2.1 but there's a little conflict around the imports. There patch adds two additional files: src/org/python/core/Dict2JavaTest - for unit tests in java code (had to do this because some tests can't be run in jython). Lib/test/test_dict2java.py - Jython unit testing script. ---------------------------------------------------------------------- >Comment By: Byron Foster (byronf) Date: 2007-12-04 23:27 Message: Logged In: YES user_id=110327 Originator: YES > The internal view collections of PyMapEntrySet and > PyMapKeyValSet are both expecting to extend PyMapSet, but there > is no such class in the patch. I'm guessing PyMapCollection > was supposed to be renamed to PyMapSet? Sorry, I goofed. There was a stale class on my side that allowed it to still compile. Fixed. > From a cursory examining, it seems like PyMapCollection/Set > could be greatly simplified by extending AbstractSet rather > than implementing the whole interface on its own. Many of the > implemented methods could just go away. Not Really, the problem is that (Which is true in general) objects retrieved from the dictionary in java code must pass through __tojava__, and java object being passed to the dictionary must use Py.java2py which utilizes the plugable PyObjectAdapter system. Using AbstractSet would eliminate size() and isEmpty(), but I think that's about it. Allot of the code implements the obscure java.util.Map#entrySet method which will probably never get used, but I added it for completeness. > The iterator implementation is identical between the two Set > classes, so it should be shared in the super class. Done > Unless there's a name conflict, a Java class should be imported > with an import statement and just its short name should be used > in the code. I see the full use of java.util.Iterator. Done > I'd move the values method down into the Map implementation > section now that it belongs there. Done > It'd be better to move Dict2JavaTest into Lib/src/javatests so > it's separated out with the tests. I found a Lib/test/javatests which I moved Dict2JavaTest to. Done > Tests using unittest.TestCases are much preferred to a list of > asserts as in test_dict2java.py. With a list of asserts, the > first test failure means the rest of the tests aren't run which > makes it harder to track down errors. Done ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-12-04 23:26 Message: Logged In: YES user_id=110327 Originator: YES File Added: dict2java_v2.patch ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-12-04 23:07 Message: Logged In: YES user_id=110327 Originator: YES File Added: dict2java_v2.patch ---------------------------------------------------------------------- Comment By: Charles Groves (cgroves) Date: 2007-12-01 17:42 Message: Logged In: YES user_id=1174327 Originator: NO The internal view collections of PyMapEntrySet and PyMapKeyValSet are both expecting to extend PyMapSet, but there is no such class in the patch. I'm guessing PyMapCollection was supposed to be renamed to PyMapSet? Those two classes also need to implement Set to be acceptable as return values from keySet and entrySet, so perhaps PyMapSet was supposed to implement Set? From a cursory examining, it seems like PyMapCollection/Set could be greatly simplified by extending AbstractSet rather than implementing the whole interface on its own. Many of the implemented methods could just go away. The iterator implementation is identical between the two Set classes, so it should be shared in the super class. Unless there's a name conflict, a Java class should be imported with an import statement and just its short name should be used in the code. I see the full use of java.util.Iterator. I'd move the values method down into the Map implementation section now that it belongs there. It'd be better to move Dict2JavaTest into Lib/src/javatests so it's separated out with the tests. Tests using unittest.TestCases are much preferred to a list of asserts as in test_dict2java.py. With a list of asserts, the first test failure means the rest of the tests aren't run which makes it harder to track down errors. I haven't run the tests yet since this doesn't compile, but if you'll fix the first few errors I can run the tests and really evaluate the patch. The suboptimal use of asserts isn't a deal breaker, it'd just be nice if it were fixed. ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-10-24 13:00 Message: Logged In: YES user_id=110327 Originator: YES Added set functionality to values and keySet methods so that the collection returned is backed by PyDictionary. File Added: dict2java.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=1817565&group_id=12867 |
From: SourceForge.net <no...@so...> - 2007-12-08 23:03:00
|
Patches item #1817565, was opened at 2007-10-21 21:11 Message generated for change (Comment added) made by cgroves You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=1817565&group_id=12867 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Byron Foster (byronf) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for [1816134] passing dictionaries to java Initial Comment: This patch provides an implementation for the java.util.Map interface on the PyDictionary object. This allows passing a dictionary created in Jython to java methods. The patch provides associated wrapper classes so that the dictionary can be manipulated in java, and the changes will be reflected in Jython. This patch applies to Trunk, It also looks like it will apply to 2.2.1 but there's a little conflict around the imports. There patch adds two additional files: src/org/python/core/Dict2JavaTest - for unit tests in java code (had to do this because some tests can't be run in jython). Lib/test/test_dict2java.py - Jython unit testing script. ---------------------------------------------------------------------- >Comment By: Charles Groves (cgroves) Date: 2007-12-08 18:02 Message: Logged In: YES user_id=1174327 Originator: NO > > From a cursory examining, it seems like PyMapCollection/Set > > could be greatly simplified by extending AbstractSet rather > > than implementing the whole interface on its own. Many of the > > implemented methods could just go away. > > Not Really, the problem is that (Which is true in general) > objects retrieved from the dictionary in java code must pass > through __tojava__, and java object being passed to the > dictionary must use Py.java2py which utilizes the plugable > PyObjectAdapter system. Using AbstractSet would eliminate size() > and isEmpty(), but I think that's about it. Allot of the code > implements the obscure java.util.Map#entrySet method which will > probably never get used, but I added it for completeness. Since most of AbstractSet operates on the Iterator returned by its concrete implementation, and PyMapSet has to implement iterator, the methods on AbstractSet will go through that iterator. I've attached a new version of your patch that uses AbstractSet and passes your tests. It eliminates 9 methods: hashCode, equals, retainAll, removeAll, containsAll, add, addAll, toArray and isEmpty. Am I missing something? ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-12-05 01:27 Message: Logged In: YES user_id=110327 Originator: YES > The internal view collections of PyMapEntrySet and > PyMapKeyValSet are both expecting to extend PyMapSet, but there > is no such class in the patch. I'm guessing PyMapCollection > was supposed to be renamed to PyMapSet? Sorry, I goofed. There was a stale class on my side that allowed it to still compile. Fixed. > From a cursory examining, it seems like PyMapCollection/Set > could be greatly simplified by extending AbstractSet rather > than implementing the whole interface on its own. Many of the > implemented methods could just go away. Not Really, the problem is that (Which is true in general) objects retrieved from the dictionary in java code must pass through __tojava__, and java object being passed to the dictionary must use Py.java2py which utilizes the plugable PyObjectAdapter system. Using AbstractSet would eliminate size() and isEmpty(), but I think that's about it. Allot of the code implements the obscure java.util.Map#entrySet method which will probably never get used, but I added it for completeness. > The iterator implementation is identical between the two Set > classes, so it should be shared in the super class. Done > Unless there's a name conflict, a Java class should be imported > with an import statement and just its short name should be used > in the code. I see the full use of java.util.Iterator. Done > I'd move the values method down into the Map implementation > section now that it belongs there. Done > It'd be better to move Dict2JavaTest into Lib/src/javatests so > it's separated out with the tests. I found a Lib/test/javatests which I moved Dict2JavaTest to. Done > Tests using unittest.TestCases are much preferred to a list of > asserts as in test_dict2java.py. With a list of asserts, the > first test failure means the rest of the tests aren't run which > makes it harder to track down errors. Done ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-12-05 01:26 Message: Logged In: YES user_id=110327 Originator: YES File Added: dict2java_v2.patch ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-12-05 01:07 Message: Logged In: YES user_id=110327 Originator: YES File Added: dict2java_v2.patch ---------------------------------------------------------------------- Comment By: Charles Groves (cgroves) Date: 2007-12-01 19:42 Message: Logged In: YES user_id=1174327 Originator: NO The internal view collections of PyMapEntrySet and PyMapKeyValSet are both expecting to extend PyMapSet, but there is no such class in the patch. I'm guessing PyMapCollection was supposed to be renamed to PyMapSet? Those two classes also need to implement Set to be acceptable as return values from keySet and entrySet, so perhaps PyMapSet was supposed to implement Set? From a cursory examining, it seems like PyMapCollection/Set could be greatly simplified by extending AbstractSet rather than implementing the whole interface on its own. Many of the implemented methods could just go away. The iterator implementation is identical between the two Set classes, so it should be shared in the super class. Unless there's a name conflict, a Java class should be imported with an import statement and just its short name should be used in the code. I see the full use of java.util.Iterator. I'd move the values method down into the Map implementation section now that it belongs there. It'd be better to move Dict2JavaTest into Lib/src/javatests so it's separated out with the tests. Tests using unittest.TestCases are much preferred to a list of asserts as in test_dict2java.py. With a list of asserts, the first test failure means the rest of the tests aren't run which makes it harder to track down errors. I haven't run the tests yet since this doesn't compile, but if you'll fix the first few errors I can run the tests and really evaluate the patch. The suboptimal use of asserts isn't a deal breaker, it'd just be nice if it were fixed. ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-10-24 15:00 Message: Logged In: YES user_id=110327 Originator: YES Added set functionality to values and keySet methods so that the collection returned is backed by PyDictionary. File Added: dict2java.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=1817565&group_id=12867 |
From: SourceForge.net <no...@so...> - 2007-12-08 23:03:42
|
Patches item #1817565, was opened at 2007-10-21 21:11 Message generated for change (Comment added) made by cgroves You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=1817565&group_id=12867 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Byron Foster (byronf) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for [1816134] passing dictionaries to java Initial Comment: This patch provides an implementation for the java.util.Map interface on the PyDictionary object. This allows passing a dictionary created in Jython to java methods. The patch provides associated wrapper classes so that the dictionary can be manipulated in java, and the changes will be reflected in Jython. This patch applies to Trunk, It also looks like it will apply to 2.2.1 but there's a little conflict around the imports. There patch adds two additional files: src/org/python/core/Dict2JavaTest - for unit tests in java code (had to do this because some tests can't be run in jython). Lib/test/test_dict2java.py - Jython unit testing script. ---------------------------------------------------------------------- >Comment By: Charles Groves (cgroves) Date: 2007-12-08 18:03 Message: Logged In: YES user_id=1174327 Originator: NO File Added: dict2java_groves.patch ---------------------------------------------------------------------- Comment By: Charles Groves (cgroves) Date: 2007-12-08 18:02 Message: Logged In: YES user_id=1174327 Originator: NO > > From a cursory examining, it seems like PyMapCollection/Set > > could be greatly simplified by extending AbstractSet rather > > than implementing the whole interface on its own. Many of the > > implemented methods could just go away. > > Not Really, the problem is that (Which is true in general) > objects retrieved from the dictionary in java code must pass > through __tojava__, and java object being passed to the > dictionary must use Py.java2py which utilizes the plugable > PyObjectAdapter system. Using AbstractSet would eliminate size() > and isEmpty(), but I think that's about it. Allot of the code > implements the obscure java.util.Map#entrySet method which will > probably never get used, but I added it for completeness. Since most of AbstractSet operates on the Iterator returned by its concrete implementation, and PyMapSet has to implement iterator, the methods on AbstractSet will go through that iterator. I've attached a new version of your patch that uses AbstractSet and passes your tests. It eliminates 9 methods: hashCode, equals, retainAll, removeAll, containsAll, add, addAll, toArray and isEmpty. Am I missing something? ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-12-05 01:27 Message: Logged In: YES user_id=110327 Originator: YES > The internal view collections of PyMapEntrySet and > PyMapKeyValSet are both expecting to extend PyMapSet, but there > is no such class in the patch. I'm guessing PyMapCollection > was supposed to be renamed to PyMapSet? Sorry, I goofed. There was a stale class on my side that allowed it to still compile. Fixed. > From a cursory examining, it seems like PyMapCollection/Set > could be greatly simplified by extending AbstractSet rather > than implementing the whole interface on its own. Many of the > implemented methods could just go away. Not Really, the problem is that (Which is true in general) objects retrieved from the dictionary in java code must pass through __tojava__, and java object being passed to the dictionary must use Py.java2py which utilizes the plugable PyObjectAdapter system. Using AbstractSet would eliminate size() and isEmpty(), but I think that's about it. Allot of the code implements the obscure java.util.Map#entrySet method which will probably never get used, but I added it for completeness. > The iterator implementation is identical between the two Set > classes, so it should be shared in the super class. Done > Unless there's a name conflict, a Java class should be imported > with an import statement and just its short name should be used > in the code. I see the full use of java.util.Iterator. Done > I'd move the values method down into the Map implementation > section now that it belongs there. Done > It'd be better to move Dict2JavaTest into Lib/src/javatests so > it's separated out with the tests. I found a Lib/test/javatests which I moved Dict2JavaTest to. Done > Tests using unittest.TestCases are much preferred to a list of > asserts as in test_dict2java.py. With a list of asserts, the > first test failure means the rest of the tests aren't run which > makes it harder to track down errors. Done ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-12-05 01:26 Message: Logged In: YES user_id=110327 Originator: YES File Added: dict2java_v2.patch ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-12-05 01:07 Message: Logged In: YES user_id=110327 Originator: YES File Added: dict2java_v2.patch ---------------------------------------------------------------------- Comment By: Charles Groves (cgroves) Date: 2007-12-01 19:42 Message: Logged In: YES user_id=1174327 Originator: NO The internal view collections of PyMapEntrySet and PyMapKeyValSet are both expecting to extend PyMapSet, but there is no such class in the patch. I'm guessing PyMapCollection was supposed to be renamed to PyMapSet? Those two classes also need to implement Set to be acceptable as return values from keySet and entrySet, so perhaps PyMapSet was supposed to implement Set? From a cursory examining, it seems like PyMapCollection/Set could be greatly simplified by extending AbstractSet rather than implementing the whole interface on its own. Many of the implemented methods could just go away. The iterator implementation is identical between the two Set classes, so it should be shared in the super class. Unless there's a name conflict, a Java class should be imported with an import statement and just its short name should be used in the code. I see the full use of java.util.Iterator. I'd move the values method down into the Map implementation section now that it belongs there. It'd be better to move Dict2JavaTest into Lib/src/javatests so it's separated out with the tests. Tests using unittest.TestCases are much preferred to a list of asserts as in test_dict2java.py. With a list of asserts, the first test failure means the rest of the tests aren't run which makes it harder to track down errors. I haven't run the tests yet since this doesn't compile, but if you'll fix the first few errors I can run the tests and really evaluate the patch. The suboptimal use of asserts isn't a deal breaker, it'd just be nice if it were fixed. ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-10-24 15:00 Message: Logged In: YES user_id=110327 Originator: YES Added set functionality to values and keySet methods so that the collection returned is backed by PyDictionary. File Added: dict2java.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=1817565&group_id=12867 |
From: SourceForge.net <no...@so...> - 2007-12-12 01:31:37
|
Patches item #1817565, was opened at 2007-10-21 19:11 Message generated for change (Comment added) made by byronf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=1817565&group_id=12867 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Byron Foster (byronf) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for [1816134] passing dictionaries to java Initial Comment: This patch provides an implementation for the java.util.Map interface on the PyDictionary object. This allows passing a dictionary created in Jython to java methods. The patch provides associated wrapper classes so that the dictionary can be manipulated in java, and the changes will be reflected in Jython. This patch applies to Trunk, It also looks like it will apply to 2.2.1 but there's a little conflict around the imports. There patch adds two additional files: src/org/python/core/Dict2JavaTest - for unit tests in java code (had to do this because some tests can't be run in jython). Lib/test/test_dict2java.py - Jython unit testing script. ---------------------------------------------------------------------- >Comment By: Byron Foster (byronf) Date: 2007-12-11 18:31 Message: Logged In: YES user_id=110327 Originator: YES > Since most of AbstractSet operates on the Iterator returned by its > concrete implementation, and PyMapSet has to implement iterator, the > methods on AbstractSet will go through that iterator. I've attached > a new version of your patch that uses AbstractSet and passes your > tests. It eliminates 9 methods: hashCode, equals, retainAll, > removeAll, containsAll, add, addAll, toArray and isEmpty. Am I > missing something? Yea, that looks good, I didn't realize that the AbstractSet explicitly used the Iterator for the interface, as opposed to an implementation detail subject to possible change. Could probably remove size() and clear() also. ---------------------------------------------------------------------- Comment By: Charles Groves (cgroves) Date: 2007-12-08 16:03 Message: Logged In: YES user_id=1174327 Originator: NO File Added: dict2java_groves.patch ---------------------------------------------------------------------- Comment By: Charles Groves (cgroves) Date: 2007-12-08 16:02 Message: Logged In: YES user_id=1174327 Originator: NO > > From a cursory examining, it seems like PyMapCollection/Set > > could be greatly simplified by extending AbstractSet rather > > than implementing the whole interface on its own. Many of the > > implemented methods could just go away. > > Not Really, the problem is that (Which is true in general) > objects retrieved from the dictionary in java code must pass > through __tojava__, and java object being passed to the > dictionary must use Py.java2py which utilizes the plugable > PyObjectAdapter system. Using AbstractSet would eliminate size() > and isEmpty(), but I think that's about it. Allot of the code > implements the obscure java.util.Map#entrySet method which will > probably never get used, but I added it for completeness. Since most of AbstractSet operates on the Iterator returned by its concrete implementation, and PyMapSet has to implement iterator, the methods on AbstractSet will go through that iterator. I've attached a new version of your patch that uses AbstractSet and passes your tests. It eliminates 9 methods: hashCode, equals, retainAll, removeAll, containsAll, add, addAll, toArray and isEmpty. Am I missing something? ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-12-04 23:27 Message: Logged In: YES user_id=110327 Originator: YES > The internal view collections of PyMapEntrySet and > PyMapKeyValSet are both expecting to extend PyMapSet, but there > is no such class in the patch. I'm guessing PyMapCollection > was supposed to be renamed to PyMapSet? Sorry, I goofed. There was a stale class on my side that allowed it to still compile. Fixed. > From a cursory examining, it seems like PyMapCollection/Set > could be greatly simplified by extending AbstractSet rather > than implementing the whole interface on its own. Many of the > implemented methods could just go away. Not Really, the problem is that (Which is true in general) objects retrieved from the dictionary in java code must pass through __tojava__, and java object being passed to the dictionary must use Py.java2py which utilizes the plugable PyObjectAdapter system. Using AbstractSet would eliminate size() and isEmpty(), but I think that's about it. Allot of the code implements the obscure java.util.Map#entrySet method which will probably never get used, but I added it for completeness. > The iterator implementation is identical between the two Set > classes, so it should be shared in the super class. Done > Unless there's a name conflict, a Java class should be imported > with an import statement and just its short name should be used > in the code. I see the full use of java.util.Iterator. Done > I'd move the values method down into the Map implementation > section now that it belongs there. Done > It'd be better to move Dict2JavaTest into Lib/src/javatests so > it's separated out with the tests. I found a Lib/test/javatests which I moved Dict2JavaTest to. Done > Tests using unittest.TestCases are much preferred to a list of > asserts as in test_dict2java.py. With a list of asserts, the > first test failure means the rest of the tests aren't run which > makes it harder to track down errors. Done ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-12-04 23:26 Message: Logged In: YES user_id=110327 Originator: YES File Added: dict2java_v2.patch ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-12-04 23:07 Message: Logged In: YES user_id=110327 Originator: YES File Added: dict2java_v2.patch ---------------------------------------------------------------------- Comment By: Charles Groves (cgroves) Date: 2007-12-01 17:42 Message: Logged In: YES user_id=1174327 Originator: NO The internal view collections of PyMapEntrySet and PyMapKeyValSet are both expecting to extend PyMapSet, but there is no such class in the patch. I'm guessing PyMapCollection was supposed to be renamed to PyMapSet? Those two classes also need to implement Set to be acceptable as return values from keySet and entrySet, so perhaps PyMapSet was supposed to implement Set? From a cursory examining, it seems like PyMapCollection/Set could be greatly simplified by extending AbstractSet rather than implementing the whole interface on its own. Many of the implemented methods could just go away. The iterator implementation is identical between the two Set classes, so it should be shared in the super class. Unless there's a name conflict, a Java class should be imported with an import statement and just its short name should be used in the code. I see the full use of java.util.Iterator. I'd move the values method down into the Map implementation section now that it belongs there. It'd be better to move Dict2JavaTest into Lib/src/javatests so it's separated out with the tests. Tests using unittest.TestCases are much preferred to a list of asserts as in test_dict2java.py. With a list of asserts, the first test failure means the rest of the tests aren't run which makes it harder to track down errors. I haven't run the tests yet since this doesn't compile, but if you'll fix the first few errors I can run the tests and really evaluate the patch. The suboptimal use of asserts isn't a deal breaker, it'd just be nice if it were fixed. ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-10-24 13:00 Message: Logged In: YES user_id=110327 Originator: YES Added set functionality to values and keySet methods so that the collection returned is backed by PyDictionary. File Added: dict2java.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=1817565&group_id=12867 |
From: SourceForge.net <no...@so...> - 2007-12-12 09:49:29
|
Patches item #1817565, was opened at 2007-10-21 21:11 Message generated for change (Comment added) made by cgroves You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=1817565&group_id=12867 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Byron Foster (byronf) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for [1816134] passing dictionaries to java Initial Comment: This patch provides an implementation for the java.util.Map interface on the PyDictionary object. This allows passing a dictionary created in Jython to java methods. The patch provides associated wrapper classes so that the dictionary can be manipulated in java, and the changes will be reflected in Jython. This patch applies to Trunk, It also looks like it will apply to 2.2.1 but there's a little conflict around the imports. There patch adds two additional files: src/org/python/core/Dict2JavaTest - for unit tests in java code (had to do this because some tests can't be run in jython). Lib/test/test_dict2java.py - Jython unit testing script. ---------------------------------------------------------------------- >Comment By: Charles Groves (cgroves) Date: 2007-12-12 04:49 Message: Logged In: YES user_id=1174327 Originator: NO It would be possible to remove the size and clear operations, but they're going to be so much faster on the actual collection than with an iterator on top of them. As such, I committed the AbstractSet version of the patch in r3802. Thanks! ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-12-11 20:31 Message: Logged In: YES user_id=110327 Originator: YES > Since most of AbstractSet operates on the Iterator returned by its > concrete implementation, and PyMapSet has to implement iterator, the > methods on AbstractSet will go through that iterator. I've attached > a new version of your patch that uses AbstractSet and passes your > tests. It eliminates 9 methods: hashCode, equals, retainAll, > removeAll, containsAll, add, addAll, toArray and isEmpty. Am I > missing something? Yea, that looks good, I didn't realize that the AbstractSet explicitly used the Iterator for the interface, as opposed to an implementation detail subject to possible change. Could probably remove size() and clear() also. ---------------------------------------------------------------------- Comment By: Charles Groves (cgroves) Date: 2007-12-08 18:03 Message: Logged In: YES user_id=1174327 Originator: NO File Added: dict2java_groves.patch ---------------------------------------------------------------------- Comment By: Charles Groves (cgroves) Date: 2007-12-08 18:02 Message: Logged In: YES user_id=1174327 Originator: NO > > From a cursory examining, it seems like PyMapCollection/Set > > could be greatly simplified by extending AbstractSet rather > > than implementing the whole interface on its own. Many of the > > implemented methods could just go away. > > Not Really, the problem is that (Which is true in general) > objects retrieved from the dictionary in java code must pass > through __tojava__, and java object being passed to the > dictionary must use Py.java2py which utilizes the plugable > PyObjectAdapter system. Using AbstractSet would eliminate size() > and isEmpty(), but I think that's about it. Allot of the code > implements the obscure java.util.Map#entrySet method which will > probably never get used, but I added it for completeness. Since most of AbstractSet operates on the Iterator returned by its concrete implementation, and PyMapSet has to implement iterator, the methods on AbstractSet will go through that iterator. I've attached a new version of your patch that uses AbstractSet and passes your tests. It eliminates 9 methods: hashCode, equals, retainAll, removeAll, containsAll, add, addAll, toArray and isEmpty. Am I missing something? ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-12-05 01:27 Message: Logged In: YES user_id=110327 Originator: YES > The internal view collections of PyMapEntrySet and > PyMapKeyValSet are both expecting to extend PyMapSet, but there > is no such class in the patch. I'm guessing PyMapCollection > was supposed to be renamed to PyMapSet? Sorry, I goofed. There was a stale class on my side that allowed it to still compile. Fixed. > From a cursory examining, it seems like PyMapCollection/Set > could be greatly simplified by extending AbstractSet rather > than implementing the whole interface on its own. Many of the > implemented methods could just go away. Not Really, the problem is that (Which is true in general) objects retrieved from the dictionary in java code must pass through __tojava__, and java object being passed to the dictionary must use Py.java2py which utilizes the plugable PyObjectAdapter system. Using AbstractSet would eliminate size() and isEmpty(), but I think that's about it. Allot of the code implements the obscure java.util.Map#entrySet method which will probably never get used, but I added it for completeness. > The iterator implementation is identical between the two Set > classes, so it should be shared in the super class. Done > Unless there's a name conflict, a Java class should be imported > with an import statement and just its short name should be used > in the code. I see the full use of java.util.Iterator. Done > I'd move the values method down into the Map implementation > section now that it belongs there. Done > It'd be better to move Dict2JavaTest into Lib/src/javatests so > it's separated out with the tests. I found a Lib/test/javatests which I moved Dict2JavaTest to. Done > Tests using unittest.TestCases are much preferred to a list of > asserts as in test_dict2java.py. With a list of asserts, the > first test failure means the rest of the tests aren't run which > makes it harder to track down errors. Done ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-12-05 01:26 Message: Logged In: YES user_id=110327 Originator: YES File Added: dict2java_v2.patch ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-12-05 01:07 Message: Logged In: YES user_id=110327 Originator: YES File Added: dict2java_v2.patch ---------------------------------------------------------------------- Comment By: Charles Groves (cgroves) Date: 2007-12-01 19:42 Message: Logged In: YES user_id=1174327 Originator: NO The internal view collections of PyMapEntrySet and PyMapKeyValSet are both expecting to extend PyMapSet, but there is no such class in the patch. I'm guessing PyMapCollection was supposed to be renamed to PyMapSet? Those two classes also need to implement Set to be acceptable as return values from keySet and entrySet, so perhaps PyMapSet was supposed to implement Set? From a cursory examining, it seems like PyMapCollection/Set could be greatly simplified by extending AbstractSet rather than implementing the whole interface on its own. Many of the implemented methods could just go away. The iterator implementation is identical between the two Set classes, so it should be shared in the super class. Unless there's a name conflict, a Java class should be imported with an import statement and just its short name should be used in the code. I see the full use of java.util.Iterator. I'd move the values method down into the Map implementation section now that it belongs there. It'd be better to move Dict2JavaTest into Lib/src/javatests so it's separated out with the tests. Tests using unittest.TestCases are much preferred to a list of asserts as in test_dict2java.py. With a list of asserts, the first test failure means the rest of the tests aren't run which makes it harder to track down errors. I haven't run the tests yet since this doesn't compile, but if you'll fix the first few errors I can run the tests and really evaluate the patch. The suboptimal use of asserts isn't a deal breaker, it'd just be nice if it were fixed. ---------------------------------------------------------------------- Comment By: Byron Foster (byronf) Date: 2007-10-24 15:00 Message: Logged In: YES user_id=110327 Originator: YES Added set functionality to values and keySet methods so that the collection returned is backed by PyDictionary. File Added: dict2java.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=312867&aid=1817565&group_id=12867 |