• 0 Posts
  • 34 Comments
Joined 1 year ago
Cake day: July 7th, 2023
  • UlrikHD@programming.devtoPython@programming.dev•Problems parsing a string with pyparsing
    51·
    11 months ago

    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.

  • UlrikHD@programming.devtoPython@programming.dev•Unable to include data files in python package with setuptools.English
    21·
    1 year ago

    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.

  • UlrikHD@programming.devtoProgramming@programming.dev•Linear code is more readable
    2·
    1 year ago

    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.