Michael Driscoll, please fix wxPython Cookbook!

wxPython Users
1

If you don’t like Mike’s book, don’t buy it. There is no reason to be nasty about it – particularly in a public forum.

If you do have suggestions or corrections, There must be a way to contact him directly. Hopefully nicely.

However, this is an appropriate forum to discus what should be idiomatic wxPython, so:

Also, wx.Frame.init(self, None, title=‘Python Image Title’) and all other examples can be super().init(parent=None, title=‘Python Image Title’)

The code is much cleaner that way and if you’re dealing with multiple inheritance, you are golden with super().

We’ll, yes and no. super() is kind of ugly and confusing syntax ( in py3 anyway ), and the subclassing only works well if the superclasses are carefully designed to handle super properly.

I’ve vacillated about this myself for years, but tend to go back to the explicit call. And it’s particularly appropriate for a tutorial.

Also, add keyword argument names! Don’t just write SomeClass(blah, None, blah_some_more)

I agree here, but you can be nice about it.

It’s particularly important when you need to add extra parameters to a subclass.

I also prefer *args, **kwargs for passing the usual arguments on to the superclass:

def init( self, custom_arg, *args, **kwargs):

wx.Window.init(*args, **kwargs)

…

Then I use keyword arguments when I call it:

w = MyWindow(parent=self, size=(800, 600))

So you only need to pass the ones that aren’t default.

Pardon the typos, hard to write (or test) code on a phone!

BTW: if you want to provide the community with good examples of idiomatic wxPython code, going in an updating the wiki would be great.

I also have a substantial collection of demos here:

https://github.com/PythonCHB/wxPythonDemos

Those were written over a very long period of time, and the older ones have outdated ( and downright awful ) style, and may not even work anymore.

I’d really appreciate any PRs for improved style or functionality – It would be far more helpful to the community if they all had clean style and actually worked :slight_smile:

One more opportunity:

The wiki page here:

https://wiki.wxpython.org/wxPython%20Style%20Guide

Was written quite some time ago – maybe it could use a review?

-CHB

2

If you don’t like Mike’s book, don’t buy it. There is no reason to be nasty about it – particularly in a public forum.

If you do have suggestions or corrections, There must be a way to contact him directly. Hopefully nicely.

However, this is an appropriate forum to discus what should be idiomatic wxPython, so:

I do have multiple ways of contacting me…this is probably one of the rudest ways. It should be noted that OP is known to behave this way though…

Also, wx.Frame.init(self, None, title=‘Python Image Title’) and all other examples can be super().init(parent=None, title=‘Python Image Title’)

The code is much cleaner that way and if you’re dealing with multiple inheritance, you are golden with super().

We’ll, yes and no. super() is kind of ugly and confusing syntax ( in py3 anyway ), and the subclassing only works well if the superclasses are carefully designed to handle super properly.

I’ve vacillated about this myself for years, but tend to go back to the explicit call. And it’s particularly appropriate for a tutorial.

Yeah, I almost used super() in this book, but decided against it. I have seen very few examples that use it and I didn’t want my readers to be confused by a new syntax. I did mean to mention the differences though, so that is something I may add.

Also, add keyword argument names! Don’t just write SomeClass(blah, None, blah_some_more)

I agree here, but you can be nice about it.

It’s particularly important when you need to add extra parameters to a subclass.

I also prefer *args, **kwargs for passing the usual arguments on to the superclass:

def init( self, custom_arg, *args, **kwargs):

wx.Window.init(*args, **kwargs)

…

The main reason I didn’t do keyword arguments in a lot of the examples is because the line width can get too wide for the various book’s formats. For example, the code examples might look fine in PDF, but they might look like garbage in mobi if the reader is using a phone. I can’t mitigate all screen sizes of course, but I was trying for a nice middle ground. If I ever get around to writing my introductory book on wxPython, I will certainly consider adding those.

Mike

···

On Wednesday, March 22, 2017 at 10:49:27 AM UTC-5, Chris Barker - NOAA Federal wrote:

3

Well, tough to have to use less than an 80 character line. But when lines
get long in general, I like to put the arguments on their own line anyway:

def __init__(self,
             parent=None,
             title='Python Image Title',
             size=(800,600),
             )

that should fit on a pretty small screen.

Also, trying to read a programming book in format that doesn't support 80
characters on a line is kind of a lost cause anyway....

-CHB

···

On Fri, Mar 24, 2017 at 11:24 AM, Mike Driscoll <kyosohma@gmail.com> wrote:

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

4

Oh, I totally agree. It’s either going to be the lines are too long or the code is broke up across multiple pages. You can’t make every one happy.

The people who have contacted me about this book have been happy with it though.

Mike

···

On Friday, March 24, 2017 at 4:18:49 PM UTC-5, Chris Barker wrote:

On Fri, Mar 24, 2017 at 11:24 AM, Mike Driscoll kyos...@gmail.com wrote:

Well, tough to have to use less than an 80 character line. But when lines get long in general, I like to put the arguments on their own line anyway:

def init(self,
parent=None,
title=‘Python Image Title’,

         size=(800,600),
         )

that should fit on a pretty small screen.

Also, trying to read a programming book in format that doesn’t support 80 characters on a line is kind of a lost cause anyway…