Ok, the Pydev 1.4.2 is just out.
The major feature this release has been long awaited: each project can now have a different configured interpreter.
As a result of that change, some internal structures will have to be recreated. So, right after upgrading it's expected that Pydev will do some processing to make that right, and now, it has to gather the information for all the interpreters, and not only for the current one, so, be a bit patient while it does that (it'll do that just once).
Also, many fixes were made available, so, upgrading is really reccommended.
Tuesday, January 13, 2009
Monday, December 22, 2008
Pydev 1.4.1
Ok, after 1.4 a bug was found dealing with the licensing (for Pydev Extensions on Eclipse 3.4.1), so, this release fixes this one bug (so, it's only released again in fabioz.com, not on sourceforge).
Pydev 1.4
Yeap, Pydev 1.4 It's finally out ;-)
Major things include:
- Support for Python 3.0 and Python 2.6
- The context-based find definition was moved from Pydev Extensions to Pydev Open source (note that the context-independent part, which goes on to find a definition from all the available tokens in your workspace is still only available in Pydev Extensions)
- A major bug was fixed in the parser when multiple threads were making the parse (this became more evident in java 6 with its optimizations, so, if you found out you had warnings that sometimes appeared nonsense, it should be fixed now)
- Hovers were added for docstrings and to show variables when debugging
Aside from that, there are a bunch of other bugfixes available.
Note that there are some things that are probably still missing to say that the Python 3.0 support is a 100% finished (most notably, the coverage is still not available because the coverage.py module used still does not support it... so, it's waiting on that to properly support it) and as it's a really big change, there's probably a bunch of other things that are still missing... so, I'm waiting on the bug reports :)
Major things include:
- Support for Python 3.0 and Python 2.6
- The context-based find definition was moved from Pydev Extensions to Pydev Open source (note that the context-independent part, which goes on to find a definition from all the available tokens in your workspace is still only available in Pydev Extensions)
- A major bug was fixed in the parser when multiple threads were making the parse (this became more evident in java 6 with its optimizations, so, if you found out you had warnings that sometimes appeared nonsense, it should be fixed now)
- Hovers were added for docstrings and to show variables when debugging
Aside from that, there are a bunch of other bugfixes available.
Note that there are some things that are probably still missing to say that the Python 3.0 support is a 100% finished (most notably, the coverage is still not available because the coverage.py module used still does not support it... so, it's waiting on that to properly support it) and as it's a really big change, there's probably a bunch of other things that are still missing... so, I'm waiting on the bug reports :)
Saturday, December 20, 2008
Pydev: Python 2.6/3.0 support status
Finished topics on the support for Python 2.6 and Python 3.0:
- The grammar support is finished (a lot of work was done at this area, as the grammar changed quite a bit -- a good side-effect of that is that as I spent more time dealing with JavaCC and the AST construction, some good cleanups were done, and the parsing of all versions should be a bit faster now)
- Interpreter can be configured for those
- The project config can use the new grammars
- Code-completion is working
- Pretty printing of the new grammar seems to be complete
Things unfinished are:
- Debugger
- Unbuffered support (apparently, passing -u to the interpreter does not give unbuffered output anymore -- which is probably a regression bug), so, an acceptable workaround still needs to be found.
- Code coverage
- Code analysis must be checked with the new constructs
That's it... that support should finished pretty soon ;-)
- The grammar support is finished (a lot of work was done at this area, as the grammar changed quite a bit -- a good side-effect of that is that as I spent more time dealing with JavaCC and the AST construction, some good cleanups were done, and the parsing of all versions should be a bit faster now)
- Interpreter can be configured for those
- The project config can use the new grammars
- Code-completion is working
- Pretty printing of the new grammar seems to be complete
Things unfinished are:
- Debugger
- Unbuffered support (apparently, passing -u to the interpreter does not give unbuffered output anymore -- which is probably a regression bug), so, an acceptable workaround still needs to be found.
- Code coverage
- Code analysis must be checked with the new constructs
That's it... that support should finished pretty soon ;-)
Wednesday, November 26, 2008
Making code work in Python 2 and 3
Below are some tips for those interested in writing code that runs on Python 2 and Python 3 -- there are probably many other issues, but those were the ones I ran into while porting the code-completion code in Pydev (so, there's probably going to be a part 2 of this when I go on to port the debugger)
0. This may be one of the most important advices: breathe regularly while doing the porting... and be prepared to have uglier code waiting for you if you want to support both Python 2 and Python 3 -- if you do have a choice, don't try to support both versions of Python -- the way Python 3 is implemented, no one's supposed to do that.
1. Print can NEVER be used (use the write() method from objects or create your own print function -- with a different name and use it everywhere)
2. Catching exceptions putting the exception in a given var can NEVER be used (there's no compatible way of doing it in a way that's acceptable in both versions, so, just deal with it as you can using the traceback module)
3. socket.send needs bytearray: socket.send(bytearray(str, 'utf-8'))
4. socket.receive gets bytes (so, they need to be decoded: socket.recv(size).decode('utf-8')
5. Some imports:
try:
import StringIO
except:
import io as StringIO #Python 3.0
try:
from urllib import quote_plus, unquote_plus
except ImportError:
from urllib.parse import quote_plus, unquote_plus #Python 3.0
try:
import __builtin__
except ImportError:
import builtins as __builtin__ #Python 3.0
There are way too many others, so, the approach for getting it right is basically running the 2to3 with that import to see the new version of it and then making it work as it used to.
6. True, False assign: in some scripts, to support older python/jython versions, the following construct was used:
__builtin__.True = 1
__builtin__.False = 0
As True and False are keywords now, this assignment will give a syntax error, so, to keep it working, one must do:
setattr(__builtin__, 'True', 1) -- as this will only be executed if True is not defined, that should be ok.
7. The long representation for values is not accepted anymore, so, 2L would not be accepted in python 3.
The solution for something as long_2 = 2L may be something as:
try:
long
except NameError:
long = int
long_2 = long(2)
Note that if you want to define a number that's already higher than the int limit, that won't actually help you (in my particular case, that was used on some arithmetic, just to make sure that the number would be coerced to a long, so, that solution is ok -- note: if you were already on python 2.5, that would not be needed as the conversion int -> long is already automatic)
8. raw_input is now input and input should be written explicitly as eval(raw_input('enter value'))
So, to keep backwards compatibility, I think the best approach would be keeping on with the raw_input (and writing the "old input" explicitly, while removing the "new input" reference from the builtins)
try:
raw_input
except NameError:
import builtins
original_input = builtins.input
del builtins.input
def raw_input(*args, **kwargs):
return original_input(*args, **kwargs)
builtins.raw_input = raw_input
9. The compiler module is gone. So, to parse something, the solution seems to be using ast.parse and to compile, there's the builtins.compile (NOTE: right now, the 2to3 script doesn't seem to get this correctly)
0. This may be one of the most important advices: breathe regularly while doing the porting... and be prepared to have uglier code waiting for you if you want to support both Python 2 and Python 3 -- if you do have a choice, don't try to support both versions of Python -- the way Python 3 is implemented, no one's supposed to do that.
1. Print can NEVER be used (use the write() method from objects or create your own print function -- with a different name and use it everywhere)
2. Catching exceptions putting the exception in a given var can NEVER be used (there's no compatible way of doing it in a way that's acceptable in both versions, so, just deal with it as you can using the traceback module)
3. socket.send needs bytearray: socket.send(bytearray(str, 'utf-8'))
4. socket.receive gets bytes (so, they need to be decoded: socket.recv(size).decode('utf-8')
5. Some imports:
try:
import StringIO
except:
import io as StringIO #Python 3.0
try:
from urllib import quote_plus, unquote_plus
except ImportError:
from urllib.parse import quote_plus, unquote_plus #Python 3.0
try:
import __builtin__
except ImportError:
import builtins as __builtin__ #Python 3.0
There are way too many others, so, the approach for getting it right is basically running the 2to3 with that import to see the new version of it and then making it work as it used to.
6. True, False assign: in some scripts, to support older python/jython versions, the following construct was used:
__builtin__.True = 1
__builtin__.False = 0
As True and False are keywords now, this assignment will give a syntax error, so, to keep it working, one must do:
setattr(__builtin__, 'True', 1) -- as this will only be executed if True is not defined, that should be ok.
7. The long representation for values is not accepted anymore, so, 2L would not be accepted in python 3.
The solution for something as long_2 = 2L may be something as:
try:
long
except NameError:
long = int
long_2 = long(2)
Note that if you want to define a number that's already higher than the int limit, that won't actually help you (in my particular case, that was used on some arithmetic, just to make sure that the number would be coerced to a long, so, that solution is ok -- note: if you were already on python 2.5, that would not be needed as the conversion int -> long is already automatic)
8. raw_input is now input and input should be written explicitly as eval(raw_input('enter value'))
So, to keep backwards compatibility, I think the best approach would be keeping on with the raw_input (and writing the "old input" explicitly, while removing the "new input" reference from the builtins)
try:
raw_input
except NameError:
import builtins
original_input = builtins.input
del builtins.input
def raw_input(*args, **kwargs):
return original_input(*args, **kwargs)
builtins.raw_input = raw_input
9. The compiler module is gone. So, to parse something, the solution seems to be using ast.parse and to compile, there's the builtins.compile (NOTE: right now, the 2to3 script doesn't seem to get this correctly)
Subscribe to:
Posts (Atom)