Ahh sorry. This was in Python 2.5.
On Sat, Mar 28, 2009 at 1:20 AM, Terry Reedy tjre...@udel.edu wrote:
Nick Edds wrote:
Is there an easy way to figure out what the type of an AST Node is?
Specify version.
? If I
have a node n, doing type(n) doesn't help because it gives me type
Is there an easy way to figure out what the type of an AST Node is? If I
have a node n, doing type(n) doesn't help because it gives me type
'instance', but what I really want is If, or And, or whatever node type the
node actually is. I could always just look at n.__repr__(), because the repr
for
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
43 matches
Mail list logo
