WIT runtime bug

[Boštjan Mejak]

I get a runtime bug if I use wx.lib.mixins.inspection.InspectionMixin in my program. My OS is Windows 7 SP1 (64 bit), my Python version is 3.3.2 (64 bit), Phoenix snapshot build used is win64-py3.3 r74041. The traceback I get after pressing Ctrl+Alt+i is this (oh yes, and I strictly followed Phoenix docs to implement WIT in my program):

Traceback (most recent call last):

  File "C:\Program Files\Python 3.3.2\lib\site-packages\wx\lib\mixins\inspection.py", line 156, in _OnKeyPress

    self.ShowInspectionTool()

  File "C:\Program Files\Python 3.3.2\lib\site-packages\wx\lib\mixins\inspection.py", line 169, in ShowInspectionTool

    InspectionTool().Show(wnd)

  File "C:\Program Files\Python 3.3.2\lib\site-packages\wx\lib\inspection.py", line 103, in Show

    app=self._app)

  File "C:\Program Files\Python 3.3.2\lib\site-packages\wx\lib\inspection.py", line 159, in __init__

    style=wx.NO_BORDER,

  File "C:\Program Files\Python 3.3.2\lib\site-packages\wx\py\crust.py", line 60, in __init__

    rootIsNamespace=rootIsNamespace)

  File "C:\Program Files\Python 3.3.2\lib\site-packages\wx\py\filling.py", line 289, in __init__

    static=static)

  File "C:\Program Files\Python 3.3.2\lib\site-packages\wx\py\filling.py", line 62, in __init__

    self.SetItemHasChildren(self.root, self.objHasChildren(rootObject))

  File "C:\Program Files\Python 3.3.2\lib\site-packages\wx\py\filling.py", line 108, in objHasChildren

    if self.objGetChildren(obj):

  File "C:\Program Files\Python 3.3.2\lib\site-packages\wx\py\filling.py", line 117, in objGetChildren

    if otype is types.DictType \

AttributeError: 'module' object has no attribute 'DictType'

[Boštjan Mejak]

Here's a snippet of the source code used:

import wx

import wx.lib.mixins.inspection as wit

class MyApp(wx.App, wit.InspectionMixin):

    def OnInit(self):

        self.Init()  # Initialize the Widget Inspection Tool (WIT)

        return True

I press Ctrl+Alt+i when my program is running and I get the previously-posted traceback. Anyone knows what seems to be the issue?

[werner]

I don't see this but then I am on:
Py2.7 on Win32 with r73946 Phoenix

According to the "Tags" the WIT is not yet ported to Py3, see if you
find what the issue is and provide a patch to the dev list.

Werner

["Boštjan Mejak"]

To change the line 117 to "if otype is dict:" is not quite correct. Correct is "if isinstance(otype, dict):", because type checking has to be done by using the isinstance() built-in method. ;)

I'll try to come up with a patch. Stay tuned. :)ile "C:\Program Files\Python 3.3.2\lib\site-packages\wx\py\filling.py",

> line 108, in objHasChildren
> if self.objGetChildren(obj):
> File "C:\Program Files\Python 3.3.2\lib\site-packages\wx\py\filling.py",
> line 117, in objGetChildren
> if otype is types.DictType \
> AttributeError: 'module' object has no attribute 'DictType'
>

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Joaquin Abian]

Boštjan,

I was using the faster correction that worked (I think lib2to3 also uses this translation) .

Now I realize it is not the recommended, correct one.
Thanks

Joaquin

[Boštjan Mejak]

Okay, so this is my first attempt to make WIT Python 3 compatible. However, it breaks Python 2 compatibility, but that's something I need to dig into once I get a thumbs up from you guys.

Any comments on my patch are welcome.

[Robin Dunn]

The changes like this one are not correct:

@@ -114,11 +114,11 @@ class FillingTree(wx.TreeCtrl):
"""Return dictionary with attributes or contents of object."""
busy = wx.BusyCursor()
otype = type(obj)
- if otype is types.DictType \
+ if isinstance(otype, dict) \
or str(otype)[17:23] == 'BTrees' and hasattr(obj, 'keys'):
return obj
d = {}
- if otype is types.ListType or otype is types.TupleType:
+ if isinstance(otype, list) or isinstance(otype, tuple):
for n in range(len(obj)):
key = '[' + str(n) + ']'
d[key] = obj[n]


otype is a type object, not something that can be an instance of a
dictionary. You should check isinstance(obj, dict) instead.

On Python 2 compatibility, it only needs to stay compatible with Python
2.7, so feel free to use any compatibility helps or __future__'s that
will help to write code that is compatible with both. See the
http://wiki.wxpython.org/ProjectPhoenix/LibraryMigration page in the
wiki for more info.

--
Robin Dunn
Software Craftsman
http://wxPython.org

[Boštjan Mejak]

So are you saying that in my patch "if otype is types.DictType:" should be "if isinstance(obj, dict):"?

[Boštjan Mejak]

Okay, here's my new patch. Please review and comment. ;)

[Robin Dunn]

Bo�tjan Mejak wrote:
> Okay, here's my new patch. Please review and comment. ;)
>

For changes like this one:

- if otype is types.StringType or otype is types.UnicodeType:
+ if isinstance(obj, str):


You should use the string_types value in wx.lib.six in order maintain
compatibility with both Python 2.7 and Python 3.

from wx.lib import six
...

if isinstance(obj, six.string_types):
...


Please review that module to learn about more ways to make it easier to
maintain compatibility with both Pythons.

[Boštjan Mejak]

New patch. Again, please review and comment. ;)

[Robin Dunn]

Bo�tjan Mejak wrote:
> New patch. Again, please review and comment. ;)
>

In this change:

- if otype is types.StringType or otype is types.UnicodeType:

+ if isinstance(obj, six.string_types) or isinstance(obj,
six.text_type):

I think checking just isinstance(obj, six.string_types) is sufficient.

Also, the "Tags: py3-port" at the top should be in a comment. Did you
not try running it before making the patch?

[Boštjan Mejak]

Fixed my patch according to your suggestions.

I have a question about line 145

keys.sort(lambda x, y: cmp(str(x).lower(), str(y).lower()))

which uses the cmp() function which is gone in Python 3.

How should I deal with it?

On Mon, May 27, 2013 at 10:12 PM, Robin Dunn <ro...@alldunn.com> wrote:

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.

[Joaquin Abian]

maybe:

keys.sort(key=lambda x: str(x).lower())

J

To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-user...@googlegroups.com.

[Joaquin Abian]

maybe:

keys.sort(key=lambda x: str(x).lower())

but this is not compatible with pythont 2.

In porting to python 3 Regebro recommends to use a helper function:

def cmp(a, b):
    return (a > b) - (a < b)

J

On Monday, May 27, 2013 10:33:25 PM UTC+2, Boštjan Mejak wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-user...@googlegroups.com.

[Vlastimil Brom]

> On Monday, May 27, 2013 10:33:25 PM UTC+2, Boštjan Mejak wrote:
>>
>> Fixed my patch according to your suggestions.
>>
>> I have a question about line 145
>> keys.sort(lambda x, y: cmp(str(x).lower(), str(y).lower()))
>> which uses the cmp() function which is gone in Python 3.
>>
>> How should I deal with it?
>>
>>
>> On Mon, May 27, 2013 at 10:12 PM, Robin Dunn <ro...@alldunn.com> wrote:
>>>
>>> Boštjan Mejak wrote:
>>>>
>>>> New patch. Again, please review and comment. ;)
>>>>
>>>
>>> In this change:
>>>
>>> - if otype is types.StringType or otype is types.UnicodeType:
>>> + if isinstance(obj, six.string_types) or isinstance(obj, six.text_type):
>>>
>>> I think checking just isinstance(obj, six.string_types) is sufficient.
>>>
>>> Also, the "Tags: py3-port" at the top should be in a comment. Did you not try running it before making the patch?
>>>
>>>
>>> --
>>> Robin Dunn
>>> Software Craftsman
>>> http://wxPython.org
>>>
>>> --

> --

2013/5/27 Joaquin Abian <gatoy...@gmail.com>

>
> maybe:
> keys.sort(key=lambda x: str(x).lower())
> but this is not compatible with pythont 2.
> In porting to python 3 Regebro recommends to use a helper function:
> def cmp(a, b):
> return (a > b) - (a < b)
>
> J

Hi,
I don't know the context of the relevant source code, but the "key"
argument for sorting functions is perfectly valid in py 2.7;
cf.:

Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit
(Intel)] on win32
...
>>> keys = ["a","D","A","b"]
>>> keys.sort(); keys
['A', 'D', 'a', 'b']
>>> keys.sort(key=lambda x: x.lower()); keys
['A', 'a', 'b', 'D']
>>>

if the str(...) call is needed, probably an appropriate alias from the
"six" module could be used (probably six.text_type).

hth,
vbr

[Boštjan Mejak]

I fixed my patch. Thanks, Joaquin and Robin, for your wonderful suggestions. I also polished the patch a little bit, i.e. removed some imports that are not used in the code and some str() calls were fixed to six.string_types()... Anyway, if you see some other porting issue, let me know. ;)

[Joaquin Abian]

Thanks Boštjan,

- I think you can replace:

if isinstance(obj, list) or isinstance(obj, tuple):

with

if isinstance(obj, (list, tuple)):

looks nicer to me :-)

J

["Boštjan Mejak"]

Ah, yes, it does look nicer. I'll fix that.

And now for something completely different... Why does this module include a __revision__ tag? The convention is to have a __version__ tag.

The __revision__ line goes like this:
__revision__ = "$Revision$"[14:-2]
and I don't understand the reason for having the slice notation. Anyone care to explain?

[Boštjan Mejak]

The __revision__ line is actually

__revision__ = "$Revision$"[11:-2]

so 11 instead of 14, but you get the idea.

Anyway, made a new patch. I wanted to remove the slice notation [11:-2] in the __revision__ line but I wasn't sure if it's okay. Please explain why is it that it needs to be hardcoded.

[Robin Dunn]

Back in the old days when CVS was the commonly used revision control
system it was common to put some keywords like $Id$ or $Revision$ (or
some others) in the source file. When the file was checked out from
revision control CVS would substitute those keywords with text
specifying the actual revision number, or commit date, or whatever for
that file. It was a convenient way to know exactly which revision of
the file you are looking at, especially since CVS tracked separate
version numbers for every file. Subversion has a mode where it will
also substitute text for those CVS keywords, but it is turned off by
default.

It doesn't hurt anything to keep them in the source file, so I haven't
worried about going through and removing them everywhere.

["Boštjan Mejak"]

Is the slice notation [11:-2] needed at all?

[Robin Dunn]

Bo�tjan Mejak wrote:
> Is the slice notation [11:-2] needed at all?
>

That will slice out just the revision number from the substituted value,
so __revision__ would be just the number without a label in front of it.

[Boštjan Mejak]

I see. But I, myself, kind of dislike hardcoded things. And the revision numbering scheme may change in the future, so it would be nice if "$Revision$" would output just the number. Or is that VCS-dependant?

On Wed, May 29, 2013 at 6:45 PM, Robin Dunn <ro...@alldunn.com> wrote:

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.

[Boštjan Mejak]

*CVS-dependant

[Tim Roberts]

Boštjan Mejak wrote:
> I see. But I, myself, kind of dislike hardcoded things. And the
> revision numbering scheme may change in the future, so it would be
> nice if "$Revision$" would output just the number. Or is that
> VCS-dependant?

Exactly. That's the point. The $Revision$ string is expanded by the
source control system. The [11:-2] thing is specifically for CVS.

--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[Boštjan Mejak]

Robin, is my patch ready for being commited to the trunk?

[Robin Dunn]

Bo�tjan Mejak wrote:
> Robin, is my patch ready for being commited to the trunk?

I've committed it locally, it will be pushed up to SVN later.

Next time please test your changes with both Py3 and Py2.7. If you had
done that this time then you would have realized that six.string_types()
is not what should be used as a replacement for str(). Instead,
six.text_type() should be used for that and six.string_types should be
used with isinstance.

[Boštjan Mejak]

I'll keep that in mind. Thanks for sharing that. Anyway, I hope my patch helps you in some way. If there are any other modules that need porting to Python 3 and be Python 2.x-compatible, list them here and I'll see what I can do.

On Fri, May 31, 2013 at 6:26 PM, Robin Dunn <ro...@alldunn.com> wrote:

[Boštjan Mejak]

I tested the Phoenix snapshot build r74085 on Windows 7 x64 for Python 3.3 after my patch from this thread was commited. There's a SyntaxError now if you run a program that has the InspectionMixin mixed with App. I fixed my snapshot build to the state that the Widget Inspection Tool is perfectly working now and I am posting a patch for the source code that I grabbed from GitHub. I had to fix filling.py and also a little fix needed to be made in inspection.py.

Please review and commit. ;)

[Karsten Hilbert]

On Sun, Jun 02, 2013 at 08:38:33AM -0700, Boštjan Mejak wrote:

> I tested the Phoenix snapshot build r74085 on Windows 7 x64 for Python 3.3

> I had to fix filling.py and also a little fix needed to be
> made in inspection.py.

How did the tests with 2.x turn out ?

Karsten
--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

["Boštjan Mejak"]

Testing just now on Python 2.7 was a success as well.

[Robin Dunn]

Boštjan Mejak wrote:
> I'll keep that in mind. Thanks for sharing that. Anyway, I hope my patch
> helps you in some way. If there are any other modules that need porting
> to Python 3 and be Python 2.x-compatible, list them here and I'll see
> what I can do.

All of them that do not have a "py3-port" tag.

[Robin Dunn]

Thanks.

[Boštjan Mejak]

Was my patch inspection_and_filling.patch commited locally only? 'Cause I don't see my changes in the source.

[werner]

Hi,

On 04/06/2013 15:28, Bo�tjan Mejak wrote:
> Was my patch inspection_and_filling.patch commited locally only?
> 'Cause I don't see my changes in the source.

You can see what is committed here:
https://github.com/RobinD42/Phoenix/commits/master

or in the SVN repo.

Depending on Robin's work load, his testing on different platforms and
different ..... it can take some time.

Werner

[Boštjan Mejak]

It's interesting that my newest patch was not yet commited.

[Boštjan Mejak]

Gotta link to the SVN repo?

[werner]

On 04/06/2013 18:04, Bo�tjan Mejak wrote:
> It's interesting that my newest patch was not yet commited.

Robin commits to his work and does whatever he does and at some point he
commits to the public repo.

What is your problem with that?

Anyhow you have your patch applied to your code and can work with it,
others who absolutely have to have it can apply it to their code and
work with it.

Werner

P.S.
The SVN repo is the one where all the wxWidget code is in which you can
find on the wxPython home page somewhere.

[Robin Dunn]

Bo�tjan Mejak wrote:
> Was my patch inspection_and_filling.patch commited locally only? 'Cause
> I don't see my changes in the source.

Sorry. I had it ready to go but forgot to merge that branch before
pushing to the subversion repository. It's there now.

[Boštjan Mejak]

Yup, there it is. ;)  Thanks, Robin. If I stumble upon any other bug, I'll fix the source and give you the patch via this mailing list.

[Boštjan Mejak]

The patch fixes the boolean evaluation order in filling.py.

[Boštjan Mejak]

Robin, we have one more boolean evaluation order bug in filling.py that I fix in my patch. Please review and commit as soon as you can. Thanks.

[Robin Dunn]

Bo�tjan Mejak wrote:
> Robin, we have one more boolean evaluation order bug in filling.py that
> I fix in my patch. Please review and commit as soon as you can. Thanks.

Thanks again.