dmulholl / shortcodes

A customizable shortcode parser in Python.

Shortcodes

A Python library for parsing customizable WordPress-style shortcodes.

• Documentation

shortcodes's Issues

Python 2.7 support

Would it be possible to support Python 2.7? I know it's almost deprecated, but there is some stuff running on it, and I can't imagine it being too hard to do using the six module...

How does this called the registered functions?

Seems to have a missing step. Tried using it in django with the tags in a functions.py but the register doesn't seem to work or pick up the tags

Feature Request: Processing the outermost shortcode first?

Hi,

First, thank you for making such a great library! It is the backbone of the Unprompted templating language for Stable Diffusion.

It has proven itself both flexible and reliable, however there is one limitation I've had to carefully work around: the inability to process an outermost shortcode first.

My project has evolved into a pseudo-programming language with conditional shortcodes like [if] and [switch] that, by design, must defer or outright skip processing of inner content.

Assuming this isn't already possible, I was hoping you could point me in the right direction for implementing such a change. I understand if it's not something you would implement yourself--my use case of the library is definitely unusual--but I'd appreciate your thoughts. Is it something that could be added without inverting the entire flow of parse()?

Thanks!

How does this called the registered functions?

Seems to have a missing step. Tried using it in django with the tags in a functions.py but the register doesn't seem to work or pick up the tags

Non-ASCII text is broken

The decode_escapes() function breaks non-ASCII text. For example, decode_escapes('ü') returns 'ü'.

Tested on Python 3.6.3 on Ubuntu Linux.

don’t intercept exceptions in AtomicShortcode and BlockShortcode

hi,

first and foremost: thank you for working on this library.

while looking at the code (and integrating it into one of my django apps) i noticed that you except any kind of exception in AtomicShortcode and BlockShortcode with no possibility to opt-out from this behaviour.

imho you should’t catch exceptions at all at this point. in fact the way you handle them now even hides SyntaxError exceptions. in my case i wanted to raise a specific exception that is handled by one of the django middlewares. this is impossible because the exception in my shortcode is already handled by the render function in AtomicShortcode. all i have now is a RenderingError that doesn’t help much :).

i see a few options for resolving this:

• don’t catch exceptions in AtomicShortcode and BlockShortcode
• allow users to configure the behaviour when registering the shortcode
• expose a custom exception class that users can subclass and that is ignored by your exception handler function

if you tell me which option you prefer i may be able to submit a pull request :).