Pydev & Python 3.0

One thing that should be added in the next release is support for Python 3.0 (aka Python 3k)

So, to cover that, I've started at the most basic part: being able to configure an interpreter with Python 3.0. And you guessed it: print does not work anymore, so, when I started checking how can support be added for Python 3.0 while still retaining compatibility with other versions (as most existent python library probably will have to do), something weird struck me: print is now something banned in the python world...

Not only won't I be able to use the print statement (because it's not available on Python 3.0), but I also won't be able to use the print function (because it's not available in older versions of Python), so, when considering the 2to3 tool, actually, what should be available is a 2toAny, where print is removed altogether in what's probably going to be the actual standard for python: instead of print 'x', the thing to have backward compatibility is writing: sys.stdout.write('x\n') -- which I think is really something sad -- probably a step backwards for python, where printing something used to be sane... unlike java things such as System.out.println()... But now not only it's very similar -- it also gets worse: you have to add the new line yourself.

So, in the 2toAny, what should be done is transforming print varA into sys.stdout.write('%s\n' % (varA,)) and print >> log, varA into log.write('%s\n', (varA,))-- much more pythonic right?!?

Well, aside from that, I wanted to say that besides that particular change, most other things seem to be consistent in taking the language forward... but that one seems just gratuitous breakage of most python code existent (it's not like print is used seldonly in the python world or anyone did actually dislike it).

I'm sorry about the tone of this post, but I must say I'm a bit disapointed with that particular change in Python at this stage... Am I missing something here? Is there another way to really have actual compatibility? -- Maybe defining my own print_ function and using it everywhere? Why did Python "fix" something that not only worked, but that everyone was happy about? (or wasn't?)

How about a python 2toAny tool, does someone know if such a thing exists? It's probably much more important than a 2to3 (as almost all libraries will need to keep supporting old versions and probably only few projects will actually migrate to 3.0 -- at least initially and until the libraries they use are able to support it).

Pydev 1.3.23 and 1.3.24

Yes, that's right, 2 new releases were done.

Basically, 1.3.24 fixes a major bug in Pydev, related to the debugger (it was halting on some cases and Jython was not working because a dependency on itertools was added).

I think that the major highlight in 1.3.23 is the possibility to debug multiple processes at the same time in the remote debugger (yes, it only supported one at a time), so, if you're spawning multiple processes, that should help a bit :)

Another fix was an incompatibility with the update manager of Eclipse 3.4... It should be backward compatible, but apparently, because the Pydev update site contained some really old versions, after installing Pydev, no other plugins could be installed! -- something related to getting the dependencies wrong in the new Eclipse update manager.

Aside from that, this release had lots of minor bugs fixed, so, upgrading is highly recommended!

Pydev Subversion @ Aptana

I think it's already widely publicized that Pydev is now a part of Aptana, and the last release is starting to mark that integration: the source is now available at the subversion hosted by Aptana.

The basic info to get it is:

• repo: https://source.aptana.com/pydev_repo/
• user: anonymous
• password: aptana

There are detailed instruction on how to get/build it at: http://pydev.sourceforge.net/developers.html

Enjoy!

Pydev 1.3.22

This Pydev release was focused mostly on bug-fixes, with many minor things being done. It fixed that nasty bug related to handling __all__ incorrectly together with a bunch of others.

I think that the only feature added that's worth mentioning is a mode where you can have Pydev analyze only your current editor (this enables builds to happen faster, as less work is needed when building the project, so, it can increase your performance a bit at the cost of having the markers added only to open editors). To activate it, go to window > preferences > Pydev > Builders and check 'Only analyze open editors'.

Note that doing so will not remove existing markers, and will be available for new analysis (the markers may be removed by right-clicking a folder and choosing "Pydev > Remove error markers"). Also, this feature is still in beta, so, please report any bugs found when using it.

Pydev 1.3.19

I guess 1.3.19 is already old news by now, but I decided to comment a bit on it, especially on a new support direction that'll start to be adopted in the Pydev development (and I'm still unsure how well that'll work):

Pydev will now try to support Eclipse 3.2, 3.3 and 3.4 (all with the same binaries) -- actually, there are still some known bugs on Eclipse 3.4, but those should be solved for the next release.

Now, while trying to support all those versions with the same binary release, there are some hacks that don't really seem right for me (but I couldn't see another way out for it):

1. Catching Exceptions such as ClassNotFoundException / LinkageError and related and falling back to another version (usually deprecated) of some API

2. When adapting to some interface, instead of having adapter == IElementContentProvider.class, do things as if(adapter.toString().endsWith("org.eclipse.debug.internal.ui.viewers.model.provisional.IElementContentProvider"))
-- because that class still does not exist on a previous version.

3. Using reflection (yes, in languages as Python this would be the default, but Java's not really made for this)

BTW: This wouldn't be possible without using Mercurial locally -- right now I have 4 workspaces, all synched through mercurial -- one for each version of Eclipse and one that's the link to the outside world -- and each of those has some changes to make it compile in that version -- yes, the final code runs in all versions, but it'll only actually compile in 3.3 for now -- the others have classes not defined (which are those cases with ClassNotFoundException), so, the code must be tested later on those versions with the final release.