Wingware Blog: Renaming Symbols and Attributes in Python Code with Wing Pro’s Refactoring Tool

In the previous Wing Tips post we looked at using multiple selections to edit several parts of code at once. As part of that, we briefly mentioned that refactoring is a better approach when renaming a symbol or attribute globally. Let’s take a closer look at that now.

What is Refactoring Anyway?

Refactoring is the process of changing code in a way that does not alter its functionality, in order to better organize the code or make it easier to read and maintain. A round of refactoring is often appropriate before working on code that has become a bit crufty over time.

IDEs like Wing Pro can help with this process by automating some of the operations commonly made during refactoring, including renaming symbols or attributes, moving symbols around, collecting code into a new function or method, and so forth.

Renaming Symbols and Attributes

Rename refactoring is often used to make code more readable by selecting clearer or more appropriate names. It may also be used to change a method on a class from __Private form, which in Python can only be accessed from code in the class itself, to a form that can be called from code outside of the class. For example:

/images/blog/refactor-rename/refactor-rename-1.gif

Renaming method “__SetPosition” to “_SetPosition” with refactoring, so it can be used from outside of the class

Renaming Modules and Packages

Rename refactoring may also be used on whole modules or packages, by renaming any use of the module or package name. Wing Pro will rename the associated disk files and directories and track the change in the active revision control system, if any.

/images/blog/refactor-rename/refactor-rename-2.gif

Renaming module “urlutils” to “urlops” with refactoring

Like-Named Symbols and Symbol Identity

Wing Pro’s rename refactoring uses static source analysis of your code to determine which symbols are actually the same symbol. For example, in the following code there are two distinct symbols called name, one in the scope show_name and another in the scope process_name:

 def show_name(name=None):     if name is not None:         print(name)  def process_name(name):     show = enter_name(name)     if show:         show_name(name=name) 

Renaming name in the first function should only affect that scope, and any code that is passing the argument by name, as in the following example:

/images/blog/refactor-rename/refactor-rename-3.gif

Refactoring to rename only one of two distinct but like-named symbols “name”

Uncertain Symbol Identity

In some cases, Wing Pro cannot determine for certain that a like-named symbol is actually the same symbol as the one you are renaming. In the following example, a missing import statement prevents Wing from determining that the instance of name in the file testanother.py is definitely the same symbol:

/images/blog/refactor-rename/refactor-rename-4.gif

Renaming “name” finds an uncertain match, where a missing import prevents analysis from establishing the symbol’s identity

When this occurs, Wing marks the potential match with a ? and won’t rename it unless you check the checkbox next to it. Items can be visited in the editor by clicking on them in the Refactoring tool.

If you find Wing is failing to identify many symbols with certainty, you may want to check that your configured Python Path in Project Properties is allowing Wing to trace down the modules that you import in your code. You should see code warning indicators on imports that cannot be resolved.

In some other cases, adding type hints may also help Wing’s static analysis of your code.

Wing Pro also provides a number of other refactoring operations that we’ll eventually go through here in Wing Tips. For more information, take a look at Refactoring in the product manual.

That’s it for now! We’ll be back next week with more Wing Tips for Wing Python IDE.

Planet Python

Mike Driscoll: Pros and Cons of Indy Publishing

I personally really love self-publishing or Indy Publishing, so I am a little biased. In this article, I will go over what I think are the pros and cons of Indy Publishing versus going with a “real” publisher.

Pros

Here are my favorite parts about indy publishing:

  • I control the release date
  • I control the content
  • eBooks can be updated within minutes
  • Your royalty rate is 70-90%
  • Prices can be changed in seconds
  • Flash sales are easy
  • It looks good on a resume / cv

I’m going to expand a bit on some of these points. I have worked with two publishers as an author: Packt Publishing and Apress. Packt has very aggressive timelines for getting things done. Chapters have to be done according to the schedule. A publisher can throw you curveballs when you are getting close to the end as well. When you self-publish, you control all of that.

When I want to fix errata in my book, change an example or add a chapter, I can just do that and send out the update.

If I want to give my book(s) away for free to students or whoever I want to, I can do that too. I donate books to local python user groups too. Feel free to contact me if you’d like some swag for your group. I may charge shipping if you live a long ways away though.

Leanpub, Amazon and Gumroad have reports you can look at to see how well your book is doing. These are very useful.

Finally I wanted to point out that employers don’t seem to care if the book was self-published or done through a publisher. Either way, they are usually interested and/or impressed.

Cons

Here are some cons that I have learned about from indy publishing:

  • You don’t get an editor
  • No technical reviewers
  • No marketing department
  • No art department

After working with a couple of publishers, I noticed I didn’t really get any useful feedback from editors. I have worked with No Starch Press as a technical reviewer and I thought they gave better feedback to the author, but I only saw a little of that so I don’t really know how much they actually received.

I did have a couple of technical reviewers on my wxPython Recipes book. That was helpful, although not as much as I thought it would be. As I mentioned in my previous post, I usually use my blog and Kickstarter to get feedback about my books before I launch them and that works as well or better.

It is nice to have someone else do the marketing. Packt even assigned a publicist to me briefly. And Apress was helpful in giving me ideas about more consistent styling of the chapters and sections.

The biggest con in a way is that you have to pay for everything. Artwork is expensive. Advertising is expensive too. You have to keep an eye on all of that and figure out what you want to spend and how you want to spend it.

Negotiating Contracts

When you self-publish or just blog a lot, publishers will probably come knocking and ask you to write for them. Or they might ask to buy the rights to your book and reprint them under their branding. While I don’t have a lot of experience negotiating contracts, I will mention a few points.

If you are not well known in whatever community you want to sell to, that will hurt you at the negotiating table. Make sure you have the publisher’s time table before you decide on your final asking price.

Writing a book is a time consuming and usually lonely process. Unless you already write a lot, it will most likely take you much longer than you expect. If the publisher wants you to do a convention, make sure to ask for your compensation to go up. They may not pay for everything, but they will usually bump it up a bit.

One other thing I want to mention is that the advance that you get paid may be all that you get paid for the book. In fact, it is best to just think that is what is going to happen so you don’t get disappointed. Let’s crunch some numbers. Most publishers pay around 10% as their royalty rate. Now let’s say you get a $ 4000 advance. You don’t start getting royalties when they hit $ 4000. Instead you get paid when your royalty amount goes over $ 4000.

If the book is selling for $ 25, your royalty will be something like $ 1.25. You would need to sell over 3000 books before you start getting royalties. Sadly you will probably never get there.

You can read more about this topic and writing books in general here.

I think the biggest positive I had when working with publishers is getting one of my books in a Humble Bundle. As an indy publisher, I can’t get into those. Will I make any money from that? I don’t know. The royalties for bundles are small and only find out how well your book is doing on a quarterly basis at best.

Wrapping Up

I really enjoy publishing my own books. I like the freedom it gives me with the content and the ability to share my content however I see fit. I have learned a lot from working with publishers though. They certainly have their place. But I think you can do just as well without them if you are willing to put in the work.

Planet Python