Becoming an expert?

12 Jan, 2018

Femi A writes:

I just got your book: Python for kids and I’m excited to start reading it. I am 36 years old and I would like to learn computer programming. I figure python would be a good place to start. Is it possible to become an expert at python in 6 months with intensive efforts? And if it is can you please let me know how to go about that, the steps to take etc...

I would say this isn't necessarily a Python, nor even a general computer programming question. It's more a question about how you define expertise, what that means from a learning perspective, and what your goals really are. If you define expertise in terms of Malcolm Gladwell's 10,000 hour rule and spend 4-5 hours a day at it, you'll be an "expert" in 6 years or so [1]. So if your goal is to call yourself an "expert", then that's probably your timeline.

If your goal is to develop some software, make a meaningful contribution to an open source project, or something along those lines, and are well motivated, it's certainly possible to do that, and more, with 6 months of dedicated effort. So, how to get to the point where you're at least confident in your coding? Start with a beginners book, funnel that knowledge in developing a few simple projects to build your experience; then perhaps look for a more advanced Python book (O'Reilly's Python Cookbook might be a good option), followed by some more advanced projects, again for the experience. Just remember, it's more important to be coding than reading about it.

Hope that helps.

[1]: Also see this Business Insider article for a counterpoint to the 10K hour principle.


Python 3.5 beta issue on Windows

22 Aug, 2015

Tony writes:

I have installed Python 3.5.0b3, and when I tried to make the shortcut, it looked very different from the book's examples and I did not get the toolbar with "File", "Edit", "Options", etc. on the top. Please tell me how to correctly complete the installation process. Thank you, and I hope to hear back.

I'm not sure exactly what error you're getting, but I would suggest that while learning programming, you should probably use the latest release version of Python, rather than the beta. So at time of writing, that's version 3.4.3.

I do know of one problem with 3.5, where you need to move the DLL found in directory c:\Python35\DLLs\Microsoft.VC140.CRT, up one level (to directory c:\Python35\DLLs), in order to get tkinter working -- which I guess could be part of your problem (as detailed here: https://bugs.python.org/issue24847).

So that's simply moving the file here:

microsoft.vc140.crt file - original location

to here:

microsoft.vc140.crt file - new location

NOTE: this is no longer required for the release version of 3.5 (it was only necessary for the beta versions)


Multiplying Strings

11 Oct, 2017

Robin L writes (excerpted):

I am trying to teach myself how to code and thought this was a good place to begin. I am having trouble with the "multiplying strings" section. I don't know anyone else who codes so I am hoping that you are still available at this email. This is the part about printing a letter in the shell. For some reason when I run mine the "print()" keeps actually printing "()".

Can you please help me figure out what I am doing wrong?

There's a pretty major difference between printing with older versions of Python (Python2.7 and earlier) and newer versions (Python3 and later). In Python2, print is a statement, which means this works fine:

print "hi there"

If you try that in Python3, you'll get an error:

print "hi there"
  File "<stdin>", line 1
    print "hi there"
               ^
SyntaxError: Missing parentheses in call to 'print'

That's because print in Python3 is a function not a statement.

Why does that make a difference? In Python2, this code...

print()

...is a print statement followed by an empty tuple. You're effectively telling Python to "print this empty tuple", and by quirk of the way the print statement works, you get (). The exact same code in Python3 is a function name (print) followed by an open bracket, no parameters, and a closing bracket. You're providing no parameters and the function prints nothing as a consequence. And that, basically, is the difference.

Cutting a long story short - all you're doing wrong is running an older version of Python. Check chapter one, and follow the instructions to install Python3, and the code will work as you expect.


Top Few

05 Jul, 2020

I was reading Tim Bray's recent blog posts (here and here) about his Topfew utility with interest, and wondered how my go-to systems programming language (Nim) stacks up compared to Go. I knocked up a quick and dirty implementation and then ran against a 900MB access_log from my own site. A minute or so later I hit CTRL+C, realising my quick and dirty implementation was (a) not quick at all, and (b) perhaps a bit too "dirty". ಠ_ಠ

Once I changed from the naive read everything into memory approach, to using Nim's streams, I ended up with something slightly more acceptable. Caveat: not really optimised (well... apart from compiling with -d:release --passC:-mcpu=native --boundChecks:off flags), lazily developed, probably still naive, but at least has border-line acceptable performance (Github).

Results on my laptop (with an approx 1.5 million line access_log):

Elapsed User System vs Go
Tim's topfew 2.68 3.86 0.41 1.0
ls/uniq/sort 9.10 1.76 0.26 3.4
Nim 3.91 3.65 0.25 1.5

1.5x isn't brilliant, but it's not bad considering the minimal amount of effort I spent on it. But that led me to wonder, what about Python performance? Another Q&D implementation later (and this time I haven't bothered to dig into the performance at all)...

Elapsed User System vs Go
Tim's topfew 2.68 3.86 0.41 1.0
ls/uniq/sort 9.10 1.76 0.26 3.4
Nim 3.91 3.65 0.25 1.5
Python 8.57 7.77 0.79 3.2

Not much better than the uniq/sort version, but the python version is arguably a little more readable than Nim. One interesting difference between Python and Nim -- the Python version does read the whole file into memory before tokenising...

with open(filename) as f:
    for line in f.readlines():
    	...

...yet the performance was significantly better than my earlier naive Nim implementation which also read the whole file. So it's not just the right tool for the job, but the right technique for the tool.

Do I feel like dusting off the rather rusty Haskell skills though...?