wxPython for 3.1 ??

I was considering downloading wxPython but the download page says it's
only available for phyton 2.4, 2.5 and 2.6.

Is the version designed for 2.6 compatible with 3.1 ??

And if not, is there a version for 3.1 ??

Has anyone here used AccessGrid with python 3.1 ??

Juliette Salexa wrote:

I was considering downloading wxPython but the download page says it's
only available for phyton 2.4, 2.5 and 2.6.

Is the version designed for 2.6 compatible with 3.1 ??

And if not, is there a version for 3.1 ??

Has anyone here used AccessGrid with python 3.1 ??

>

Nope, wxPython (as well as many, many other Python packages) aren't
ready for version 3. In fact the official python site recommends to use
2.6 over 3.1 due to this

I was considering downloading wxPython but the download page says it’s

only available for phyton 2.4, 2.5 and 2.6.

Is the version designed for 2.6 compatible with 3.1 ??

No. Almost none of the third-party libraries designed for 2.6 and earlier is compatible with 3.x, as far as I can tell, and this will continue to be the case for some time. For the group I work with, I doubt we will have migrated to 3.x within five years. I suspect the 2.x line will continue to be maintained more or less indefinitely because of the massive amount of work involved in fixing everything that 3.x breaks. (This varies from package to package - wxPython may not have as many problems as some software.)

And if not, is there a version for 3.1 ??

No.

This question gets asked every few weeks, and I honestly don’t understand the need to use the absolute latest version of Python, given how incompatible it is with the vast majority of existing Python code. As far as I can tell, it is not terribly difficult to write code that will run on both 2.6 and 3.x, as long as you know what to avoid. Has anyone on this list actually used Python 3.0 and can comment on whether I’m missing out on some amazing new feature? (Obsoleting the “print” statement is not a feature.)

···

On Wed, Jul 15, 2009 at 10:30 AM, Juliette Salexa juliette.physicist@gmail.com wrote:

Hi Nathaniel,

2009/7/15 Nathaniel Echols:

And if not, is there a version for 3.1 ??

No.
<rant>This question gets asked every few weeks, and I honestly don't understand the need to use the absolute latest version of Python, given how incompatible it is with the vast majority of existing Python code. As far as I can tell, it
is not terribly difficult to write code that will run on both 2.6 and 3.x,
as long as you know what to avoid. Has anyone on this list actually used
Python 3.0 and can comment on whether I'm missing out on some amazing new
feature? (Obsoleting the "print" statement is not a feature.)</rant>

<rant-2>
I can feel your pain. Until Python 2.5, I was upgrading my Python
version to the bleeding edge every time a new release came out. Now I
have stopped at 2.5.4. I can't mention a single possible improvement
in Python 3 wrt 2.5/2.6, not to mention any *smashing* new feature.

If the intention of breaking backward compatibility was already there,
I would have expected some bold move, some revolutionary change... to
mention a few:

1) Remove the GIL;
2) Remove the GIL;
3) Remove the GIL (and don't say it's not possible, look at
IronPython. What's missing is the will, not the possible
implementation);
4) Don't make "print" a function.

It is most unfortunate that in order to port medium to big-size 3rd
party libraries the developers need to sweat their a$$ off with so
little to gain (if not to lose) with Python 3.

</rant-2>

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

···

On Wed, Jul 15, 2009 at 10:30 AM, Juliette Salexa > <juliette.physicist@gmail.com> wrote:

Other ideas that have come up in discussions with coworkers:

  1. Re-write the interpreter in C++ and simplify writing extension modules.

  2. Get rid of ‘self’.

I wouldn’t have any major objections to the features of Python 3 if I was starting from scratch, and there are actually a few changes I agree with (true division of integers is my favorite). I just resent the imposition on everyone who has adopted Python and built up a large code base, especially since the motives seem so. . . petty.

···

On Wed, Jul 15, 2009 at 2:48 PM, Andrea Gavana andrea.gavana@gmail.com wrote:

If the intention of breaking backward compatibility was already there,

I would have expected some bold move, some revolutionary change… to

mention a few:

  1. Remove the GIL;

  2. Remove the GIL;

  3. Remove the GIL (and don’t say it’s not possible, look at

IronPython. What’s missing is the will, not the possible

implementation);

  1. Don’t make “print” a function.

Andrea Gavana escribió:

<rant-2>

[...]

If the intention of breaking backward compatibility was already there,
I would have expected some bold move, some revolutionary change... to
mention a few:

1) Remove the GIL;
2) Remove the GIL;
3) Remove the GIL (and don't say it's not possible, look at
IronPython. What's missing is the will, not the possible
implementation);
4) Don't make "print" a function.

It is most unfortunate that in order to port medium to big-size 3rd
party libraries the developers need to sweat their a$$ off with so
little to gain (if not to lose) with Python 3.

</rant-2>

Andrea.

At some point agree with you, Andrea, but wait, take a look at this project:

http://code.google.com/p/unladen-swallow/

I hope this branch gets those changes in CPython-trunk. :slight_smile:

Regards

···

--
Marcelo F. Fernández
Buenos Aires, Argentina
Licenciado en Sistemas de Información - CCNA

E-Mail: marcelo.fidel.fernandez@gmail.com
Jabber ID: fernandezm22@jabber.org
Public Key ID: 5C990A6C 111C3661
Blog: http://blog.marcelofernandez.info