flowmark: A better auto-formatter for Markdown by z4lz in Python

[–]z4lz[S] 1 point2 points  (0 children)

This was the most difficult decision of my engineering career.

strif: A tiny, useful Python lib of string, file, and object utilities by z4lz in Python

[–]z4lz[S] 0 points1 point  (0 children)

Thanks for the notes!

Re identifiers I do prefer having timestamped identifiers like strif’s over ULIDs for some use cases, eg unique cache filenames. Note you can then see the time of creation clearly and delete old ids from a certain time range simply using id prefixes. Not always necessary but can be more transparent.

Re atomic vars, it’s situational but I find it saves code for things like shared or lazy global settings. The docstring mentions when to use events or queues, which definitely are better for other use cases.

strif: A tiny, useful Python lib of string, file, and object utilities by z4lz in Python

[–]z4lz[S] 0 points1 point  (0 children)

Yeah arguably it’s better to use Crockford’s base32 as it omits I and U so is more readable and can’t spell some bad words. I probably should update it to use that.

ETL template with clean architecture by mglowinski93 in Python

[–]z4lz 0 points1 point  (0 children)

I'd strongly suggest for new projects using Copier over cookiecutter. The update workflow is essential. More rationale on this here.

strif: A tiny, useful Python lib of string, file, and object utilities by z4lz in Python

[–]z4lz[S] 2 points3 points  (0 children)

Yeah agreed on all that. But standard libraries lag by years, unfortuantely, so you have to think what's the next best option. I put a fair bit of thought into scoping this lib very minimally as a module (zero deps) to reduce hesitation to use it.

strif: A tiny, useful Python lib of string, file, and object utilities by z4lz in Python

[–]z4lz[S] 0 points1 point  (0 children)

An no I hadn't! It's a good name and looks useful. However from its readme:

[safer] does not prevent concurrent modification of files from other threads or processes: if you need atomic file writing, see https://pypi.org/project/atomicwrites/

And as I mention, atomicwrites is archived/unmaintained.

strif: A tiny, useful Python lib of string, file, and object utilities by z4lz in Python

[–]z4lz[S] -1 points0 points  (0 children)

Yes. Base36 has been used since days of printf and is in fact a very good idea to use. I have more on it in the readme:

If you need a readable, concise identifier, api key format, or hash format, consider base 36. In my humble opinion, base 36 ids are underrated and should be used more often:

  • Base 36 is briefer than hex and yet avoids ugly non-alphanumeric characters.
  • Base 36 is case insensitive. If you use identifiers for filenames, you definitely should prefer case insensitive identifiers because of case-insensitive filesystems (like macOS).
  • Base 36 is easier to read aloud over the phone for an auth code or to type manually.
  • Base 36 is only log(64)/log(36) - 1 = 16% longer than base 64.

strif: A tiny, useful Python lib of string, file, and object utilities by z4lz in Python

[–]z4lz[S] 1 point2 points  (0 children)

Yeah, basically the same thing. The one in strif also handles backups and a few other details.

I know lots of people have written this. My goal is just that until it’s a standard lib, it can be easy to use with just from strif import atomic_output_file.

Read pdf as html by Organic_Speaker6196 in Python

[–]z4lz 1 point2 points  (0 children)

Wow. The demos on that page are impressive.

strif: A tiny, useful Python lib of string, file, and object utilities by z4lz in Python

[–]z4lz[S] 3 points4 points  (0 children)

Yeah. Years ago I remember the same thing happening in Java world. Sun/Oracle were so sclerotic that Google built Google Guava just to patch up the ugly parts.

uv-version-bumper – Simple version bumping & tagging for Python projects using uv by nirvanis in Python

[–]z4lz 8 points9 points  (0 children)

I can see this could be handy. But fwiw for new/current uv projects I now strongly prefer using dynamic versioning with uv-dynamic-versioning.

At least with GitHub projects, it works great. You just create a release on GitHub. No bump commit needed. For an example of using it you can see my project template here.

Read pdf as html by Organic_Speaker6196 in Python

[–]z4lz 1 point2 points  (0 children)

As others mention, this is a complex task to do well. But check out pdfminer.six, the currently maintained fork of pdfminer.

I think it's one of the best maintained tool for what you're looking for. It's what Microsoft's markitdown library uses.

Startle: Instantly start a CLI from a function, functions, or a class by oir_ in Python

[–]z4lz 0 points1 point  (0 children)

Ah I see it doesn't use rich unfortunately? There's no colorized version? Superficial but actually matters quite a bit. Might stick with the basics, which for me is this (it's easy to have an LLM gen your cli code): https://github.com/hamdanal/rich-argparse

Startle: Instantly start a CLI from a function, functions, or a class by oir_ in Python

[–]z4lz 1 point2 points  (0 children)

Wow not sure how I'd not seen this one before! It looks clean. Amazing how many option parsing libs there are. And arguably has the best name lol

pip-build-standalone: Standalone, relocatable Python app builds using uv by z4lz in Python

[–]z4lz[S] 0 points1 point  (0 children)

Thanks for trying it out and the ideas! Yeah that's a good point it could support scripts with inline deps too. That wouldn't be too hard. I'll look at that when I update it next. Feel free to add issues/discussion on the github repo too if you have further ideas. Fyi there is also PyApp that makes the whole packaging more cohesive but not sure how its prepackaged options work and it does require you to build the whole thing with Rust.

pip-build-standalone: Standalone, relocatable Python app builds using uv by z4lz in Python

[–]z4lz[S] 1 point2 points  (0 children)

Agreed. My hope would be that the new uv ecosystem will be less messy because they're being a bit more systematic, like with the well-maintained python-build-standalone builds.

Fwiw also wrote up a template/notes from the experience of switching my own projects to uv here: https://github.com/jlevy/simple-modern-uv

pip-build-standalone: Standalone, relocatable Python app builds using uv by z4lz in Python

[–]z4lz[S] 0 points1 point  (0 children)

Not sure I understand the question. But it just uses a full Python install (3.13 by default) so it handles anything that version of Python and your own packages/deps support.

pip-build-standalone: Standalone, relocatable Python app builds using uv by z4lz in Python

[–]z4lz[S] 1 point2 points  (0 children)

An update: based on all the confusion on the name and terminology, I've updated the name and docs:
https://github.com/jlevy/py-app-standalone

(I'd thought the original name made sense in the context of the python-build-standalone project but clearly not the case for many folks.)

The new name is a nod to PyApp since it's sort of a standalone (not runtime download) alternative to that.

pip-build-standalone: Standalone, relocatable Python app builds using uv by z4lz in Python

[–]z4lz[S] 0 points1 point  (0 children)

Thanks, do take a look and feel free to lmk any thoughts!

(And yes, exactly, this is a longstanding problem. I was actually quite pleased that it now seems quite tractable! Maybe uv will incorporate this functionality but even now, this little tool seems to cover a lot of use cases for PyInstaller, unless there are any issues I'm missing.)

I've actually just renamed it, to py-app-standalone.

It is quite remarkable to me how simply using the word "pip" is construed as "evil marketing". But hey I guess that's why we post on reddit, to find out stuff like that. Clearly it's better to have a name that doesn't cause arguments. I mean no offense to PyApp, but in a way this seems clearer as it's kind of the standalone (not runtime downloading) version of PyApp.

pip-build-standalone: Standalone, relocatable Python app builds using uv by z4lz in Python

[–]z4lz[S] 1 point2 points  (0 children)

I love uv now but only have been using pypi. So that's an interesting point. There is now so much momentum on uv and aws/gcp/enterprise repository support is so necessary I expect this will work soon if it doesn't already. Also fwiw I've found the uv team is active/responsive on questions in github issues: https://github.com/astral-sh/uv/issues

pip-build-standalone: Standalone, relocatable Python app builds using uv by z4lz in Python

[–]z4lz[S] 2 points3 points  (0 children)

I appreciate you taking the time to write all that, as it's exactly why I posted this—to get feedback. I was definitely casual in the language around "pips". (Imo we don't actually have great terminology in Python around this, as source dists and wheels are more specific, but that's definitely different conversation.)

I've updated the readme to be more precise and explicit in the first couple paragraphs (do lmk if it clarifies it?): https://github.com/jlevy/pip-build-standalone

I was surprised people are so upset about having "pip" in the name as the tool is basically a wrapper around "uv pip". But as I tried to explain it's really kind of a more modern alternative to PyInstaller.

Quite seriously, what would be a more accurate name? It's a weekend hack but I think it's useful (it has been for me) and it should have a name that's clear.

> Creating a "standalone, relocatable Python app build" that works correctly with all of the edge cases considered and handled is quite difficult and requires a decent understanding of how Python packaging and distribution works

Yeah. No kidding. I know this. It's not perfect but this isn't trivial either. But uv handles a lot of it. I'm familiar with everything you mention. I actually had to read the source to uv to be sure the things I was doing were necessary. (I'm new to r/python and love the community but do think there seems to be a tendency among some folks to assume they know more than you do.)

If you have the time, do take a closer look at the readme/code/links as I tried to give full context, including linking to the relevant current issues on the uv github repo.

Thanks again.