shared.python.utils 1.0

Github link: shared.python.utils

Welcome to the second post on python utils. Lets get to it, shall we?

empty_list()

To make an empty list with a specific number of items looks like this:

# generates list full of None values: 
empty_list = [] * number_of_items

While its not terrible, its not great either. I made this function so I could fill the list with something specific. Like so:

empty_list = pyutils.empty_list(number_of_items=0, default_item=True)

time_it() and count_it()

These two are useful decorators. What is a decorator you ask? Think of it as writing a generic wrapper for a function, but you leave the function variable. If you want a step by step on how to make decorators, please visit my decorator discussion page.


get_sorted_by_most_common()

I suppose this is where we get specific to problems I’ve had. I needed to sort all items in a list by how many items there are. for example:

data = get_sorted_by_most_common(
    [
    "Mouth",
    "Corner",
    "Up",
    "Mouth",
    "Up",
    "Mouth",
    "Up",
    "Mouth",
    "Up",
    "Mouth",
    "Corner",
    "Up"
    ]
)

# result:
# ["Mouth", "Up", "Corner"]

I’m aware this is not a common thing, but hey, if you ever have a similar issue, here it is.


That’s mostly it. Please ask questions if you have any. Leave a comment. Let me know how I’m doing. Thank you all.

//Isoparm

shared.python Intro

In my experience, having a good core library makes a world of difference. I couldn’t even imagine not having one. I owe all of my speed of development to my core library. It’s worth spending the time to get a good library started. And then, it’s worth keeping it up. I can’t stress this enough. To me, success in any Python project starts at your core library.

You will notice I use the words ‘core’ and ‘shared’ interchangeably. I dont like the word ‘core’ because it has baggage that I sometimes don’t fully follow and I end up spending a ton of time arguing semantics, rather than code. However, it’s an accepted word in the community, so it’s sometimes easier to just use it. I go back and forth on it. Maybe we should have a discussion on it in our discussions page?

Here are the modules that I’m currently planning for our core / shared library:

  • python
  • maya
  • math
  • ui
  • startup

python

We will start with the lowest level modules. These modules are meant to help with writing Python. For example, they can be wrappers for os or subprocess, or they can be a python utilities module for making some base decorators.

maya

These modules will contain wrappers for the maya.cmds, maya.mel, pymel, openMaya, and other Maya related modules. We will try to keep the code as un-opinionated as possible. Solutions here should be as generic as possible. So try to avoid thinking in terms of tools and workflow, and think more about APIs and what you think you will need for when you are making tools.

math

There are quite a few things that I don’t like doing in Maya. Math is one of them. If I can avoid opening Maya for my solutions, then I will be able to use my code in projects that are not for Maya. Among some of the modules in here, we will have vectors, angles, filters, math functions, point clouds, etc.

ui

This is one I end up arguing over a lot. In reality, this module is here for the sake of practicality, not for the sake of Pythonic purity. One thing I really like doing, is selecting a UI scheme that can work in most situations, and them making it so I can make GUIs quickly. I even developed an auto GUI maker once. I really liked it, since it allowed me to focus on the meat of the tools and code, and not on the GUI. As we develop this module further, I’m sure you will see the benefits.

startup

Yeah, we need one of these. It’s really convenient to have a single entry point for all your Python settings and environment. Here we will set up the logger, pick which Python Host we are in, load the correct versions of plugins, etc.

Alright, enough rambling. Next post, we will start on shared.python.utils.py

// Isoparm