Comments on the new Bind() method

Hi,

Allow me to add some comments from an end user perspective.

From the migration guide - binding events:

All of the EVT_* functions are now instances of the wx.PyEventBinder
class. They have a __call__ method so they can still be used as
functions like before, but making them instances adds some
flexibility.
wx.EvtHandler (the base class for wx.Window) now has a Bind method
that ...

Fact: there is a new and clever way to bind events to an object.

From the migration guide - wx namespace:

You shouldn't need to migrate all your modules over to use the new
package and names right away as there are modules in place that try to
provide as much backwards compatibility of the names as possible. If
you rewrote the above sample using "from wxPython.wx import *", the
old wxNames, and the old style of event binding it will still work
just fine.

Fact: the old style event binding will still work

I really wonder if this is a good idea to keep this backward compatibility.
You know what will happen, some users will keep the old style and
other users will enjoy to use the new form The result is just two
programming styles for the same job. This will only introduce
confusion for new users. Experienced users, who want to exchange
code, will suffer from this too. User A, a new-style programmer, get
code from user B, an old-style programmer. What will the user A do?
i) he/she can keep the code from B and he/she has now a mixture of old and
new styles, what is in my mind not very elegant.
ii) he/she rewrites the code from B and introduced the new style.
iii) he/she rewrites the code from B and reintroduced the old style
(worst case).

Keeping backward compatibility may be nice, but it also has its drawback.
wxPy 2.5 is so new, I wonder if it not better to clean up the situation
even if it breaks compatibility. In that case, forcing the use of the Bind
method.

Beside this Python 2.3 has already introduced enough backward
incompatibilites (deprecation warnings), that a forced change in 2.5
is not so dramatic.

As an example, I can take the small application from the migration
guide and write it in three variants, all doing the same job.

···

----
Variant A (from migration guide)

import wx
class MyFrame(wx.Frame):
    def __init__(self, parent, title):
        wx.Frame.__init__(self, parent, -1, title)
        p = wx.Panel(self, -1)
        b = wx.Button(p, -1, "Do It", (10,10))
        b.Bind(wx.EVT_BUTTON) , self.JustDoIt)
    def JustDoIt(self, evt):
        print "It's done!"

app = wx.PySimpleApp()
f = MyFrame(None, "What's up?")
f.Show()
app.MainLoop()

----
Variant B

class MyFrame(wx.Frame):
    def __init__(self, parent, title):
        wx.Frame.__init__(self, parent, -1, title)
        p = wx.Panel(self, -1)
        b = wx.Button(p, 1001, "Do It", (10,10)) *****
        w.EVT_BUTTON(self, 1001, self.JustDoIt) *****
    def JustDoIt(self, evt):
        print "It's done!"

----
Variant C

class MyFrame(wx.Frame):
    def __init__(self, parent, title):
        wx.Frame.__init__(self, parent, -1, title)
        p = wx.Panel(self, -1)
        b = wx.Button(p, -1, "Do It", (10,10)) ******
        b.Bind(wx.EVT_BUTTON) , self.JustDoIt) ******
    self.JustDoIt(self, evt):
        print "It's done!"

If I understand correcty, a clean (==pure wxPy 2.5.xxxx) code uses only
the wx directory. The wxPython dir can be removed.

Last minute remark. I do not know if somebody has tried py2exe. I have.
Seems to work fine.

Jean-Michel Fauth, Switzerland

<<snip>>

I really wonder if this is a good idea to keep this backward compatibility.
You know what will happen, some users will keep the old style and
other users will enjoy to use the new form The result is just two
programming styles for the same job. This will only introduce
confusion for new users. Experienced users, who want to exchange
code, will suffer from this too. User A, a new-style programmer, get
code from user B, an old-style programmer. What will the user A do?
i) he/she can keep the code from B and he/she has now a mixture of old and
new styles, what is in my mind not very elegant.
ii) he/she rewrites the code from B and introduced the new style.
iii) he/she rewrites the code from B and reintroduced the old style
(worst case).

Keeping backward compatibility may be nice, but it also has its drawback.
wxPy 2.5 is so new, I wonder if it not better to clean up the situation
even if it breaks compatibility. In that case, forcing the use of the Bind
method.

Uhm, there's also a slightly major drawback to not keeping backwards compatibility. It breaks every wxPython script written before 2.5! I wonder what newbies would think if they couldn't run most of the scripts they've downloaded?

***If*** we did this it would need to be a complete and clean split - 2.4 would need to remain in existence and be able to live alongside wxPython 2.5/6/3 peacefully. I agree with the 'there should be one obvious way to do it' philosophy, but I also believe that change takes time and forcing a large group of users to re-write a decent chunk of their (previously working) scripts to make it work with new versions of wxPython will upset a good number of people. What will happen is that over the course of 2-3 years, the old syntax will start to disappear and the new syntax will become prominent. In 5-6 years, probably noone will even remember the old syntax. =) It just takes time.

Thanks,

Kevin

···

On Nov 27, 2003, at 7:33 AM, Jean-Michel Fauth wrote:

Keeping backward compatibility may be nice, but it also has its drawback.
wxPy 2.5 is so new, I wonder if it not better to clean up the situation
even if it breaks compatibility. In that case, forcing the use of the Bind
method.

In principle, I agree, but as I've been going through converting the demo,
I've found that a *lot* of stuff is breaking with the new binder, in terms
of contributed libraries. Now, most of those are going to get migrated one
way or the other, but then we have a lot of other stuff that isn't
officially part of the wxPython library that's going to die when they
upgrade.

Then we hit files generated by stuff people use, such as wxDesigner and Boa
and thier ilk. Right now, if the reverse renamer and all were removed, all
that stuff would break, guaranteed.

Also, it has been promised that it *would* be backwards compatable as much
as possible. The point to remove backwards compatability *totally* is a
point after everybody's been duly warned.

What *might* be a good idea would be to pepper the compatability stuff with
deprecation warnings so as to get everybody moving the right direction. Then
drop the hammer down the road somewhere, like 2.6 or 2.7.

Jean-Michel Fauth wrote:

I really wonder if this is a good idea to keep this backward compatibility.
You know what will happen, some users will keep the old style and
other users will enjoy to use the new form The result is just two
programming styles for the same job. This will only introduce
confusion for new users. Experienced users, who want to exchange
code, will suffer from this too. User A, a new-style programmer, get
code from user B, an old-style programmer. What will the user A do?
i) he/she can keep the code from B and he/she has now a mixture of old and new styles, what is in my mind not very elegant.
ii) he/she rewrites the code from B and introduced the new style.
iii) he/she rewrites the code from B and reintroduced the old style
(worst case).

It's easy to add a pending deprecation warning in a future release to the EVT*.__call__ method, and also to the reverse renamer modules. Everybody will (or should) know that this is the direction we are moving and will have time to change.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!