DEV Community: Noah Hughes

Python Imports: The Most Unintuitive

Noah Hughes — Mon, 09 Oct 2023 04:17:31 +0000

Have you ever felt like a programming language was punishing you for trying to clean up your code? To make it more modular? To make it follow the SRP? Well, if you have tried to do this in Python I can confidently say you have run into this very common, and very annoying error message

ModuleNotFoundError: no module named "example"

Let's say you encounter this error and see people say "Oh, just do absolute imports to avoid that issue!" and while yes that may solve the error, it is a messy solution. So, when you look into Python's relative imports instead and see that you just need to put an '__ init __.py' file in every directory your relatives should just magically work! Well, again, no. This same path of learning is what led me into the unintuitive, sloppy, and cumbersome world of Python imports. After finally dragging myself out of the other side of the abyss, I am hopeful this blog will be able to help someone else from having to stumble and trip through learning Python's import system.

First, let's discuss what kind of imports you can do in Python. For all of these examples, we will be using the following example tree

├── __init__.py
├── package1
   ├── package3
       ├── __init__.py
       ├── module7.py
   ├── __init__.py
   ├── module1.py
   ├── module2.py
   ├── module3.py
├── package2
   ├── package4
       ├── __init__.py
       ├── module8.py
   ├── __init__.py
   ├── module4.py
   ├── module5.py
   ├── module6.py

The first major import method to know is the absolute import. An absolute import does not require the '__ init _.py' files in your directories. While this may seem nice as it leads to less bloat by not requiring a bunch of what _can be empty files there is a very important caveat. When you do an absolute import, the file you import will have access to every variable and object that file has within its scope. Again, this may seem nice but it leads to a lot of extra code if you do use it. This is what it would look like if you wanted to try and do an absolute import from module1 to module4, thus allowing module4 to use the function module1() in module4. First, the import

#in module4.py

import package1.module1

And then to be able to call that specific function

#in module4.py

#some code...
package1.module1.module1()

Well that doesn't seem to bad. But what if wanted to also call on module2's module2() and module3's module3()? Well, we still only have one import statement, but this is where you see the bloat start to come in.

#in module4.py

import package1.module1

#some code...
package1.module1.module1()
package1.module2.module2()
package1.module3.module3()

While this is nice in fact that you know what you're getting and you can avoid circular imports (we'll come back to this later), it can quickly lead to a lot of extra code. Oh, you wanted to use module7's module7() in module4? Oh no...

#in module4.py

import package1.package3.module7

#some code
package1.package3.module7.module7()

You can see how messy this can begin to get if you have multiple levels of nested folders. You know, a really common file structure when working with larger projects. Not all hope is lost though! We know there is another main method of imports in Python. The relative import.

The relative import is the method that requires us to have all of those __ init __.py files, but why? Well, if you read through deep enough into the late 1990s web-styled documentation, you will see that these files tell the Python interpreter "Hey! Look over here for packages and modules too!" Once you have these in place you can create much cleaner and clearer import methods. If you were to import module2's module2() into module1 it would look like this

#in module1.py

from package1.module2 import module2

#some code

module2()

Now that looks much nicer! We can choose the one object we want from module2 also allowing other engineers to know where that function is coming from and it avoids the repetitive long strings of dot notation in both the import and in the function call itself. Well, everything is pointing to relative imports just being better for clear and clean code, right? Well, there are some caveats. Yes, more caveats, Python imports have a lot of those. Let's say you for some reason needed to also import module1's module1() into module2. A very common case for this is if module1() is a main menu for a CLI, and module2() is a sub-menu of module1(). Well, if you want a user to be able to navigate back from module2()'s menu to the main menu in module1(), you would need to call module1(). Okay, let's go ahead and set that up!

#in module1

from package1.module2 import module2

def module1():
    #some code
    if(choice == 'a'):
        module2()

#in module2

from package1.module1 import module1

def module2():
    #some code
    if(choice == 'back'):
        module1()

Hey, that's nice! We can have some clean navigation functionality for our code! Nope! You just caused a circular import! This is another one of Python's infamous error codes. And with Python's, again, unintuitive import system, it is tied to it. We have already discussed the solution to it though! Those extremely bloated and cumbersome absolute imports! Let's change our code to the import system that would work for this use case.

#in module1

import package1.module2

def module1():
    #some code
    if(choice == 'a'):
        package1.module2.module2()

#in module2

import package1.module1

def module2():
    #some code
    if(choice == 'back'):
        package1.module1.module1()

Does anyone else's stomach start to churn a little bit when having to see the way to avoid circular imports? We will come back to my extremely mixed feelings on Python, for now, let's look at yet another unintuitive aspect of Python imports. Relative imports from other file directories.

We already saw the syntax for relative imports within the same directory

from package1.module2 import module2

Seems simple enough, now let's look at the Python documentation on relative imports from different folders (the packages in our example).

Relative imports use leading dots. A single leading dot indicates a relative import, starting with the current package. Two or more leading dots indicate a relative import to the parent(s) of the current package, one level per dot after the first

Okay, so following this logic, if we wanted to import module1's module1() to module4 we would need to have two leading dots to reach our parent directory. Then step back down with the dot notation we have already done. Well, let's try it!

#in module4

from ..package1.module1 import module1()

Again, nope! Another one of Python's infuriating import errors! Yet another way to run into the ModuleNotFoundError. This method of running into that error is the one that broke me mentally. Everywhere I searched, every documentation I read, all led to me (and another experienced dev I had asked for assistance) being completely lost. After way too many Stack Overflow questions and Google searches about this, I decided to just look at an older project I had access to from using it as a lab. I checked how they would handle this same
import and the moment I saw it, I was ready to put my forehead through my desk. Want to guess the solution? I will give you a moment to think about it based on the documentation given to us by Python.

...........

#in module 4
from package1.module1 import module1

Well, that seems to suggest maybe the Python documentation is just blatantly wrong. Okay, what about if it's another directory level down to module7? Again, no. Again, the documentation is just flat-out wrong. The syntax to bring module7's module7() to module4?

#in module4
from package1.package3.module7 import module7

Yeah, this was the moment I gave up on believing anything the Python documentation stated. This was the same moment I decided Python had the most unintuitive, cumbersome, slow, and dated import system of any language used in modern programming. Even now that I have finished the project that required me to have a complex import system, even now after having to drag myself through the Python import trenches, I am fuming about it. How can such a beautiful, beginner-friendly, and powerful (but very slow) language still have such a horrible import system? While this blog has been both an exploration and a venting session for myself, I hope it will save someone else from the abyss that Python imports.

Chakra UI As A New Dev: The Odyssey

Noah Hughes — Mon, 25 Sep 2023 04:57:46 +0000

Coming into my next big project for Flatiron, I noticed a small but amazing detail about what we could do to handle styling for this project.

You can also incorporate a UI framework

I was ecstatic! I had heard about all of the magical things that frameworks like Bootstrap and Tailwind could do for styling! As I started to look and ask around about which I should try to use, I learned of Chakra UI. I started to look at their components and a lot of them seemed almost just like refactors of existing HTML elements thrown into a component ready to get dropped into your code. While that seemed convenient I was still curious, so how does this really work? That led me down the theming and styling rabbit hole.

Now, I knew I wanted to work with Chakra UI but how do I do that? I started looking through their documentation and I noticed it's actually really simple, or so I thought. As a new dev the only thing I have ever had to do as far as package management was

npm install
npm start
npm test
npx create-react-app

I look at their installation guide and it's like hey, run this npm command instead
npm i @chakra-ui/react @emotion/react @emotion/styled framer-motion
Seems easy enough. I run the command, my terminal does it's magic, and boom I now have the Chakra UI library in my project but I still can't use it just yet. I have to wrap my entire project inside of their <ChakraProvider /> component first. So I head on over to my index file, I see where React has set up my render me and I just give that <App /> component a big Chakra hug.

root.render(
  <ChakraProvider >
      <App />
  </ChakraProvider>
);

Okay, now I can use it, right? Well, technically yes. I could start dropping Chakra's components into my code, but that is almost everything I could do. I could do some mild coloring and styling but this was nothing compared to what I had seen Chakra could do for web applications. I did some more research and I found out that a lot of styling will also require Tailwind CSS. I make my way to their documentation and see they have a nice and simple install guide too.

Step 1: Run these commands

npm install -D tailwindcss
npx tailwindcss init

Step 2: Make your tailwind.config.js file and put this in it (whatever this means, I thought)

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: ["./src/**/*.{html,js}"],
  theme: {
    extend: {},
  },
  plugins: [],
}

Step 3: Make your global CSS file this

@tailwind base;
@tailwind components;
@tailwind utilities;

Wait, my npx create-react-app gives me two CSS files? Oh well, I'll delete this App one and just keep my index one. If it's the only one it's got to be my global one. I do a little className test for Tailwind with a <Box /> I grabbed from Chakra and by some miracle it's styled. At this point, I was feeling pretty confident in myself and I started coding away. I'm throwing variants on this component, hovers over that one, and making this <Button /> white... wait, why's my button not white? I looked through Chakra's documentation and I see that they have this whiteAlpha color, I assume that's what I want and I throw it on my component. Now it's opaque? Okay, let me try the hex for white. I set my background to #FFFFFF and still nothing. Well, that's strange I guess I'll just make yet another component red and move on. As I am working through this project I learn about Chakra UI templates. Now if you are reading this and somehow haven't seen these things, to my baby dev self, they are the most amazing things I have ever seen. (Here if you haven't seen them)

I was looking at fully structured, 'styled', and sometimes even animated components. I grabbed one of these templates, dropped it in my code, and morphed it into what I needed. I follow this pattern of finding what I need, dropping it in, and morphing it. Did they always have what I needed? Of course not, but that's when I brought in my handy Chakra components myself and just made what I needed. I was getting to the point where my project was getting closer to finished and I decided I didn't just want these default default black, white, and whatever random bright color I chose scheme for my project. I started researching the color issue again and that's when I fell down the real Chakra UI rabbit hole - custom themes.

Truthfully, before this project, I was not ready for this. I started looking through the documentation, looking at guides, and learning about color palettes. It all started with creating this theme you wanted and passing into that big <ChakraProvider /> hug from earlier, okay simple enough.

root.render(
  <ChakraProvider theme={customTheme}>
    <BrowserRouter>
      <App className="overflow-y-auto no-scrollbar" />
    </BrowserRouter>
  </ChakraProvider>
);

I started setting up my color pallet:

export default extendTheme({
  colors: {
      primary: {
        50: '#EDF6F9',
        100: '#D1E9F0',
        200: '#B5D9E6',
        300: '#99C9DC',
        400: '#7DB9D2',
        500: '#83C5BE',
        600: '#68A09B',
        700: '#4D7B78',
        800: '#326654',
        900: '#1B412F',
      },
      secondary: {
        50: '#FFDDD2',
        100: '#FFD3C0',
        200: '#FFC9AE',
        300: '#FFBF9D',
        400: '#FFB58B',
        500: '#E29578',
        600: '#BF745E',
        700: '#9C5444',
        800: '#79332A',
        900: '#561311',
      },
      neutral: {
        50: '#F7FAFC',
        100: '#EDF2F7',
        200: '#E2E8F0',
        300: '#CBD5E0',
        400: '#A0AEC0',
        500: '#718096',
        600: '#4A5568',
        700: '#2D3748',
        800: '#1A202C',
        900: '#171923',
      },
    },
});

Now I'm using these colors and surprisingly it starts looking pretty nice! Wait, I can do dark and light mode? Just requires another color pallet and some config object? Alright, let's do it!

export default extendTheme({
  config: {
    initialColorMode: 'light',
    useSystemColorMode: false,
  },
  colors: {
    light: {
      primary: {
        50: '#EDF6F9',
        100: '#D1E9F0',
        200: '#B5D9E6',
        300: '#99C9DC',
        400: '#7DB9D2',
        500: '#83C5BE',
        600: '#68A09B',
        700: '#4D7B78',
        800: '#326654',
        900: '#1B412F',
      },
      secondary: {
        50: '#FFDDD2',
        100: '#FFD3C0',
        200: '#FFC9AE',
        300: '#FFBF9D',
        400: '#FFB58B',
        500: '#E29578',
        600: '#BF745E',
        700: '#9C5444',
        800: '#79332A',
        900: '#561311',
      },
      neutral: {
        50: '#F7FAFC',
        100: '#EDF2F7',
        200: '#E2E8F0',
        300: '#CBD5E0',
        400: '#A0AEC0',
        500: '#718096',
        600: '#4A5568',
        700: '#2D3748',
        800: '#1A202C',
        900: '#171923',
      },
    },
    dark: {
      primary: {
        50: '#001C24',
        100: '#003039',
        200: '#00434E',
        300: '#005763',
        400: '#006D77',
        500: '#3073F8',
        600: '#6097FA',
        700: '#90BBFC',
        800: '#C0DFFE',
        900: '#F0F7FF',
      },
      secondary: {
        50: '#561311',
        100: '#79332A',
        200: '#9C5444',
        300: '#BF745E',
        400: '#E29578',
        500: '#FFB58B',
        600: '#FFBF9D',
        700: '#FFC9AE',
        800: '#FFD3C0',
        900: '#FFDDD2',
      },
      neutral: {
        50: '#171923',
        100: '#1A202C',
        200: '#2D3748',
        300: '#4A5568',
        400: '#718096',
        500: '#A0AEC0',
        600: '#CBD5E0',
        700: '#E2E8F0',
        800: '#EDF2F7',
        900: '#F7FAFC',
      },
    },
  },
});

Oh, I am cruising now! I start to set my light mode / dark mode with Chakra's useColorMode hook, I'm throwing in some more Tailwind to allow scrolling and I'm even making custom styles for certain components (after stumbling and tripping my whole way through Chakra's documentation) like this one to let me standardized how my <Heading /> component looked anywhere else in my project.

export const HeadingStyle = defineStyleConfig({
  baseStyle: (props) => ({
    textTransform: 'uppercase',
    fontWeight: 900,
    color: mode('secondary.800', 'secondary.500')(props),
  }),
  sizes: {},
  variants: {},

  defaultProps: {},
});

I noticed though not all of my files were letting me use Tailwind. Now, why was that? Well, outside of the default files React had made for me the rest of my file structure was using .jsx, not just .js files. A quick update to my config file

  ...content: ['./src/**/*.{html,js,jsx}'],

And I was good to go again. I had done it. With much stumbling, tripping, and painful debugging I was able to make a beautiful, custom, and interactive web application as my first remotely "larger" React project. I had many humbling moments during this journey, but I am proud to say, as a new dev, that I was at least somewhat able to showcase the strength of Chakra and also build a decent competency with it. To those of you curious, yes I did manage to learn how to use white and black in my application and you can see it live as my first deployed project as well!

The product of this odyssey

(Or if you want to see the meat and potatoes behind this project)

Async Await vs Fetch.Then()

Noah Hughes — Wed, 28 Jun 2023 18:13:30 +0000

In my time preparing for my bootcamp, I decided to get some practice with some web development fundamentals. One of those being working with APIs and manipulating JSONs that were returned to me. In my journey to self-teach myself how to do fetch calls, I came across a method that used async functions and a keyword of await.

const apiCall = async () => {
   const apiCallPromise  = await 
   fetch('https://api.example.com/data');
   const apiCallObj = await apiCallPromise.json();
   return apiCallObj;
};

This snippet is a quick and easy function to make a simple fetch request and return the parsed JSON as a mutable object. What the code is doing in practice is making my GET request to the endpoint, telling the code to wait for a resolved promise, taking that promise and turning it into an object using the .json() function, and finally returning that object. This is simple, clean, and predictable code. You always know what object you will get back is, and if you pass in parameters, you can easily control which endpoint you hit on the API with string interpolation.

When I began my bootcamp and started working my way through the course, I inevitably reached the chapter focused on JSONs and fetch, post, patch, delete etc. While going through this chapter I noticed we were taught another way of doing fetch requests. They weren't handle in async functions, they didn't use the await keyword, and they were linking callback functions to the initial fetch.

const apiCall = () => {
   fetch('https://api.example.com/data')
   .then((resp) => resp.json)
   .then((data) => {
      return data;
   });
}

Now that snippet looks much different from what I had learned. What is it doing exactly though? When invoked, the function will send my GET request to the target endpoint, it will then (get it?) invoke the then() function which takes a callback function. In this example that call-back function is simply returning the object of the response after invoking .json() on it. After doing so then() will take that parsed object and do something with it. That can be invoking another call back, changing the content of the object then, or simply returning it as my example does.

So, what is the difference between these two methods for handling requests? Is one better than the other?

There is three key differences between async await and then(). They boil down to syntax, error handling, and general code organization.

The syntax differences between the two are shown above; however, there is more going on behind the scenes of the syntax. With await, we are able to write asynchronous code in a way that looks and feels synchronous. await is allowing us to pause code execution until our promise is resolved and then again while parsing the JSON we get back from that fulfillment. With then() we are promise chaining. We are saying after this, do this, and so on and so on. This is what is allowing us to asynchronously handle the request sent to the endpoint. This promise chaining is more explicit and allows us to handle that promise in multiple ways before returning it.

The next difference is how these two methods handle errors. With await we are able to create a try and catch code block.

const apiCall = async () => {
   try{
      const apiCallPromise  = await 
      fetch('https://api.example.com/data');
   };
   const apiCallObj = await apiCallPromise.json();
   return apiCallObj;
   catch(error){
      console.error(error);
   };
};

This code block is acting as an if-else but one designed for acting with requests. What this is doing is in the try if the requests is successful, continue on and return the object; otherwise, throw this error to the console and tell me the error with the requests. With catch(), your errors are handled in your promise chain just as your then()s are.

const apiCall = () => {
   fetch('https://api.example.com/data')
   .then((resp) => resp.json)
   .then((data) => {
      return data;
   });
   .catch((error) => console.error('Error:', error));
};

This snippet functions exactly the same as done with the await example but the difference is that here, catch() is expecting a callback function.

The third key difference between the await and then() comes down to code organization. I have touched on it already but using await allows you to write your code in a more linear and organized manner. You can perform subsequent operations on the fetched response immediately after the await statement, which can make the code flow more naturally. With then(), you need to chain multiple then() calls to handle the response and subsequent processing. This can sometimes lead to nested or cascading then() calls, which may make the code harder to read and maintain.

So, which is better? I don't believe there is a definitive answer to this question. While I do have my preference in using await, I believe it comes down to the context of your application, use case, and preference.