Friday, April 17, 2015

Loopy else in Python

I love Python.  Yet, there are some minor things in the language that I find baffling...

Python loop statements (for/while) include an optional else clause whose behaviour is very counter intuitive.  In fact, it is so "bad" that Brett Slatkin, author of Effective Python, wrote as one of his 59 specific ways to write better Python:


Item 12: Avoid else Blocks After for and while Loops.

In fact, Guido himself wrote in 2009:


I would not have the feature at all if I had to do it over.

(My initial preference, when I learned about the meaning of else in those loops, was to wonder why "ifnobreak" had not bee used as a keyword instead; later I saw Raymond Hettinger suggest simply "nobreak" which I thought was both more readable and a better idea. [You can see Hettinger explain why in this video.]  However, Guido also mentioned in the above quoted message "I would *not* choose another keyword.")

In the official Python tutorial, when the else clause is discussed, we find these two interesting statements:


Yes, this is the correct code. Look closely: the else clause belongs to the for loop, not the if statement.
(I don't know about you, but when I read some similar warning in a tutorial, my immediate reaction is to question why it was done like this in the first place since it is recognized as being far from obvious.)


When used with a loop, the else clause has more in common with the else clause of a try statement than it does that of if statements...
This is yet another acknowledgement that people might be confused about the meaning of "else", since they mostly see it with "if" statements.  

 And it seems it's going to get only worse.  In a new PEP, we see that another similar else clause is proposed with the similar semantic...


async for TARGET in ITER:
    BLOCK
else:
    BLOCK2
 Why, oh why can we not introduce a clearer keyword (like nobreak) and stop introducing yet more examples of confusingly named clause...

Thursday, January 29, 2015

Type hinting in Python: focus on readability


tl;dr: the proposed type hinting for Python is done to help tools analyze code better (which can be very useful for programmers) but at the cost of reduced readability.  A different idea is discussed which focuses on readability.
----

So, Python is going to have some type hinting [PEP484].

I agree with the idea that lead to this addition to Python; however, I find that the syntax proposed is less than optimal. Thinking about how it came about, it is not entirely surprising.


  1. Functions annotations were introduced in 2006 [PEP3107].
  2. Various libraries worked within the constraints and limitations imposed by this new addition, including mypy [mypy].
  3. PEP 484 is "strongly inspired by mypy" essentially using it as a starting point. However, it indirectly acknowledges that the syntax chosen is less than optimal:

If type hinting proves useful in general, a syntax for typing variables may be provided in a future Python version. [PEP484]

What if [PEP3107] had never been introduced nor accepted and implemented, and we wanted to consider type hinting in Python?...

Why exactly is type hinting introduced?

As stated in [PEP484]:


"This PEP aims to provide a standard syntax for type annotations, opening up Python code to easier static analysis and refactoring, potential runtime type checking, and performance optimizations utilizing type information."

The way I read this is as follows:  type hinting is primarily introduced to help computerized tools analyze Python code.

I would argue that, a counterpart to this would be that type hinting should not be a hindrance to humans; in particular, it should have a minimal impact on readability.   I would also argue that type hinting, as it is proposed  and discussed, does reduce readability significantly. Now, let's first have a look at some specific examples given, so that you can make your own opinion as to how it would affect readability.

Simple example (from [PEP484]):

I will start with a very simple examples for those who might not have seen
the syntax discussed.

def greeting(name: str) -> str:
    return 'Hello ' + name

Within the function arguments, the type annotation is denoted by 
a colon (:); the type of the return value of the function is done
by a special combination of characters (->)  that precede the colon which
indicates the beginning of a code block.

Slightly more complicated example (from [mypy])

def twice(i: int, next: Function[[int], int]) -> int:
    return next(next(i))

We now have two arguments; it becomes a bit more difficult to see at a
glance what the arguments for the function are.  We can improve upon this
by formatting the code as follows:

def twice(i: int, 
          next: Function[[int], int]) -> int:
    return next(next(i))


What about keyword-based arguments?

From [PEP483]


"There is no way to indicate optional or keyword arguments, nor varargs (we don't need to spell those often enough to complicate the syntax)"

From [PEP484]


"Since using callbacks with keyword arguments is not perceived as a common use case, there is currently no support for specifying keyword arguments with Callable."

However, some discussions are taking place;  here is an example taken from https://github.com/ambv/typehinting/issues/18 (formatted in a more readable way than found on that site)

def retry(callback: Callable[AnyArgs, Any[int, None]], 
          timeout: Any[int, None]=None, 
         retries=Any[int, None]=None) -> None:

Can you easily read off the arguments of this function?  Did I forget one argument when I split the argument lists over three lines?  Can you quickly confirm that the formatting is not misleading?

Type Hints on Local and Global Variables

The following is verbatim from [PEP484]


No first-class syntax support for explicitly marking variables as being of a specific type is added by this PEP. To help with type inference in complex cases, a comment of the following format may be used: 

x = []   # type: List[Employee] 

In the case where type information for a local variable is needed before if was declared, an Undefined placeholder might be used: 

from typing import Undefined
x = Undefined   # type: List[Employee]
y = Undefined(int)
 
 If type hinting proves useful in general, a syntax for typing variables may be provided in a future Python version.(emphasis added)  

Edit: why not bite the bullet and do it now? Considering what this syntax, if it were introduced, should look like, might reassure people who see type information in comments as problematic and ensure that the limited syntax decided upon in this PEP will not have to be changed to be made coherent with the new addition(s).

What about class variables?  

I have yet to see them being discussed.  I assume that they would be treated the same as local and global variables, with an as yet undefined syntax.


A different proposal for type hinting.

Let's forget for a moment the syntax introduced by [PEP3107] for functions annotations, and imagine that we are considering everything from the beginning.

Type hinting is introduced for tools (linters, etc.).  As such, I would assume the following:

When reading/parsing code:

  1. type hinting information should be easily identifiable by tools
  2. type hinting information should be easily ignorable by humans (if they so desire)


By this, I mean that the type hinting information should not decrease significantly the readability of the code.


Let me start with an obvious observation about Python:  indentation based code-blocks indicate the structure.  Code blocks are identified by their indentation level, which is the same within a code block.

Tools, like the Python interpreter, are very good at identifying code blocks. Adding an new type of code block to take into account by these tools should be straightforward.


A secondary observation is that comments, which are ignored by Python, are allowed to deviate from the vertical alignment within a given code block as illustrated below.

def f():
    x = 1
    y = 2
       # this comment is not aligned 
       # with the rest of the code.
    if z:
        pass
  

Now, suppose that we could use a syntax where type annotation was  structured around code-blocks defined by their indentation. Since type annotation are meant to be ignored by the interpreter  (non executable, like comments), let us also give the freedom to have additional indentation for those ignorable code-blocks, like we do for comments.

The specific proposal
  
Add where as a new Python keyword; the purpose of this keyword is to introduce a code block in which type hinting information is given.

To see how this would work in practice, I will show screenshots of code from a syntax-aware editor containing type hinting information as it is proposed and contrasted with how it might look when using the "where code blocks".  I'm using screenshots as it provides a truer picture of what code would really look like in real life situations.

First, the example from [mypy] shown above:



Now, the same example using the "where" code-block.











I used "return" instead of "->"  as I find it more readable; however, "->could be used just as well.

Having a code-block, I can use the code-folding feature of my editor to reduced greatly the visibility of the type hinting information; such code-folding could presumably be done automatically for all type-hinting code blocks.








Moving on to a more complicated example, also given above.  First, the screenshot with the currently proposed syntax.









Next, using the proposed code-block; notice how keyword-based arguments are treated just the same as any other arguments. [Note: I was not sure if timeout above was a keyword based argument assigned a default value or not, since it used a different syntax from retries which is a keyword based argument.]







Again, using code-folding, the visual noise added by the type-hinting information essentially disappears.

Finally, the example with the "global variable", first with the proposed type hinting information added in a comment:











Next, using a code block; no need to import a special "type" to assign a special "Undefined" value: the standard None does the job.








A similar notation could easily be used for class variables, something which is not addressed by the current type-hinting PEP.

Type hinting information is going to be a useful feature for future Python programmers.  I believe that using indentation based code blocks to indicate type hinting information would be much more readable that what has been discussed so far.  Unfortunately, I also believe that it has no chance of being accepted, let alone considered seriously.  

[PEP483] https://www.python.org/dev/peps/pep-0483/
[PEP484] https://www.python.org/dev/peps/pep-0484/
[PEP3107] https://www.python.org/dev/peps/pep-3107/
[mypy] http://mypy-lang.org/

This blog post is licensed under CC0 and was written purely with the intention to entertain.






Wednesday, January 28, 2015

Revisting an old idea...

So, it now seems certain that Python is going to have some type hinting.  I'm not too fond of the proposed syntax although it is mentioned that some special syntax may be introduced at a later time if this idea proves to be useful.  However, it does not look like an adaptation of my 10 year old idea [*] which I still prefer over the discussed alternatives, would stand a chance...

[*] By this, I mean using where as a block introducing keyword - not necessarily all the specific examples mentioned which were meant to mirror the idea of GvR's blog post at that time.



Scratching an itch: improving pydoc

Pydoc is great - no make that fantastic.  However, I was never fond of the look of help pages displayed when pydoc is used in webserver mode.    Pydoc uses hard-coded styling options (including font and colors) based on deprecated html 4 syntax.

I decided to see if I could make it more customizable and, after a half-day coding sprint, I offer you mod_pydoc, which is somewhat more easily customizable using css.  The new version has a simplified styling as default.

mod_pydoc is only available from github (for now); I'm hoping that people with better designing skills will contribute some code to make the output look better than my feeble attempt.  Eventually, my intention would be to file a feature request to python.org and submit it as a possible improvement on the current module.

Monday, January 19, 2015

Disgusted by LavaSoft AdAware antivirus

A short while ago, I installed LavaSoft AdAware free anti-virus after reading a review praising it.  Many years (and computers) ago, before it had an anti-virus, I found LavaSoft AdAware very useful in cleaning up my PC and keeping it that way, free of various malware.

To make a long story short, I found that it caused the following problems:

1. I could no longer update Bracket's extensions.

2. I could not run IPython notebooks, getting the error message:

WebSocket connection failedA WebSocket connection could not be established. You will NOT be able to run code. Check your network connection or notebook server configuration.

It took me many hours, deleting my IPython profile, uninstalling and reinstalling IPython, doing the same with Tornado, trying in various browsers, searching for posts about people having had similar problems, etc., etc., etc. until I found this stackoverflow post which had a different problem but made me think that it was perhaps related to an anti-virus program issue.

I stopped MadAware (and restarted the default Windows Defender) ... no change.  On a hunch, I uninstalled it and rebooted (for the Nth time) my computer.

Sure enough, that was the problem.

After deleting MadAware, my problems went away.

I had to get this off my chest before I could resume working on tomorrow's lesson where I wanted to show off the IPython notebook.  


Thursday, January 08, 2015

Where are the edu-sig folks at the Python Education Summit?

After many years of being unable to attend Pycon, I look forward to this year's Pycon to be held (for the second time) in my favourite city, Montreal.  In the past, one of the highlights of that conference was meeting face to face other educators, many of whom I knew only through emails sent to edu-sig. At that time, there was no such thing as an official education summit.  Now there is.

According to the official description of the Education Summit,   We are taking proposals for talks from educators from all venues: authors; schools, colleges, universities; community-based workshops; online programs and government.

When I look at the current list of talk proposals, I see a list where very none of the proposals (other than my own) are from people who have contributee to edu-sig.  My own talk proposal (whose description is a little terse, I'll admit) has the dubious distinction of having been downvoted the most at this time! Unlike a few years ago, when I attended Pycon, there seems to be a huge disconnect between the people that contribute to edu-sig and who write books/tutorials/tools widely used in teaching Python, and the people currently interested in and submitting proposal to the Education Summit at Pycon.

(I would love to attend talks by people who subscribe to edu-sig and who have written books and/or tutorials about Python or created useful tools, like Naomi Ceder, Andrew Harrington, John Zelle or, probably the one I'd like to see the most, Philip Guo, who created the fantastic online python tutor.  One non-edu-sig contributor (as far as I know) who would be most interesting to hear from is Albert Sweigart who, in addition to writing many interesting books on Python is also thinking about making IDLE a better tool.)

There is one other talk that focus on a specific "tool" created to teach Python ("Python birds") in a postsecondary setting which has (and rightly so) seen an upsurge in votes in the past day or so.   While I do find some talks about teaching Python in non-traditional environments potentially interesting (and I have upvoted quite a few of the proposals for such talks), I don't think I would consider attending the Education Summit if that's all that there was.  However, the "Python birds" talk, if it gets accepted, would likely tip the balance for me and have me wish that I could be invited to attend, since it seems that participation is by invitation only.

Tuesday, December 30, 2014

EasyGUI_Qt progressing well.

A short while ago, I started working on an adaptation of EasyGUI for PyQt.  This new project is called EasyGUI_Qt.  For those that are not familiar with EasyGUI, the idea is to provide a series of graphical "widgets" that can be used in procedural programs.  For example, suppose you have a program where you query a user with Python's input:

    >>> input("Enter your reponse " )

Normally, you'd see a copy of the prompt appear, waiting for the user's response.  Using EasyGUI_Qt's  analogue of input(), this is what would show instead of a prompt:




There is also a demo launcher which can be used to see all of the available widgets:




A complete description of the existing widgets is available.  EasyGUI_Qt will not have all the same widgets available as the original EasyGUI.  While the current version number is 0.4, it is, in fact, nearly complete.  I have written a roadmap indicating what's left to be done until the 1.0 release. Anyone should feel free to make comments about the proposed roadmap including making suggestions for additional widgets (with justification provided).

EasyGUI_Qt targets Python 3.3 (and PyQt4) but should support (except for some pesky unicode issues) Python 2.7 - following some requests by users.