JS – Can I stop "use"ing "strict";?

It was during grade school that my analytical skills and thought process was developed. It came largely through the many hours I spent toiling through my Saxon Math and Algebra books, the names of which can strike fear into the heart of nearly any homeschooler. While mathematics was not my favorite subject in the world, I always did very well in it. This was accomplished, as aforementioned, by the many hours I spent not only trying to understand the poorly explained and demonstrated mathematical concepts but by always working to get the correct answer in the correct manner. There was always an answer; I just had to find it. Generally, math always has an answer to the equation. I would sometimes spend close to an hour solving and resolving one question, with 20-something more questions to do, because I did not fully understand how to solve it and was determined to get that coveted correct answer using the correct process.

Thus my deep analytical and logical thought process was thoroughly developed, becoming my greatest strength and biggest weakness. In anything I do, I seek out a good, proper, logical, and most efficient way to proceed, and research questions in a quest to find the answer. Lately a few people have interpreted this behavior pattern as perfectionism, something I truly am not anyway near or wish to be. When I am unable to find a suitable closure for the journey at hand, I often get very frustrated, for the answer I am looking for (and indeed there is an answer; most of my searches are ones that have at least a “best practice” or “generally accepted” ending) cannot be found, and I want to know it. Usually when my exploration hits a dead-end like this, I stop looking it up for a while and maybe the next day, a few days, or a week later, I resume my search, this time with a clear mind and better understanding of the issue at hand. It is rare I have an oft-lingering case without any answer, and if the channel dries up, I compose a new method to perform the same thing.

This post, however, explores one of those unanswerable questions I cannot find an answer to.

Continue reading

Python – What is the __future__ module?

I was asked an interesting Python question recently: what is the __future__ module?

If the __future__ (PEP that introduced __future__) module seems vaguely familiar to you, it is because I use it in most of my Python tutorial scripts and have briefly talked about __future__ in a few of my tutorials, but I have never really explained what it is.

You know how you must import sys in order to access the functions located in the sys module? The same goes for accessing the special items located in __future__. However, you cannot simply import the __future__ module like any other module. That is because __future__ backports standard functionality in future Python versions. Because making them standard at in a typical patch release may create breaking change (and breaking changes should never be made in a patch release), the Python developers instead a reference to the new feature in __future__ and waited to introduce the new standard behavior in a minor- or if it is a highly volatile change, major- release.

By inserting a reference to the new changes in __future__ and withholding making them standard until the appointed version prevent substantial breaking changes, it also permitted developers early access to the changes, thereby allowing them to update any code that may/would break or benefit from the coming changes. For example, both the with statement and Python 3 print() function was initially made available through __future__. Python 2 developers often import __division__ to gain true division, something not made standard until Python 3.0.

In all cases, if the Python version being used supports the feature or change without needed __future__, the import is ignored. This is good in the chance the code supports both Python 2 and 3.

To access the content in __future__, use the from module import item syntax. You cannot use the “normal” import module and dot notation method, as nothing it references can be used in that manner, nor will from module import * work (“SyntaxError: future feature * is not defined“). Any __future__ imports must be the first imports made. Importing __future__ code after importing other modules will again raise a SyntaxError (“from __future__ imports must occur at the beginning of the file“).

To quickly demonstrate using __future__ in a script, we will write a Python 2 and 3 supporting script that rolls a set number of dice (however many dice is defined by the numOfDice variable) that for some reason must make use of the end parameter of the Python 3 print() function, which recall is only available in Python 2 by importing it from __future__ (exactly why the script is written this way stems the author’s lack of ideas, the fact this use case has been covered before in a previous tutorial, and a limited number of currently relevant __future__ imports that do not require using an archaic version of Python :P ).


If you were to comment out the __future__ import and run that script on Python 2, you would encounter a SyntaxError because you do not have access to the New and Improved Print Function™

And that is __future__ in a nutshell. :)

2 years of programming!

As of today, the 26th of January, I have been a programmer for two years! :D

You may be thinking to yourself:

le717, two years is not a very long time. Two years is really only a beginner!

Well, it depends on how you look at it. Two years may not be a long time in terms of experience, but I have gained some experience in those years. It may not be much in terms of knowledge and wisdom, but I dare to say that I have gained both knowledge and wisdom in this two year’s time. I do think that in these two years of a life of code I have done very well, all because God has gifted me with these talents and abilities. Without Him, I would not be where I am right now. :D

In case you were expecting some program release, update, or special thing I have written to celebrate, I must sadly inform you I have not done such a thing. :( In an attempt to make it up to you, have a nice song. :)

Here is to two whole years of programming, and may I continue to learn, grow, and experience more in code in the next years to come. :D


P.S. Happy new year! I know, this is late coming, but this was the only post I had ready for the first of the new year. :P

Conforming to an established code style

Recently I was doing a quick pre-pull request code review for a project I had filed a bug report with. The person contributing the fix (who was not the developer of the project) admitted he was not that experienced with the overarching code, so I left a few comments on his changes in an attempt to help him out. While doing this, I saw the entire script had been reformatted. Naturally I inquired why, as it was not part of the required and requested changes. It turned out to be a beautifier that runs on save, and he had forgotten to turn it off.

Continue reading

“That’s what Christmas is all about, Charlie Brown.”

As I wrote last year, A Charlie Brown Christmas is one of my all-time favorite Christmas TV shows. Why is that? Because it accurately portrays the events that occur at this time of the year, possibly even truer this year than any year before. Christmas music was already being played in stores and malls on 1 November this year. Thanksgiving week (including Thanksgiving day) and the week after were glorified shopping events where you could max out your credit card buying stuff you wanted in a matter of hours. Every Christmas special and Christmas-themed segment on the morning news talked about what they called the true meaning of Christmas, be it family, friendship, love, kindness, peace, or giving. Nearly every one of these things were represented in A Charlie Brown Christmas, a hand-drawn cartoon created all the way back in 1965: Snoopy decorating his dog house in order to win “Money! Money! Money!” and Sally wanting money in “10s and 20s”.

Continue reading