[issue3182] 2to3 Slight Patch
New submission from Nick Edds <[EMAIL PROTECTED]>: This is a small patch to the 2to3 tool, replacing some calls to isinstance (x,y) with type(x) is y in the file pytree.py. Although there is only a slight performance increase for each time this change is made, the recursive nature of pattern matching means that isinstance was being calling hundreds of thousands of times per file, so overall these minor changes result in a 3-4% speed increase in my limited testing. It currently fails only one test due to line 432 in test_pytree, because I had to rename the type parameter to new_type so I could call type() on something. But with the line in the test file changed, it passes all tests. -- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) files: pytree.py messages: 68641 nosy: collinwinter, nedds severity: normal status: open title: 2to3 Slight Patch type: performance versions: Python 2.6 Added file: http://bugs.python.org/file10713/pytree.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3182> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3182] 2to3 Slight Patch
Nick Edds <[EMAIL PROTECTED]> added the comment: I don't think the improvement falls in margin of error, but maybe I'm wrong. The problem was that even when just run on a single file, isinstance was being called upwards of 100,000 times. I guess it doesn't merit inclusion on its own though, but with other things I'm working on, I think it makes sense. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3182> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3218] 2to3 Fix_imports optimization
New submission from Nick Edds <[EMAIL PROTECTED]>: This is an optimization in pytree.py specifically for the bare_name pattern from fix_imports.py. It also has the isinstance change I previously suggested piggybacked onto it. Because the bare_name pattern is so massive (764 nodes!), it is very slow to call _recursive_matches on it. This fix has a special bare_name_matches fix that uses an iterative matching solution specifically tailored to the bare_name pattern. From preliminary testing, it appears to be roughly 25-30% faster than the previous version of 2to3. If I uncomment the fix_imports test, it fails 6 of them, but they are the same ones failed by the current version of 2to3 and it fails them in the same way, so I think it works. As with my previous isinstance chance, a one line change to test_pytree is required. -- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) files: pytree.py messages: 68840 nosy: collinwinter, nedds severity: normal status: open title: 2to3 Fix_imports optimization type: performance Added file: http://bugs.python.org/file10751/pytree.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3218> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3218] 2to3 Fix_imports optimization
Nick Edds <[EMAIL PROTECTED]> added the comment: Here are the changes we talked about to fix_imports.py which remove the functionality for members. This causes a substantial performance boost, as fix_imports was the main bottleneck for 2to3. Added file: http://bugs.python.org/file10756/fix_imports.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3218> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3218] 2to3 Fix_imports optimization
Nick Edds <[EMAIL PROTECTED]> added the comment: Here is a diff for the both the fix_imports changes which I corrected, and the pytree changes. The pytree changes were a lot more significant before the fix_imports change, but I think they are still a decent improvement. I think I have now restored the functionality you wanted without the members, although I'm not quite sure I made the patterns exactly right. I tested the from a import b as c, as well as in text foo.bar references, and they seemed to be corrected properly. -- keywords: +patch Added file: http://bugs.python.org/file10791/fix_imports.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3218> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3316] Proposal for fix_urllib
New submission from Nick Edds <[EMAIL PROTECTED]>: Here is my proposed fix_urllib. The transform function is massive because there are a lot of cases, so maybe I should break it into separate functions for each case, and it could maybe do with some more documentation as well. I also use FromImport from fixer_util.py even though it warns against doing so for dotted imports because it appears to work. The temp.py file is a dummy python file that you can test it on to get an idea of what it does. I think it's got all the desired functionality, but I'm not an expert on the urllib changes so let me know if I missed anything. I haven't written tests for it yet, but assuming it looks reasonable, I can do that later today or tomorrow. -- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) files: fix_urllib.diff keywords: patch messages: 69395 nosy: brett.cannon, collinwinter, nedds severity: normal status: open title: Proposal for fix_urllib Added file: http://bugs.python.org/file10845/fix_urllib.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3316> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3316] Proposal for fix_urllib
Nick Edds <[EMAIL PROTECTED]> added the comment: I broke up transform into the logical pieces of it, so I think now the code is a little bit more clear. Added file: http://bugs.python.org/file10846/fix_urllib.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3316> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3182] 2to3 Slight Patch
Nick Edds <[EMAIL PROTECTED]> added the comment: Fair enough. I guess that even though there's a little bit of a performance improvement from this, it does hurt extensibility, so its probably not a worthwhile change after all. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3182> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3218] 2to3 Fix_imports optimization
Nick Edds <[EMAIL PROTECTED]> added the comment: Yeah that import_as_names definitely shouldn't be there. I don't know what I was thinking at the time, but that should just be an any I believe. I'll clean this up today or tomorrow, update fix_imports2 as well, and try to fix the tests for fix_imports. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3218> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3358] 2to3 Iterative Wildcard Matching
New submission from Nick Edds <[EMAIL PROTECTED]>: Here is an iterative replacement to _recursive_matches for Wildcard Patterns. It's not really much faster now, although I think there is some room to improve it. It's doesn't seem like the most elegant solution, but it works. It passes all of the tests, although I had to rewrite one because it was generating the same matches but in a different order. -- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) files: iterative.diff keywords: patch messages: 69672 nosy: collinwinter, nedds severity: normal status: open title: 2to3 Iterative Wildcard Matching Added file: http://bugs.python.org/file10896/iterative.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3358> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3316] Proposal for fix_urllib
Nick Edds <[EMAIL PROTECTED]> added the comment: I should be able to. What time would you need it by? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3316> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3316] Proposal for fix_urllib
Nick Edds <[EMAIL PROTECTED]> added the comment: I've got it finished, I just need to write some tests for it. It will all be done later tonight. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3316> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3316] Proposal for fix_urllib
Nick Edds <[EMAIL PROTECTED]> added the comment: Here is a working version with tests. I believe it has all the desired functionality, but correct me if I'm wrong Brett. Also, I did not model MAPPING as suggested by Collin because order was important in generating tests, so I didn't think using a dictionary would be appropriate. As for star imports, right now they aren't supported, although I don't quite understand why they couldn't be. Also, if this looks good, could somebody commit it for me. I don't think I have write privileges. Sorry this took me until so late tonight to submit, I hadn't realized the high priority it had until this morning. Added file: http://bugs.python.org/file10903/fix_urllib.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3316> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3218] 2to3 Fix_imports optimization
Nick Edds <[EMAIL PROTECTED]> added the comment: I can hopefully have it all fixed up by tonight or tomorrow. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3218> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3218] 2to3 Fix_imports optimization
Nick Edds <[EMAIL PROTECTED]> added the comment: It should be done tonight, but probably not until around 11 central time. Sorry for the delay. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3218> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3218] 2to3 Fix_imports optimization
Nick Edds <[EMAIL PROTECTED]> added the comment: Sorry I couldn't have this done earlier today. I updated the test suite, and this is now passing all tests. Collin, could you verify that is has all the functionality you were expecting? If the member functionality turns out to actually be important for any of the modules in fix_imports, it probably makes the most sense to break them out into their own fixer. As an added note, I think there is still further room to optimize fix_imports, specifically the very large pattern it still generates, so I'm going to work on that at some point. Added file: http://bugs.python.org/file10922/fix_imports.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3218> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3358] 2to3 Iterative Wildcard Matching
Nick Edds <[EMAIL PROTECTED]> added the comment: Just as an added note: with the new changes made to fix_imports, this is now noticeably slower than the recursive approach, even after I made a few optimizations like removing the unnecessary len() in the while loop. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3358> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3334] 2to3 looses indentation on import fix
Nick Edds <[EMAIL PROTECTED]> added the comment: I believe the problem was that in the case of this fix, rather than using set_prefix to give the new node the same prefix as before, new.prefix = was used. Here is the one line fix which preserves the prefix in the example given. -- keywords: +patch nosy: +nedds Added file: http://bugs.python.org/file10935/fix_import.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3334> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2894] 2to3 discards comments before import statements
Nick Edds <[EMAIL PROTECTED]> added the comment: This seems to have been the same problem that was causing whitespace to get lost before some imports. I believe the fix_import change I provided in that issue, issue 3334, also corrects this problem. -- nosy: +nedds ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2894> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2894] 2to3 discards comments before import statements
Nick Edds <[EMAIL PROTECTED]> added the comment: Yeah sorry. I can't commit changes, so I have the diff in the other issue but it has not yet been committed. Here it is again for redundancy. -- keywords: +patch Added file: http://bugs.python.org/file10938/fix_import.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2894> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2532] file that breaks 2to3 (despite being correct python)
Nick Edds <[EMAIL PROTECTED]> added the comment: My iterative pattern matching doesn't break on this file, but as mentioned elsewhere, the iterative solution is slower. I'll work on speeding it up, but I don't immediately see a good way to do so. Any ideas would be greatly appreciated. -- nosy: +nedds ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2532> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3448] Multi-process 2to3
New submission from Nick Edds <[EMAIL PROTECTED]>: Here is a working, multiprocess version of 2to3 with a few caveats. First, you need to already have the processing module installed for this to work. If we don't want to include processing in some way, I think I can modify this to only import processing and use the Process method if the user wants to run it with more than one process. Also, I know that logger is supposed to be thread safe, so I am correct in assuming that this means it is also multi-process safe? This fix delegates the fixing of files to a designated number of processes, so on a multi-core machine, it is significantly faster. It may be appropriate to add a test suite for it, but I have not yet done so. I've tested it on my dual-core laptop running Ubuntu and a quad-core mac and it appears to be working fine. I don't know if the use of tempfile was the right choice, but it seemed reasonable. Another possibility is to instead using a processing Queue and pass it the output, filename, and input rather than calling write_file. Also, the join timeout I used is completely arbitrary because I don't really have a sense of what a reasonable value for it should be. -- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) files: multiProcess.diff keywords: patch messages: 70277 nosy: collinwinter, nedds severity: normal status: open title: Multi-process 2to3 type: performance Added file: http://bugs.python.org/file10985/multiProcess.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3448> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3448] Multi-process 2to3
Nick Edds <[EMAIL PROTECTED]> added the comment: Here is a version that only imports processing if the multi-process option is specified. I don't know if this is the most efficient way it can be done, and I think there's a better way to do it, but this works. Added file: http://bugs.python.org/file10986/multiProcess2.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3448> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3358] 2to3 Iterative Wildcard Matching
Nick Edds <[EMAIL PROTECTED]> added the comment: I don't think it would be hard to implement, I just need a good, fast metric to determine if a file should be processed iteratively or recursively. What do you think would be the best way to do this? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3358> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3480] Fix_imports pattern optimization
New submission from Nick Edds <[EMAIL PROTECTED]>: Here is a substantial improvement to the pattern for fix_imports. It significantly reduces the size of the previous pattern and represents it in a more reasonable way. It still passes all of the tests and it also makes 2to3 roughly two to three times as fast based on the results of some basic testing. -- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) files: fix_imports_pattern.diff keywords: patch messages: 70528 nosy: collinwinter, nedds severity: normal status: open title: Fix_imports pattern optimization type: performance Added file: http://bugs.python.org/file11019/fix_imports_pattern.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3480> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3358] 2to3 Iterative Wildcard Matching
Nick Edds <[EMAIL PROTECTED]> added the comment: Sounds good to me. I should have a chance to implement this and submit it within the next couple of days. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3358> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3358] 2to3 Iterative Wildcard Matching
Nick Edds <[EMAIL PROTECTED]> added the comment: Here is a patch that tries to use the faster recursive matching, but if there is a RuntimeError, it will use the iterative matching. It passes all the tests and works on the ssl.py file that were known to break the recursive matching. Added file: http://bugs.python.org/file11058/iterative_recursive.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3358> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2470] Need fixer for dl (removed) -> ctypes module
Nick Edds <[EMAIL PROTECTED]> added the comment: If nobody else is interested in or currently in the process of making a fixer for this, I can do it. I'm not sure if I completely understand the changes I need to make though. Importing dl needs to be replaced by importing ctypes, calls to dl.open() need to be replaced by calls to ctypes.CDLL(), and calls to call() from an open dl object need to be replaced to calls to funcname, where funcname is the first argument to call(). Also, any strings in the other arguments should be preceded with b to make them byte objects. Is this all that needs doing or am I missing something else? Are there more complicated cases that I should also take into account? -- nosy: +nedds ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2470> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2876] Write UserDict fixer for 2to3
Nick Edds <[EMAIL PROTECTED]> added the comment: What's the current status of this? If nobody is working on it, I would be willing to give it a shot. Can somebody just confirm that I have a correct understanding of the problem. UserDict.UserDict needs a deprecation warning, UserDict.IterableUserDict becomes collections.UserDict, and UserDict.Mixin becomes collections.MutableMapping. Then for keys(), items(), and values(), I want to replace something like d.keys() to list(d.keys()). One added question: based on what I gathered from PEP 3106, this last part is only needed in a situation such as a = d.keys(), but not a situation like for key in keys:, so because in the later case wrapping the call to keys() in list() would presumably be suboptimal, is this something I should try and avoid? I'm not sure exactly how it could be done, but I have some idea of how it to do it. -- nosy: +nedds ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2876> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2876] Write UserDict fixer for 2to3
Nick Edds <[EMAIL PROTECTED]> added the comment: Ahh right. I totally forgot that there was already a fix_dict.py that took care of that. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2876> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2876] Write UserDict fixer for 2to3
Nick Edds <[EMAIL PROTECTED]> added the comment: I've been thinking about this a bit, and I don't see how handling it should be all that different from handling module renaming. For import UserDict, we can just change UserDict to collections and deal with UserDict.UserDict with a deprecation warning and UserDict.IterableUserDict and UserDict.Mixin with transformations to collections.UserDict and collections.MutableMapping. For from imports, we can raise the deprecation warning on UserDict, and otherwise change from UserDict import ... to from collections import ... and then for non-import appearances of UserDict, IterableUserDict, and Mixin rename or raise a deprecation warning as appropriate. For the other import cases, similar things could be done. I think the old version of fix_imports, which had support like this, would basically be all that we need. I should be able to mimic that functionality, but also make it more scalable than the previous version. Is there something I'm missing here about the difference between modules and classes? From the use-cases I've observed of UserDict, it seems like this functionality would be sufficient. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2876> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2876] Write UserDict fixer for 2to3
Nick Edds <[EMAIL PROTECTED]> added the comment: How soon is this needed by? I probably won't have a chance to do it in the next week, but it shouldn't take that long to make once I get a chance to work on it. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2876> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2876] Write UserDict fixer for 2to3
Nick Edds <[EMAIL PROTECTED]> added the comment: Sorry about the delay with this. I've finally found some time to work on this, so it should be completed within the next couple of days. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2876> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3358] 2to3 Iterative Wildcard Matching
Nick Edds <[EMAIL PROTECTED]> added the comment: What do you think would be the best way to implement a test for this? To test it, I ran it on a known file that caused the old recursive method to fail, but I don't know if it makes sense to include that with the tests. I could always write a test to verify that the iterative element works, but as for testing the transition from recursive to iterative when the recursion limit is exceeded, do you think that is something I should do, and is there a better way than simply including the file that I know causes the recursion limit to be exceeded? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3358> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2876] Write UserDict fixer for 2to3
Nick Edds <[EMAIL PROTECTED]> added the comment: I have the functionality for this working, and will post it tomorrow when I complete its test suite. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2876> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2876] Write UserDict fixer for 2to3
Nick Edds <[EMAIL PROTECTED]> added the comment: Here is a fixer and test suite for the UserDict. It doesn't do a very good job handling imports with 'as' right now, but it's core functionality appears to be working. If I get a chance I will improve its handling of 'as' cases at some point in the future, but I think this is an alright start. It passes all tests. -- keywords: +patch Added file: http://bugs.python.org/file11634/fix_userdict.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2876> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2876] Write UserDict fixer for 2to3
Nick Edds <[EMAIL PROTECTED]> added the comment: Could somebody else take a look at this and check in it if it looks alright? I think that it works currently but I can't check it in... ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2876> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3448] Multi-process 2to3
Nick Edds <[EMAIL PROTECTED]> added the comment: Is there still any interest in this Collin? Is there anything else you need me to do for it? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3448> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3448] Multi-process 2to3
Nick Edds <[EMAIL PROTECTED]> added the comment: The currently attached patch works in Python2.5 not Python2.6, so I will update it for 2.6 when I get the chance. But as it is currently written, the default behavior is not multiprocess. Instead, if you want multiprocess, you specify how many processes you want when you run 2to3 from the command line. And as long as you've got multiple files to run 2to3 on and multiple cores, doing multiprocess 2to3 is significantly faster. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3448> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3994] import fixer misses some symbols
Nick Edds <[EMAIL PROTECTED]> added the comment: I'll look in to it. Just give me a couple of days. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3994> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3994] import fixer misses some symbols
Nick Edds <[EMAIL PROTECTED]> added the comment: The problem is that fix_imports doesn't look at matches that are nested within matches. So the _winreg.OpenKey part gets fixed, but the _winreg.HKEY_LOCAL_MACHINE does not because it is nested within the other node. I didn't make fix_imports so I don't know what the intention was for not matching nested matches. When I removed that restriction, the fixer works as expected. It also does not cause any of 2to3's tests to fail nor does it have a noticeable impact on 2to3's runtime, so I'm tempted to say that this is the fix to make, but I don't want to commit to it until I've heard from it's author about it. I added Collin to the Nosy List, so hopefully he can comment on the reasoning behind the restriction. -- nosy: +collinwinter ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3994> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3994] import fixer misses some symbols
Nick Edds <[EMAIL PROTECTED]> added the comment: Here is a patch with a new test case. I don't know if we should apply it until we've heard from Collin though. The old version of fix_imports fails the new test, but this version, which allows matching of nodes nested within matches, passes the new test I added for nesting, as well as all of the other 2to3 tests. -- keywords: +patch Added file: http://bugs.python.org/file11756/fix_imports_bug.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3994> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3448] Multi-process 2to3
Nick Edds <[EMAIL PROTECTED]> added the comment: I had very little experience with the processing module prior to the creation of this patch, and because pool objects are listed last in the documentation, I did not read about them because I saw a way to achieve what I wanted using Process. But having looked at the documentation for Pool, I think you are correct that it would be a much cleaner solution to the problem, as I was essentially implementing a Pool myself. I will post a new patch to reflect this change tomorrow. I will also submit the patch to take advantage of the fact that the multiprocessing module is included in Python2.6, as opposed to my prior patch which was designed for Python2.5 which required the user to get the processing module. And in the patch, as before, multiprocess will not be default, but it will be something the user can enable via the command line. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3448> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
