Hello:
When will wxpython be updated for the upcoming 2.6 and 3.0 versions of python?
Bob
Hello:
When will wxpython be updated for the upcoming 2.6 and 3.0 versions of python?
Bob
Hello:
When will wxpython be updated for the upcoming 2.6 and 3.0 versions of python? Thank you for your time.
Bob
Bob,
Hello:
When will wxpython be updated for the upcoming 2.6 and 3.0 versions of python?
Bob
I don't think Robin has VS2008. As I understand it, VC2008 is required for compiling wx against the 2.6 and 3.0 series of Python. I'm pretty sure Robin would take donations though.
Mike
Mike Driscoll wrote:
Bob,
Hello:
When will wxpython be updated for the upcoming 2.6 and 3.0 versions of python?
Bob
I don't think Robin has VS2008.
I do have it now.
I've made some test builds with 2.6, although not on Windows yet. On Mac and Linux it works perfectly so I'm not too worried about it. I expect that the next wxPython release after the 2.6 release will include a 2.6 build.
Python 3.0 on the other hand will likely take tons of work to be able to port to it, and I haven't even started looking at it yet. There are big differences in the Python C API, and from what I understand it may not really stabilize until the 3.1 release. So all I can say now is that although a 3.x port won't happen right away, I expect that it will happen eventually.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin Dunn <robin <at> alldunn.com> writes:
Mike Driscoll wrote:
> Bob,
>
>> Hello:
>>
>> When will wxpython be updated for the upcoming 2.6 and 3.0 versions of
>> python?
>>
>> Bob
>>
>>
>
> I don't think Robin has VS2008.I do have it now.
I've made some test builds with 2.6, although not on Windows yet. On
Mac and Linux it works perfectly so I'm not too worried about it. I
expect that the next wxPython release after the 2.6 release will include
a 2.6 build.Python 3.0 on the other hand will likely take tons of work to be able to
port to it, and I haven't even started looking at it yet. There are
big differences in the Python C API, and from what I understand it may
not really stabilize until the 3.1 release. So all I can say now is
that although a 3.x port won't happen right away, I expect that it will
happen eventually.
Hi,
The next wxWidgets releases will see the merging of the ansi and unicode build.
From what I understood, it is not really the unicode build we know, but a
platform friendly unicode build (utf-16 on Windows, utf-8 on *x).
On the other side, Python 3.x is arriving. I have already toyed a lot with it
and I find it very pleasant. A lots of small annoying details have been improved.
From what I read on miscellaneous fora, it seems the adoption with take "some
time". I'm not so sure about this. In my mind, the fundamental change in Python
3.0, is the use of unicode for the type <str>. This change may not have a big
impact for professionnals or some Python gurus, but it is certainly a plus for
newbies, hobbyists or just Python users, eg. scientists considering Python just
as a nice tool. (The chars coding, encoding and decoding stuff is a nightmare
for a lot of users).
Taking these points in consideration, having some kind of synchronization
wxPython 2.9/3.0 - Python 3.0 as soon as possible can be a big plus, even
if Python 3.0 is not "so mature."
I'm myself interested in porting some old applications, modules from Py2.3, 2.4,
2.5 directly to Py3.0, skipping the 2.6 version. I have learnt tkinter!
I have no cristal ball and the days have only 24 hours.
Jean-Michel Fauth, Switzerland
Jean-Michel Fauth wrote:
Robin Dunn <robin <at> alldunn.com> writes:
The next wxWidgets releases will see the merging of the ansi and unicode build.
From what I understood, it is not really the unicode build we know, but a
platform friendly unicode build (utf-16 on Windows, utf-8 on *x).
Sort of. The wxString class has been modified such that the internal storage of the string data can be in either format, but what format is actually used is hidden from the API perspective. In either case the programmer still deals with wxStrings in an abstract Unicode oriented manner. The internal format used is based on what the native UI APIs are expecting, in order to eliminate most of the conversions to/from what the APIs use. The wxPython wrappers still need to go through a conversion step for converting to/from Python Unicode objects.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!