Looking at your instance handle, I hope/assume that your comment is supposed to be in lighthearted jest. However that would only be an assumption on my part and in general it’s not ok to say someone’s job/work tool is for [remarks directed at sex, gender, ethnicity, orientation, disabilities, etc…] per CoC 3.5.

Please take into consideration that members on this instance may be of different backgrounds than what you’re used to and interpets what you say differently. Further breaches of our Code of Conduct may lead to temporary or permament ban.

From the perspective of the admin team, as long as reports are consistently resolved in a timely manner we are happy.

If you have any questions or want help with finding extra moderators, feel free to ask it here or via DM, otherwise we also have a Discord server and a Matrix space where we can talk.

@jnovinger@programming.dev

Just a reminder that we sent you a DM some time ago, but have yet to receive an answer. Happy cake day :)

-The admin team

Please refrain from using personal insults in this community. You’re free to express your opinion, but personal insults does nothing but make the community more toxic. c/programming is a gathering ground for both inexperienced and experienced programmers, so this level of lashing out is uncalled for.

Personally I would recommend to use regex instead for parsing, which would also allow you to more easily test your expressions. You could then get the list as

import re
result = re.findall(r'[\w_]+|\S',  yourstring)  # This will preserve ULLONG_MAX as a single word if that's what you want

As for what’s wrong with your expressions:

First expression: Once you hit (, OneOrMore(Char(printables)) will take over and continue matching every printable char. Instead you should use OR (|) with the alphanumerical first for priority OneOrMore(word | Char(printables))

Second expression. You’re running into the same issue with your use of +. Once string.punctuation takes over, it will continue matching until it encounters a char that is not a punctuation and then stop the matching. Instead you can write:

parser = OneOrMore(Word(alphanums) | Word(string.punctuation))
result = parser.parseString(yourstring)

Do note that underscore is considered a punctutation so ULLONG_MAX will be split, not sure if that’s what you want or not.

I don’t have any experience with pipx and personally prefer to just skip the .toml and place the whole pyprojectsetup in setup.py.

With that method, I would write inside setup()

packages=find_packages()  # Include every python packages
package_data={  # Specify additional data files
    'yourpackagename': [
        'config/*'
        etc...
    ]
}

This would however require you to have a package folder which all your package files/folders are inside, meaning the top level repo folder should not have any files or other folders that you want to distribute. Your MANIFEST.in looks fine.

deleted by creator

deleted by creator

Might as well start with a solid foundation from the start though. The extra work is minimal so there isn’t much of a time cost to it. I wouldn’t call it overengineering, it’s just a different way to write code, and the way many naturally default to without really thinking about it.

I get the point the author is coming from. When I was teaching first year engineering students programming, the one on the left is how everyone would write, it’s simply how human intuitively think about a process.

However, the one on the right feels more robust to me. For non trivial processes with multiple branches, it can ugly real quick if you haven’t isolated functionalities into smaller functions. The issue is never when you are first writing the function, but when you’re debugging or coming back to make changes.

What if you’re told the new Italian chef wants to have 15 different toppings, not just 2. He also got 3 new steps that must be done to prepare the dough before you can bake the pizza, and the heat of the oven will now depend on the different dough used. My first instinct if my code was the one on the left, would be to refactor it to make room for the new functionality. With the one on the right, the framework is already set and you can easily add new functions for preparing the dough and make a few changes to addToppings() and bake()

If I feel too lazy to write “proper” code and just make one big function for a process, I often end up regretting it and refactoring it into smaller, more manageable functions once I get back to the project the next day. It’s simply easier to wrap your head around

bakePizza() 
box()```
than reading the entire function and look for comments to mark each important step. The pizza got burned? Better take a look at `bakePizza()` then.

All it took for me to switch to GitLab was a larger free lfs quota which I wanted for a project. The superior webpage UI made me migrate every old project to it too.

I assume you meant that both Rust and C compiles into machine code? Python compiles into bytecode that is then run in a VM, Rust and C usually doesn’t do that as far as I know.

I was mostly curious if it was as easy as in C. Turun’s reply answered that question though. Cheers.

Interesting stuff, might give me an excuse to look into rust in the future. Thanks!

As others have suggested, ffmpeg is a great cli tool. If you aren’t comfortable with the terminal you can do it via python like this:

import os
import sys
import subprocess


def crop_media(file_name: str, w: int, h: int, x: int, y: int, new_dir: str) -> None:
    try:
        subprocess.run(f'ffmpeg -i "{file_name}" -vf "crop={w}:{h}:{x}:{y}" temp.gif -y',
                           shell=True, check=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
        os.rename('temp.gif', os.path.join(new_dir, file_name))
    # Print the error and continue with other gifs, remove try block if you want a complete stop
    except subprocess.CalledProcessError as e:
        print(e)
    except KeyboardInterrupt:
        print('KeyboardInterrupt, cleaning up files...')
        os.remove('temp.gif')
        sys.exit(0)


def crop_directory(directory: str, w: int, h: int, x: int, y: int, new_dir: str) -> None:
    for root, _, files in directory:
        for file in files:
            if not file.endswith('.gif'):
                continue
            if os.path.isfile(os.path.join(new_dir, file)):
                print(f'{file} already exists in {new_dir}, skipping...')
                continue

            file_path = os.path.normpath(os.path.join(root, file))
            crop_media(file_path, w, h, x, y, new_dir)


if __name__ == '__main__':
    width = 0
    height = 0
    x_offset = 0
    y_offset = 0
    gif_directory = ''
    new_directory = ''
    crop_directory(gif_directory, width, height, x_offset, y_offset, new_directory)

This should go through every file in the directory and subdirectories and call the ffmpeg command on each .gif. With new_directory you can set a directory to store every cropped .gif. The ffmpeg command is based on johnpiers suggestion.

The script assumes unique filenames for each gif and should work with spaces in the filenames. If they aren’t unique, you can just remove the new_directory part, but you will then lose the original gif that you cropped.

Could you elaborate on that point? Is it as smooth as using C?

But I think that both are useless because you can put what you want in a list in python.

You can say that about all type hinting, but assuming you actually adhere to the type hints, it’s a great tool to make python projects manageable.

Tabs work fine, you aren’t allowed to mix, indentation must be consistent.

It’d honestly the funniest thing I’ve read on this instance. Puts programmer humour to shame. Love it when developers finds the jankiest/unconventional way to solve problems.

Clean code would have indentation though, and you can use whatever space you want as indentation. Bonus points if you use tabs so that others with special needs can configure the tab length on their end.

And I don’t think I’ve encountered an indentation error since the day I learned the language. How often do you encounter that error when writing python scripts? Sounds more like a theoretical problem than something anyone used to python would encounter.

I’ve never understood the complaint about forced indentation. What kind of monster doesn’t use indentation for their code anyway?

If anything, it’s nice that the language forces it on you so that you don’t stumble on code written by one of those monsters.