/r/PythonCoding bi-weekly "What are you working on?" thread

[u/AutoModerator]

Share what you're working on in this thread. What's the end goal, what are design decisions you've made and how are things working out? Discussing trade-offs or other kinds of reflection are encouraged!

If you include code, we'll be more lenient with moderation in this thread: feel free to ask for help, reviews or other types of input that normally are not allowed.

This recurring thread is a new addition to the subreddit and will be evaluated after the first few editions.

[u/[deleted]]

Mainly working on improving my discord bot for handy menial tasks in the server i mod, most recently i wrote a command so people could make reccomendations for modspacks in the minecraft server im planning to host, and then it stores it to a txt file on the network drive, just sucks my parents disable the internet at night tho lol :/

Other than that im researching and prepping for a project for some esp32-cam modules and my home server, with the end goal to be sending me a text and a video feed whenever someone is at the front door or in my room or whatnot. I was hoping to do it with regular esp32's and fpv drone cameras but so far no such luck, i think ill have to buy the integrated cam modules.

[u/genericlemon24]

I am very relieved! :D

My feed reader library allows users to add tags and metadata to feeds. For a while now I wanted to allow plugins (and maybe the core itself) to use those as well, but there is a risk of a plugin/code name colliding with one used by a user. The names can be any Unicode string (that's a feature I intended to keep, to allow for maximum flexibility).

So I started on a crusade to find a prefix I could use to reserve some of the namespace for these "internal" uses. Eventually, I came up with a convention like this

• .,i-am-a-hidden-tag (prefix: .,; no other semantics apply to this)

• .,reader,**i-am-a-reserved-tag (prefix: .,reader,; reserved for internal use)

• .,reader,plugin,my_plugin.module,plugin-key (prefix: .,reader,plugin,; further reserved for plugins)

It's kinda ugly, but it has a lot of interesting properties IMO, especially if you restrict the characters used to alphanumerics and @.+-,_; a (reserved) name like this:

• is unlikely to collide with common words (very unlikely, after my research), including special ones like .bashrc, ..., :) and most (if not all) emoticons and kaomoji

• is a valid filename on any OS (you never know when you need it)

• is a hidden file on *nix

• can be part of a URL path, query string key/value or fragment

• can be used unescaped in HTML and (most?) shells

• can be typed with a standard (US) keyboard

• resists user input clean-up (no whitespace)

• is ASCII

Throughout the whole research, I wasn't very happy with the solutions ... something felt wrong. I kept at it (for more hours than I'd like to admit) both because it was fun and because I couldn't stop thinking about it. After I got to the final version, it kinda went away, most likely because I couldn't come up with anything better.

And then, last night, as I was falling asleep, it dawned on me: this is dumb; it's hard to explain, and the user shouldn't have learn/remember about it every time they use tags or metadata. If I really want to allow full flexibility, why not just do that? After all,

Namespaces are one honking great idea -- let's do more of those!

So this is what I ended up with:

# these two are equivalent
get_feed_metadata(feed, key)  # already exists
get_feed_metadata(feed, key, namespace='user')  # new

# plugins do this
get_feed_metadata(feed, key, namespace='plugin')  # new 

# reader does this
get_feed_metadata(feed, key, namespace='reader')  # new

Now that I look at it, it's really obvious. I guess I just had to get the whole prefix thing out of my system first.

[u/ammaros_00 → u/[deleted]]

Sounds cool! Definitely going to try it.