DEV Community: YairMorr

How I learned a Python trick from a JavaScript book

YairMorr — Wed, 10 Jul 2019 11:32:24 +0000

I’m working on a nice little tool for project management in Autodesk Maya. It has a few drop down menus that contain folders and files inside a project root directory. This tool automates a few steps and helps the user quickly switch from one project to another without browsing for files.

Maya Project Browser, how it looks as it is in development

While working on this tool, I ran into an annoying scope issue with my algorithm when iterating over a loop, that prevented me from assigning the value I wished to a variable. I wanted to track an index value for each drop down menu, and instead I got the same value for all menus.

I then remembered reading on a very similar issue on my favourite JavaScript book series — You Don’t Know JS by Kyle Simposon. In his book Scope & Closures, he explains that while assigning a variable to a function from inside of a loop captures a copy of that variable, it is still sharing the same scope. This means that each function call inside my loop refers to a copy of the variable that eventually points to the same value. But I write my tool in Python and not JS, as it is the language used in Maya for writing scripts.

From my experience in visual effects, problems are usually similar across different platforms, and the solutions are usually similar as well. But can this bit of wisdom serve me in the world of code? Not surprisingly, the answer is yes! I figured if this scope issue happens in JavaScript, it might as well happen in Python.

Simpson’s solution in Scope & Closures to this problem was to pass that variable to the same function, but enclosing it inside an IIFE. Now you can assign that variable to a local variable inside the IIFE (which is inside the loop). The local variable now holds a copy of the value for each iteration and passes that value to the function and it does not change after the loop iterates again and again.

In Python, as far as I can tell, there are no IIFEs and no blocks of code, like in JavaScript. To solve this issue, I just enclosed the code inside the loop in a new method and called this method within the loop. This new method essentially serves as an inner scope, similar to JavaScript’s IIFE, which “locks” the value I require and pass it down safely to the method inside.

This is basically it! Following below is a detailed explanation of how I implemented this in my code.

My script has a main class that contains all the methods and variables for the tool.

The first method is initUI(), which creates a window and adds some buttons and the dropdown menus (Maya’s cmds.optionMenu()) and stores them in a dictionary called self.menus.

The cmds.optionMenu() function in line 6 above takes a label for the dropdown menu, which is “Menu”+str(i). The cc attribute passes a callback event handler that executes once a user selects an item from the menu. To pass in additional custom parameters, I use a lambda function and call my event handler self.indexFolders() within it.

The important part here is the variable i that is passed to every optionMenu’s indexFolders() method. It holds the dropdown menu’s index, the variable I wish to use later when I want to update the content of my menus.

As it is now, once the script executes, every dropdown menu’s indexFolders() has i passed in each iteration of the loop, but eventually every indexFolders() holds the value i had at the last iteration of the loop, instead of the value i has at the time of declaration. This means that every time I select an item from any optionMenu object, I get the same value (in this case, 3), instead of an index from 0 to 3 for each menu respectively.

In Scopes & Enclosures, Simpson suggests enclosing the body of the loop in a block {} or an IIFE. The solution I found in Python was to put my code in another function and call it within the loop, like this:

The createMenu() method has the exact line of code as in the previous snippet’s line 6. I just changed the name of the variable from the loop’s global i to the method’s local level. Now I call createMenu() from within my for loop and assign it i every time, and createMenu() assigns it’s local level to the event handler with the value I intended it to have — the index for the loop.

Now each optionMenu object has a different value, based on it’s index, and I can use that value to know exactly which menus to update!

Learning JavaScript is great, and it’s even better when the knowledge I acquire helps me indirectly solving problems with other languages and establishing a deeper understanding of coding and computer science.

CS101 —Python exercise: counting days between two dates

YairMorr — Thu, 06 Jun 2019 13:20:22 +0000

CS101 — Python exercise: counting days between two dates

As part of Udacity’s Intro to Computer Science online course that I’m taking, I ran into this interesting exercise. The goal was to create a function that takes two dates as input and counts the days between them. The first date is always earlier than the second. My solution was probably not the most elegant and my code could be shorter and more efficient. The logic however was the important thing to understand, and that is also what I want to focus on in this article. This exercise was written in Python.

If we put the two input dates on a timeline, the algorithm is working from the outside in. First it calculates the days in the months of each end of the timeline, then the days in each month for each year and then the days in all the years in between. The longer the distance is between the two input dates, the more conditions necessary for the algorithm to calculate the days correctly.

1st step — Counting the days inside each month

Here, daysCount is the general counter of the days between the two days, which I used throughout my function and eventually what the function returned. I assigned it to the day2 argument. I then subtracted the amount of days in month1 from day1 to get the count of days for the rest of month1. I used the list monthsCommonYear to get the exact amount of days in each month (I tend to leap years later on). This is the first because it occurs in every scenario.

This step returns the result for two input scenarios (I’m using DD/MM/YYYY format here):

The two input dates have the same year and same month (i.e. 12.8.2012–28.8.2012)
The two input dates have the same year but sequential months (12.8.2012–15.9.2012)

However, if the input dates are for the same year but the months are different, the function goes to the next step.

2nd step — Same year, different month

In this step, if the months are not sequential and the year is the same, I count the days between the first and the last month (i.e 12.8.2012–24.12.2012)

3rd step — Sequential years

Here, if the time between the input years is 1 year or more, I add whole months to my daysCount. for year1, I add the next month (month1+1) till the end of the year. For year2, I count months from (month2–1) till the beginning of the year. I take care not to count the days in the months I counted previously. I also take care to count the correct months in my monthsCommonYear list, knowing my arguments can go from 1 to 12, but my list index goes from 0 to 11.

Distant years

The last step is pretty straightforward. I add to my daysCount the days in each year between year1 and year2. The function eventually returns daysCount.

Accounting for leap years

This exercise had an additional challenge, which made it even more interesting: the function has to tell if a year is common or leap and calculate the days accordingly. It was actually easier than I thought. The Udacity instructions linked to a Wikipedia article that offered the exact algorithm I needed and that was easily converted to a function like the one below.

The comments in this snippet are taken straight from the description in Wikipedia.

I used this function in two types of scenarios:

To determine which month list to iterate over — leap or common.
To calculate the amount of days in the last scenario — when there’s a difference of more than 1 year between the two input dates.

I called checkLeapYear() 5 times in my function: 4 times to choose which month list to use (common or leap) and 1 time to add the years to my count. That’s why I preferred checkLeapYear() to return a boolean instead of the number of days in each year (365 or 366).

Here’s the first part of the function, updated to calculate leap years. Notice I added another list for leap year months (the only difference is 29 days in February).

The code I wrote for this exercise is long and encumbered, and perhaps later in my studies I will refactor it to something shorter and more efficient. The important thing for me here was exploring the logic behind the solution, rather than the way it was implemented.