Forem: icncsx

Parameter usage for default args in JS

icncsx — Wed, 24 Nov 2021 20:59:57 +0000

A default argument can reference a prior argument.

const defaultFunc = (num1,num2=num1) => {
    console.log(`num1: ${num1} num2: ${num2}`)
}

defaultFunc(3)   // num1: 3 num2: 3
defaultFunc(3,6) // num1: 3 num2: 6

Boolean coercion

icncsx — Wed, 24 Nov 2021 20:53:57 +0000

Use !! to see how JavaScript would coerce a real value into a boolean-ish interpretation.

console.log(!!" ") // true
console.log(!!"")  //  false
console.log(!!"0") //  true
console.log(!!0) //  false

Assignment has a return value in JS

icncsx — Wed, 24 Nov 2021 20:47:33 +0000

console.log(b=1) // 1

Because assignment has a return value, we are able to chain assignments.

let a;
let b;

a = b = 1

console.log(a); // 1
console.log(b); // 1

Hard to read, but it works...

let a = 1;
let b = 2;

let c = 3 - (a = b + 1);

console.log(a); // 3
console.log(c); // 0

Difference between parameter and argument

icncsx — Wed, 17 Nov 2021 17:21:37 +0000

The two terms are used interchangeably in conversation, but they mean different things. You pass arguments when calling a method. And you use parameters within the method body.

As most if not all programming languages are copy-by-value, the two are equivalent, only differing in the context. The two terms exist to distinguish whether you are talking about a method definition or a method call. When you're calling a method, you pass in arguments. When you're actually in the method body, you are using parameters. Arguments get copied-by-value to parameters.

Uploading Docker Images to AWS ECR

icncsx — Sun, 14 Nov 2021 19:38:55 +0000

AWS

`Create an ECR Repo`

aws ecr create-repository --repository-name <name>

`Log-in to ECR`

aws ecr get-login-password --region region | docker login --username AWS --password-stdin <registry_id>.dkr.ecr.<region>.amazonaws.com

`Tag your image`

Tag your image with the Amazon ECR registry, repository, and optional image tag name combination to use. This is important if we want to push to ECR and not DockerHub.

docker tag <image_id> <registry_id>.dkr.ecr.region.amazonaws.com/<repo_name>:<tag>

`Upload image to ECR`

docker push <registryId>.dkr.ecr.<region>.amazonaws.com/<repo>:<tag>

Lambda container approach in AWS

icncsx — Sun, 14 Nov 2021 19:28:24 +0000

`Zip vs Container Approach`

There are two ways to use Lambda functions in AWS. One is to provide the deployable artifact in the form of a zip file. You then have a variety of runtimes you can choose from: https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html.

The other approach is the Lambda container approach. IMO, the container approach to Lambda management has two main advantages over the zip approach.

`Runtime selection`

With the zip approach, you have to rely on Amazon supporting the desired runtime. For example, if your code depends on Python3.10, you better hope that Amazon supports that. In a container approach however, the runtime is something you have full control over. Just make sure either your base image supports the runtime or you install the runtime as part of one of your RUN statements.

`Building dependencies`

Non-native packages such as pandas, lxml, etc have to be built in the target environment for the compiled binaries to work. For example, if you build pandas on Mac, then the compiled binaries will work on Mac - not on Amazon Linux 2 which is what Lambda runs on.

With containers, you no longer have to worry about building for a target OS, as you're able to encapsulate OS details in an image. Put simply, the image you build locally will just work in Lambda. How easy is that!

What is manylinux?

icncsx — Thu, 11 Nov 2021 21:09:40 +0000

`Why Python packaging can be hard`

There may be a time in your development career where you need to author a package that extends Python w/ C or C++. In such a case your Python package needs to go through a compilation process, which converts C or C++ to binaries that work for a specific target system. This becomes really tedious when you think about how many flavors and versions of Linux there are. Building a separate binary for Red Hat, SUSE, Ubuntu, etc... Ugh so tiring.

`Why Python packaging can be easy w/ manylinux`

Fortunately, there is a solution. manylinux was birthed to make it easy for your Python packages to be compatible with most Linux variants. manylinux takes advantage of the fact that most distributions are mindful of backwards compatibility, and intentionally builds bdist wheels on an old version of a distribution. The idea is that if we build on an old supported version, the binaries produced are compatible with current versions.

`So what is a manylinux really? Is it a ham sandwich?`

No. Even better. It's a Docker image. manylinux is a Docker image built off a certain old versions of the CentOS operating system that comes bundled with libraries that are assumed to be present by default on almost all Linux systems.

You can find an example of manylinux distributions within the pandas project. Here are two (out of many) from the list of available pandas downloads from PyPI:

pandas-1.0.3-cp37-cp37m-manylinux1_x86_64.whl
pandas-1.0.3-cp37-cp37m-manylinux1_i686.whl

In this case, pandas has built manylinux wheels for CPython 3.7 supporting both x86-64 and i686 architectures. It's manylinux so this wheel should be compatible for many linux :)

Happy packaging!

Python Packaging: sdist vs bdist

icncsx — Thu, 11 Nov 2021 20:54:55 +0000

`Why packages?`

Let's start with a fundamental question: why package at all? Reason is fairly simple. Once you have created a package, then you are likely to use some of the code in other places. For example, you might want to do this:

from mypkg.module import func

`What is a distribution?`

A Python distribution is a versioned compressed archive file that contains your Python package. The distribution file is what an end-user (the client) will download from the internet when they run pip install.

There are two primary distribution types in use today: Built Distributions and Source Distributions.

`Source Distribution (sdist)`

A source distributions is the simpler of the two types of distributions. Intuitively speaking, an sdist is very similar to source code - the code that you write. Therefore, sdist will not include platform-specific binaries. The result is an archive (.tar.gz) that contains the source code of your package and instructions on how to build it, and the target system of your client will perform the actual build to create a bdist (wheel).

Creating an sdist is akin to sharing just the source. It doesn't build usable artifacts that the client can consume immediately. The advantage of this is that creating an sdist is the same for all platforms (Windows, Linux, Mac) and machines (32 Bit / 64 Bit). The disadvantage is that users have to build the package themselves once they download the sdist.

`Built Distribution (bdist)`

A built distribution, also sometimes referred to as a bdist, is more complex than an sdist in that it actually "builds" the package. Principally, bdist creates a distribution containing .so, .dll, .dylib for binary modules. The result is an archive that is specific to a platform (for example linux-x86_64) and to a version of Python (for example Python3.9).

Installing a bdist in the client is immediate, as they don't need to build anything (you as the package author have already built it for them, setuptools doesn't need to build it). The downside is that you as the package author have to build for multiple platforms and versions and upload all of the distributions for max compatibility.

`Should I produce sdist or bdist for clients?`

It is best practice to upload both, wheels and a source distribution, because any built distribution format only works for a subset of target systems. If there is not a platform-specific bidst that works for the end-user, they can go ahead and build locally w/ the sdist.

pip stuff you might need to know

icncsx — Thu, 11 Nov 2021 19:51:36 +0000

`PIP`

pip is the standard package manager for Python. It allows you to install and manage additional packages that are not part of the Python standard library. The concept of a package manager might be familiar to you if you are coming from other languages. For example, JavaScript uses npm for package management.

`pip3 vs pip`

pip is also the CLI command that you will use to interact with pip, and there are many variants.

> pip install pandas
> pip2 install pandas
> pip3 install pandas

The thing to note here is that pip3 operates on a Python3 environment only, as pip2 does with Python2. pip (w/o the 2 or 3) operates contextually. For example, if you are in a Python3 virtual environment, pip will operate on the Python3 environment.

`But pip3 can mean many things - like if I have Python3.7 and Python3.8?`

Yes that's correct. Let's say I have two versions of Python installed, like Python 3.7 and 3.8. Now, if you were to type pip or pip3 in your terminal, it's not very clear which Python interpreter gets involved.

And this is why you'll see many developers use python -m pip. python -m pip executes pip using the Python interpreter you specified as python. Here you can provide the full path to the interpreter like: /usr/bin/python3.7 -m pip instead of relying on an alias.

Program vs Process vs Thread

icncsx — Thu, 11 Nov 2021 18:59:25 +0000

`Program`

A program is simply an executable file that contains a set of instructions to complete a task. An application such as Chrome is one example.

`Process`

A process is any currently running instance of a program. So one program can have several executions (copies) of it running at once. One Chrome program can have multiple tabs/windows open. A colleague compares the relationship between a program and process to the difference between a Docker image and a container; I hope that analogy makes sense :)

`Thread`

One process can have multiple running threads. Put simply, a thread does lightweight, singular jobs. Threads exist for added concurrency. A process can have many jobs: think saving a file, reading keyboard input, writing logs, etc. Each thread can be responsible for its own task or "subprocess" so to speak.

Functions are first class objects

icncsx — Wed, 06 Jan 2021 08:29:08 +0000

By functions being first-class objects, we mean that we can:

assign functions to variables
store functions in data structures
pass functions as arguments to other functions
return functions as values from other functions.

`Assignment`

def yell(text):
    return text.upper() + '!'

bark = yell
bark('woof')

`Functions can be stored in data structures`

funcs = [str.lower, str.capitalize]

for f in funcs:
    print(f('hey there'))

`Functions can be passed to other functions`

def yell(text):
    return text.upper() + '!'

map(yell, ['hello', 'hey', 'hi'])

`Functions can be returned from other functions`

def talk(volume):
    def whisper(text):
        return text.lower() + '...'
    def yell(text):
        return text.upper() + '!'

    if volume > 0.5:
        return yell
    else:
        return whisper

talk(0.8)("hello")

What determines the truthiness of an object in Python?

icncsx — Fri, 25 Dec 2020 23:01:20 +0000

In Python we have truthy and falsy values. For example 0 is falsy and all other numbers are truthy. In fact, all objects in Python have a truth value.

By default, all objects are considered to be truthy.

class Foo:
    pass

bool(Foo()) # True

If you want to override this default behaviour, you have to implement the __bool__ method. If an object defines __bool__, then Python calls that method to determine its truthiness.

class Bar:
    def __bool__(self):
        return False

bool(Bar()) # False

Now all instances of Bar are False.