Phoenix issues - reporting them here or on dev

Werner1 · March 6, 2013, 8:22am

Hi,

Mears question and the encouraging answers made me give it a go.

It was easy to get it going.

- downloaded the appropriate tar.gz
- created folder "site-packages\wx-2.9.6-msw-phoenix" - named it 2.9.6 so that wxversion.select could easily switch between classic and phoenix
- copied the "wx" folder from the tar.gz into the above

Then I just use this to switch from 2.9.5 classic to phoenix:

import sys

if not hasattr(sys, "frozen"):
     import wxversion
     #wxversion.select("2.9.6-msw-phoenix")
     wxversion.select("2.9.5")

Now to my question where do we report issues? Here or on dev?

Starting my tests I run into the following error on Phoenix which I don't get on Classic:

TypeError: keyword arguments are not supported
File "h:\devProjectsT\aaTests\aaMisc\aaAndrea\infobardialogtest.py", line 76, in <module>
c = TestInfoBar(None)
File "h:\devProjectsT\aaTests\aaMisc\aaAndrea\infobardialogtest.py", line 26, in __init__
super(TestInfoBar, self).__init__(**kwds)

with this code:

class TestInfoBar(wx.EvtHandler):
def __init__(self, parent, **kwds):
....
super(TestInfoBar, self).__init__(**kwds)

It is easy to fix, but wonder if it is expected?

Werner

Vlastimil_Brom · March 6, 2013, 3:58pm

Hi,

Mears question and the encouraging answers made me give it a go.

It was easy to get it going.

- downloaded the appropriate tar.gz
- created folder "site-packages\wx-2.9.6-msw-phoenix" - named it 2.9.6 so
that wxversion.select could easily switch between classic and phoenix
- copied the "wx" folder from the tar.gz into the above

...

It is easy to fix, but wonder if it is expected?

Werner

Hi,
seeing this topic and some others regarding Phoenix, I'd like to ask,
what the appropriate process of handling phoenix bugs should look
like.
In my case, there are rather random findings, as I am occasionally
trying to port some of my scripts to python 3(.3), which involves
experiments with the phoenix snapshot builds.

Lately, I noticed an obvious, easily fixable incompatibility with
python 3 in ListCtrl (unicode instead of the str builtin)

--- C:\Python33\Lib\site-packages\wx\core.py

+++ C:\Python33\Lib\site-packages\wx\core.py - UPDATED

@@ -2383 +2383 @@

- self.InsertItem(pos, unicode(entry[0]))
+ self.InsertItem(pos, str(entry[0]))
@@ -2385 +2385 @@

- self.SetItem(pos, i, unicode(entry[i]))
+ self.SetItem(pos, i, str(entry[i]))

The above fixes this problem apparently, but as this is a generated
file, the change should be made somewhere else, which is probably
beyond my skills, competence...

Should these findings be reported to the wx tracker
like I did in this case:
http://trac.wxwidgets.org/ticket/15088
or is there some other workflow preferred?

Is there some documentation available on which parts of the
wxPython-phoenix build are considered ready for testing and using (and
for which it makes sense to report bugs), or can it be inferred in
some way? Or are only the ported files included in the snapshot and
the others are currently missing?
(I noticed e.g. PyShell & co, which are likely not ported to python 3 yet)

regards,
vbr

···

2013/3/6 Werner <werner.bruhin@sfr.fr>:

Robin · March 7, 2013, 3:59am

Werner wrote:

Hi,

Mears question and the encouraging answers made me give it a go.

It was easy to get it going.

- downloaded the appropriate tar.gz
- created folder "site-packages\wx-2.9.6-msw-phoenix" - named it 2.9.6
so that wxversion.select could easily switch between classic and phoenix
- copied the "wx" folder from the tar.gz into the above

Then I just use this to switch from 2.9.5 classic to phoenix:

import sys

if not hasattr(sys, "frozen"):
import wxversion
#wxversion.select("2.9.6-msw-phoenix")
wxversion.select("2.9.5")

Now to my question where do we report issues? Here or on dev?

Here is okay, but on wxPython-dev is better. At least until there are more people using it than "early adopters."

Starting my tests I run into the following error on Phoenix which I
don't get on Classic:

TypeError: keyword arguments are not supported
File "h:\devProjectsT\aaTests\aaMisc\aaAndrea\infobardialogtest.py",
line 76, in <module>
c = TestInfoBar(None)
File "h:\devProjectsT\aaTests\aaMisc\aaAndrea\infobardialogtest.py",
line 26, in __init__
super(TestInfoBar, self).__init__(**kwds)

with this code:

class TestInfoBar(wx.EvtHandler):
def __init__(self, parent, **kwds):
....
super(TestInfoBar, self).__init__(**kwds)

It is easy to fix, but wonder if it is expected?

No it is not expected. Keyword args really should be okay there, perhaps some other tweaking going on for that class is having a side-effect that it shouldn't be having. I'll check in to it.

···

--
Robin Dunn
Software Craftsman

Robin · March 7, 2013, 4:01am

Vlastimil Brom wrote:

Hi,
seeing this topic and some others regarding Phoenix, I'd like to ask,
what the appropriate process of handling phoenix bugs should look
like.

There is a Phoenix component at trac.wxwidgets.org that can be assigned to tickets. I'm a little behind on my wx mail lists though so following up with a mail to wxPython-dev after making a ticket would be a good idea.

In my case, there are rather random findings, as I am occasionally
trying to port some of my scripts to python 3(.3), which involves
experiments with the phoenix snapshot builds.

Lately, I noticed an obvious, easily fixable incompatibility with
python 3 in ListCtrl (unicode instead of the str builtin)

--- C:\Python33\Lib\site-packages\wx\core.py

+++ C:\Python33\Lib\site-packages\wx\core.py - UPDATED

@@ -2383 +2383 @@

- self.InsertItem(pos, unicode(entry[0]))
+ self.InsertItem(pos, str(entry[0]))
@@ -2385 +2385 @@

- self.SetItem(pos, i, unicode(entry[i]))
+ self.SetItem(pos, i, str(entry[i]))

The above fixes this problem apparently,

Almost. It still has to work in 2.7 where unicode() is different than str(). I've fixed it by using wx.lib.six.text_type instead.

but as this is a generated
file,the change should be made somewhere else,

Yep, it's in Phoenix/etg/listctrl.py

which is probably
beyond my skills, competence...

It should take just a basic understanding of the Phoenix process to see what is going on. In this case the Append method is a pure python function that is grafted on to the ListCtrl class, so the whole function body is there in the etg file:

     c.addPyMethod('Append', '(self, entry)',
         doc='''\
         Append an item to the list control. The `entry` parameter should be a
         sequence with an item for each column''',
         body="""\
         if len(entry):
             from wx.lib.six import text_type
             pos = self.GetItemCount()
             self.InsertItem(pos, text_type(entry[0]))
             for i in range(1, len(entry)):
                 self.SetItem(pos, i, text_type(entry[i]))
             return pos
         """)

Should these findings be reported to the wx tracker
like I did in this case:
wxTrac has been migrated to GitHub Issues - wxWidgets
or is there some other workflow preferred?

That is fine, but like I mentioned a followup message to wxPython-dev would be good so I know that it is there. Discussions that are perhaps not ready for a patch or bug report should happen on wxPython-dev also.

Is there some documentation available on which parts of the
wxPython-phoenix build are considered ready for testing and using (and
for which it makes sense to report bugs), or can it be inferred in
some way? Or are only the ported files included in the snapshot and
the others are currently missing?
(I noticed e.g. PyShell& co, which are likely not ported to python 3 yet)

If something is coming from an extension module then if it's there then you can assume (98%) that it's ready for use. For Python modules in the wx.lib or wx.py packages we have a simple system to mark which ones have received attention and how far along they are. The files will just have some tags added to the header to indicate what stage they are in. See ProjectPhoenix/LibraryMigration - wxPyWiki. Anybody who would like to help out with migrating the library or wx.py packages is very welcome.

···

--
Robin Dunn
Software Craftsman

Werner1 · March 16, 2013, 10:07am

Hi Robin,

...

Starting my tests I run into the following error on Phoenix which I

don't get on Classic:

TypeError: keyword arguments are not supported
File "h:\devProjectsT\aaTests\aaMisc\aaAndrea\infobardialogtest.py",
line 76, in <module>
c = TestInfoBar(None)
File "h:\devProjectsT\aaTests\aaMisc\aaAndrea\infobardialogtest.py",
line 26, in __init__
super(TestInfoBar, self).__init__(**kwds)

with this code:

class TestInfoBar(wx.EvtHandler):
def __init__(self, parent, **kwds):
....
super(TestInfoBar, self).__init__(**kwds)

It is easy to fix, but wonder if it is expected?

No it is not expected. Keyword args really should be okay there, perhaps some other tweaking going on for that class is having a side-effect that it shouldn't be having. I'll check in to it.

I still see this in 73664 - just a friendly check in case it fell into the bin:-) .

Werner

···

On 07/03/2013 04:59, Robin Dunn wrote:

Robin · March 19, 2013, 12:59am

Werner wrote:

Hi Robin,

...

Starting my tests I run into the following error on Phoenix which I

don't get on Classic:

TypeError: keyword arguments are not supported
File "h:\devProjectsT\aaTests\aaMisc\aaAndrea\infobardialogtest.py",
line 76, in <module>
c = TestInfoBar(None)
File "h:\devProjectsT\aaTests\aaMisc\aaAndrea\infobardialogtest.py",
line 26, in __init__
super(TestInfoBar, self).__init__(**kwds)

with this code:

class TestInfoBar(wx.EvtHandler):
def __init__(self, parent, **kwds):
....
super(TestInfoBar, self).__init__(**kwds)

It is easy to fix, but wonder if it is expected?

No it is not expected. Keyword args really should be okay there,
perhaps some other tweaking going on for that class is having a
side-effect that it shouldn't be having. I'll check in to it.

I still see this in 73664 - just a friendly check in case it fell into
the bin:-) .

Ok, I understand better what is going on here now. Since the wrapped function does not have any args, then NULL is being passed to the args parser for the list of arg names. (Because there aren't any.) Apparently the kwds dictionary is still passed to the args parser even though it is empty, and so the error message is triggered because it is not expecting anything.

In the right light I think this could be considered a bug, so I'll pass it on to Phil and see what he says. In the meantime you will need to remove the **kwds in the call to the super's __init__, and make similar changes when a wrapped function has no args expected.

···

On 07/03/2013 04:59, Robin Dunn wrote:

--
Robin Dunn
Software Craftsman