feluxe / sty

String styling for your terminal.

---

Release 1.0.6 (November 27. 2023)

Code Changes:

• Use PEP-484 compatible exports to satisfy static type checkers.

Release 1.0.5 (November 22. 2023)

Code Changes:

• Add py.typed file for better typing support. Thanks! @Eisfunke
• Use explicit imports: from .lib import is now from sty.lib import.
• More and better doc-strings. help(x) should be much more useful now.

Other:

• Add svg logo. Thanks! @kubinka0505
• Replace pipenv with poetry.
• Remove make.py build system.
• Remove all dev dependencies.

Description

Sty's goal is to provide Python with a simple, customizable and performant string styling markup, which is decoupled from color palettes and terminal implementations.

• Sty supports 3/4bit, 8bit and 24bit (truecolor/RGB) colors as well as effects like bold, italic, underline, etc.
• Sty should work on most Unix platforms with most terminals. It works with recent Windows terminals. Window legacy terminal (cmd) needs a shim to work.
• Sty comes with default color palettes and renderers, but you can easily replace/customize them, without touching the markup in your code.
• Sty allows you to mute/unmute all styles in your codebase.
• Sty provides high access performance for all styling rules.
• Sty is fully typed, you should get good editor support for it.
• Sty does not implicitly mess with globals. E.g.: colorama overrides sys.stdout which causes a lot of trouble.
• Sty has no dependencies.
• Sty follows semver.
• Sty will support Python >=3.7 for as long as possible.

If you run into compatibility problems with sty, please file an issue!

Code Example

from sty import fg, bg, ef, rs

foo = fg.red + 'This is red text!' + fg.rs
bar = bg.blue + 'This has a blue background!' + bg.rs
baz = ef.italic + 'This is italic text' + rs.italic
qux = fg(201) + 'This is pink text using 8bit colors' + fg.rs
qui = fg(255, 10, 10) + 'This is red text using 24bit colors.' + fg.rs

# Add custom colors:

from sty import Style, RgbFg

fg.orange = Style(RgbFg(255, 150, 50))

buf = fg.orange + 'Yay, Im orange.' + fg.rs

print(foo, bar, baz, qux, qui, buf, sep='\n')

The code above will print like this in the terminal:

You can use the Register class or the default registers FgRegister, BgRegister, EfRegister and RsRegister to create your own registers:

# Extending the default FgRegister

from sty import FgRegister, Style, RgbFg, Sgr

class MyFgRegister(FgRegister):

    def __init__(self):
        super().__init__()

        self.purple = Style(Sgr(35))
        self.blue = Style(Sgr(34))
        self.orange = Style(RgbFg(255, 128, 0))
        # ...

 fg = MyFgRegister()

Documentation

Documentation-Website: https://sty.mewo.dev

Documentation-Website-Source: https://github.com/feluxe/sty-docs

sty's Issues

Doesn't work in MacOS terminal

I have got this working in the terminal in VSCode, but it doesn't work in the built-in MacOS terminal app... How do I get this working?

Support for Python 3.5

I know it is probably too late for this specific feature request, but I wanted to give a friendly feed back anyway:

Assuming that sty is a library that may be used by tool-builders, a dependncy on Python 3.6+ imposes this restriction to those tools as well.
Given that Python 3.5 has an EOL of 2020-09-13 and will probably remain in the wild a bit longer, this makes it harder to to use sty to create a tool that covers all living environments.
I fixed it by wrapping sty with a no-op fallback in this case.

I assume that 3.6 was required in order to use variable annotations, which is a cool feature internally.
However in my opinion it would have been be a better option to have a sty v1.x that supports Python 3.5..3.8 and then drop 3.5 support with sty v2.x.

As I said, may be too late to change this now, but you might consider this in the future?

N.B.
I find the Sty requires Python >= 3.6 a bit hidden, it would be nice to have this more prominent on the front page.
And maybe add the trove classifiers to setup.py

    Programming Language :: Python :: 3.6
    Programming Language :: Python :: 3.7
    Programming Language :: Python :: 3.8

[Suggestion] Text width (string length without sequences).

Yours lib is awesome, I used it for years.
Now I have a little problem, a have fine formatting and print table separated.

Is any way to find printable text width to calculate table cell width?
If not I suggest add a function to count length of the text without sequences.

Of course I can add some regex to transform text before taking its length but it'll be nice to have it out of the box.

---

EDIT: some example

rx_omit_sequences = re.compile(r'(?:\033\[|\x9b)[0-?]*[!-/]*[@-~]')

def text_width(s: str) -> int:
    return len(rx_omit_sequences.sub('', s))

s = f'{fg.red}This is red text!{fg.rs}'
print('-' * len(s))
print(s)
print('-' * text_width(s))

CHANGELOG

Subscribe to this in order to get notifications for changes in sty.

Printing a Colour gives a Numeric Prefix instead of Coloured Text

Hey there,

I'm trying to run the following line within my Py Project:

print(fg(141) + 'HWID Check Failed! Please reset your bound HWID and try again!' + fg.rs)

However, upon execution, the following is printed to my Console:

←[38;5;141mHWID Check Failed! Please reset your bound HWID and try again!←[39m

I've tried running this within Git Bash inside of VSC, as well as in Powershell, but cannot get it to work. Would anyone happen to know why?
If you need any other information just reply and I'll be more than happy to reply!

Kind Regards,
James

Assigning RGB colors doesn't work in macOS Mojave default terminal.

I tried the proposed way of assigning colors, but it gives grey font regardless of the rgb values.

from sty import fg, bg, ef, rs, Rule, Render

fg.orange = Rule(Render.rgb_fg, 15, 15, 15)
print(fg.orange, end="")
print("aaa")

print(rs.all, end="")

As seen in the picture, this line:
b = bg(50, 255, 50) + 'Text with green bg' + rs.bg # select a 24bit rgb color directly.
also doesn't work and changes font color to grey.

Simple way to mute colors

I am building a command line program and I want a quick way to be able to ignore all of these color strings with a config variable. any ideas?

Add performance tests

Just add some basic access performance tests.

Not working in windows 10

I tried the example codes in python3 running in my cmd in windows 10 but it doesn't print the string which I have mentioned as show n in the screenshot. Kindly find a solution for this!!

Move documentation into its own repo.

Currently Sty's documentation website resides within the source repo. This pollutes the commit history quite a bit.

The documentation website should be moved into a separate repo and the commit history should get cleaned up.

100% typed

Add missing type annotations...

HTML colors support

I know it can be converted somehow, but please introduce HTML colors conversion support if possible.

from sty import HTMLfg, fg

# CSS "red" 
# HEX "#FF0000"
# RGB (255, 0, 0)
print(HTMLfg(0xFF0000) + "Red")

# CSS —
# HEX "#A0A0A0"
# RGB (160, 160, 160)
print(HTMLfg("#A0A0A0") + "Gray")

# CSS "white" 
# HEX "#FFFFFF"
# RGB (255, 255, 255)
print(HTMLfg("#FFF") + "White")

# CSS "orange"
# HEX "#FFA500"
# RGB (255, 165, 0)
print(HTMLfg("orange") + "Orange")

print(fg.rs)

Install on Python 3 doesn't work

when i install and import this library in my python 3 script i gets the error:

Traceback (most recent call last):
  File "install_modules_in_project.py", line 24, in <module>
    from sty import fg, bg, rs
  File "/usr/local/lib/python3.5/dist-packages/sty/__init__.py", line 3, in <module>
    from sty.register import ef, fg, bg, rs
  File "/usr/local/lib/python3.5/dist-packages/sty/register/__init__.py", line 1, in <module>
    from sty import renderer, primitive
  File "/usr/local/lib/python3.5/dist-packages/sty/renderer/__init__.py", line 19
    return f'\x1b[38;2;{str(rgb[0])};{str(rgb[1])};{str(rgb[2])}m'
                                                                 ^
SyntaxError: invalid syntax

Remove deprecated items from code.

Remove deprecated items such as Register.get_style() and Register.set_style()

Move docs from README to some static site generator.

Something like readthedocs.

Double is_muted

Could explain me why is_muted is declared twice?
First time in class Base (as class property), second time in object dict?

from sty import ef
print(f'class mute: {type(ef).is_muted}, object mute {ef.get("is_muted")}')
mute(ef)
print(f'class mute: {type(ef).is_muted}, object mute {ef.get("is_muted")}')

class mute: False, object mute None
class mute: False, object mute True

Option to autoReset in new write

This would be like colorama's init(autoreset=true)
Every time a new line is written, reset the colors and effects to default.

This should be pretty easy.
In my code i just used write(rs.all) after every sys.stdout output.

Add "examples" directory to provide some basic code examples.

examples_old.py tries to import method "Rule" which doesn't exist anymore. Is there a replacement or a working example.py?
Thanks for a hint,
Helmut

Colors messed up in the Gnome Terminal (Ubuntu 22.04.4 LTS)

Running standard tests shows this

Especially, li_yellow colors!

SVG Logo

I don't know why there's none. Add if you want. 🙂

---

Default	Aliased

Bold reset not working

As shown below, rs.bold doesn't seem to be working.

colorama.init() breaks sty

I don't know how this can happen but look:

Using Window 10 and the Cmder terminal.

Some RGB colors not supported?

As a test, I wrote a short script to take a DNA sequence and render a colored equivalent of it:

#!/usr/bin/env python

import sys
from sty import bg, rs

bg.orange = bg(255, 150, 50)

classic = {
    'G' : bg.orange,
    'T' : bg.red,
    'U' : bg.red,
    'C' : bg.blue,
    'A' : bg.green,
}

be = rs.bg

for line in sys.stdin:
    line = line.rstrip().upper()
    for char in line:
        if char in classic:
            sys.stdout.write(classic[char] + ' ' + be)
    sys.stdout.write('\n')

Entering a sample sequence into standard input that contains G will return blank characters with no background color (e.g., ACGGAT). Standard output contains blank characters with the expected background color for the non-G characters.

Program stops running

I installed sty (Python), and then, as in the instructions https://sty.mewo.dev/intro/getting_started.html, I did everything, it works!
I edited my .py file, of course, errors could (should) have appeared, as a result - the program is not executed, I need to edit it, here I return the original version of my file, and ... it no longer works.
The pycache folder appears, some new file is in it, and nothing else works.
So what is this? How is this treated?

----- myfile.py -----
import os
os.system('color')
from sty import bg, ef, fg, rs
foo = fg.red + "red" + fg.rs
print(foo)
input("o")

Environments & Feature Sets

Environments & Feature Sets (Planning)

stycurrently supports features that don't work with some dated terminals, e.g. terminal.app (see #12, #14). There are other terminals that don't work with the common ANSI sequences, e.g. cmd, powershell. (see #2)

Feature Sets

If you are planning to support a wide range of terminals, it would be good if you could restrict sty to the features you are allowed to use.

With a del_styles_of_type function, you could, for example, remove rgb colors in order to support apple's terminal.app:

from sty import fg, RgbFg, RgbBg

fg.del_styles_of_type(RgbFg)
bg.del_styles_of_type(RgbBg)

This would remove attributes that use rgb colors from the default fg and bg register, restricting sty to the feature set of terminal.app.

If you don't want to support eightbit colors, you could use this:

from sty import fg, EightbitFg, EightbitBg

fg.del_styles_of_type(EightbitFg)
bg.del_styles_of_type(EightbitBg)

The code above would remove eightbit styles such as da_green, da_red, da_* from the default fg and bg register.

There could be a batch function to delete from multiple objects at once:

from sty import fg, EightbitFg, del_styles_of_type

custom_fg = fg.copy()
custom_fg.set_styles("orange", EightbitFg(214))

del_styles_of_type(EightbigFg, fg, custom_fg)

Environments

Configuration preset for common environments.

default Environment

The default environment enables you to use the full feature set of sty using the most common ANSI escape sequences. This is the environment which sty uses by default.

# Get default env register-objects.

ef, fg, bg, rs = sty.env.default()

# Or set default env globally (be careful with this).

sty.env.default(set_globally=True)

windows Environment

The windows environment uses windows specific ANSI sequences and allows only the features that work with cmd/powershell.

# Get windows compatible register-objects

ef, fg, bg, rs = sty.env.windows()

# Or set windows compatible register-objects globally (be careful with this).

sty.env.windows(set_globally=True)

In a real world app, you might call something like this in __init__.py of you application:

if platform.system() == 'Windows':
    sty.env.windows(set_globally=True)

Or better add a style.py to you project and use this:

if platform.system() == 'Windows':
    ef, fg, bg, rs = sty.env.windows()

Now you can import the registers from style.py, e.g.: from .style import ef, fg, bg, rs

[Suggestion] Underline styles and colors

What about underline styled (dotted, curly etc) and its colors?
I know it's an extension but supported by popular emulators, Kitty for example.
Underline colors are implemented in Kitty, VTE, mintty, and iTerm2.

I could prepare same pull request if you are interested.
Some preview.

BTW. What reason is using RgbFg/RgbBg and EightbitFg/EightbitBg instead of just Rgb and Eightbit?
They are keys in the *Register but never together.

BREAKING CHANGES

Subscribe to this in order to get notifications for breaking changes.

Fix pypi project description

The ReStructuredText of the README is not being rendered on pypi: https://pypi.org/project/sty/

Update Documentation to match beta 6 changes.

Shortcut Register

Suggestion for a Shortcut Register:

Version A

from sty import s

# Mix with fg red + bg blue + italic

s.red            # fg.red
s.red_i          # fg.red + ef.italic
s._blue          # bg.blue
s._blue_i        # bg.blue + ef.italic
s.red_blue       # fg.red + bg.blue
s.red_blue_i     # fg.red + bg.blue + ef.italic

# Mix with fg red + bg da_blue + italic

s.red
s.red_i
s._dblue
s._dblue_i
s.red_dblue
s.red_dblue_i

# Mix with fg red + bg li_blue + italic

s.red
s.red_i
s._lblue
s._lblue_i
s.red_lblue
s.red_lblue_i

# resetters

s.rs_all    # rs.all

s.rs        # rs.fg
s.rs_i      # rs.fg + rs.italic
s._rs       # rs.bg
s._rs_i     # rs.bg + rs.italic
s.rs_rs     # rs.fg + rs.bg
s.rs_rs_i   # rs.fg + rs.bg + rs.italic

Result

# Shortcut version

a = f"{s.red_i}Hello World!{s.rs_i}"
b = f"{s.red_blue_i}Hello World!{s.rs_rs_i}"

# Default version

a = f"{fg.red}{ef.i}Hello World!{fg.rs}{rs.i}"
b = f"{fg.red}{bg.blue}{ef.i}Hello World!{fg.rs}{bg.rs}{rs.i}"

Contra

Limited Composability

The composability of this implementation is somewhat limited. E.g. what if you need a string with: fg.red + bg.blue + ef.i + ef.b?

You would end up with this s.red_blue_i + s.b

A solution for this would be Version B.

Version B

Fixes composability issue of Version A.

s.red + 'foo' + r.fg                   # fg.red
s.red.i + 'foo' + r.fg.i               # fg.red + ef.i
s._.blue + 'foo' + r.bg                # bg.blue
s._.blue.i + 'foo' + r.bg.i            # bg.blue + ef.i
s.red.blue + 'foo' + r.fg.bg           # fg.red + bg.blue
s.red.blue.i + 'foo' + r.fg.bg.i       # fg.red + bg.blue + ef.i
s.red.blue.i.u + 'foo' + r.fg.bg.i.u   # fg.red + bg.blue + ef.i + ef.u

Result

# Shortcut version

a = f"{s.red.i}Hello World!{r.fg.i}"
b = f"{s.red.blue.i}Hello World!{r.fg.bg.i}"
c = f"{s.red.blue.i.u}Hello World!{r.fg.bg.i.u}"

# Default version

a = f"{fg.red}{ef.i}Hello World!{fg.rs}{rs.i}"
b = f"{fg.red}{bg.blue}{ef.i}Hello World!{fg.rs}{bg.rs}{rs.i}"
c = f"{fg.red}{bg.blue}{ef.i}{ef.u}Hello World!{fg.rs}{bg.rs}{rs.i}{rs.u}"

Pro

Less verbose

It's less verbose and it looks very clear.

Better access performance

a is more than twice as fast as b:

a = f"{s.red.blue.i}foo{r.fg.bg.i}foo"  # 5.7 Sec

b = f"{fg.red}{bg.blue}{ef.i}foo{fg.rs}{bg.rs}{rs.i}foo"  # 12.3 Sec

Contra

Complicated (implementation)

Making this compatible with sty could be complicated and may require deep changes. Implementing this without loosing customizability and editor support can be tricky.

Implementation (sketch)

This implementation is able to parse the example above:

from sty import ef, fg, bg, rs 
from collections import UserString



class Shortcut():

    def __init__(self, fg, bg, ef):

        class Ef(UserString):
            def __init__(self, seq, i=0):
                if i > 5:
                    return
                super().__init__(seq)
                self.i = Ef(self.data + ef.i, i+1)
                self.u = Ef(self.data + ef.u, i+1)
                self.b = Ef(self.data + ef.b, i+1)
                # ...

        class BgEf(UserString):

            def __init__(self, seq):
                super().__init__(seq)
                self.red = Ef(self.data + bg.red)
                self.blue = Ef(self.data +bg.blue)
                self.green = Ef(self.data +bg.green)
                self.i = Ef(self.data + ef.i)
                self.u = Ef(self.data + ef.u)
                self.b = Ef(self.data + ef.b)
                # ...

        self._ = BgEf('')
        
        for k, v in {**fg, **ef}.items():
            if k not in ['eightbit_call', 'rgb_call']:
                try:
                    setattr(self, k, BgEf(fg(k)))
                except KeyError:
                    setattr(self, k, BgEf(ef(k)))


class ShortcutRs:

    def __init__(self, rs):

        class Rs(UserString):
            def __init__(self, seq, i=0):
                if i > 5:
                    return
                super().__init__(seq)
                self.fg = Rs(self.data + rs.fg, i+1)
                self.bg = Rs(self.data + rs.bg, i+1)
                self.i = Rs(self.data + rs.i, i+1)
                self.u = Rs(self.data + rs.u, i+1)
                self.bold_dim = Rs(self.data + rs.bold_dim, i+1)
                # ...


        for k, v in rs.items():
            setattr(self, k, Rs(v))


s = Shortcut(fg, bg, ef)
r = ShortcutRs(rs)

pipenv not working

This may be a user error, but pipenv does not seem to recognize the beta suffix in sty versions. Do you have a work around for this?

$ pipenv install sty
Installing sty…
Looking in indexes: https://pypi.python.org/simple
Collecting sty
  Using cached https://files.pythonhosted.org/packages/38/8f/f37f3a9b3010343cfd43384dc0b262e12d18729e26aa0eabc8aaab7d50d8/sty-1.0.0b8-py3-none-any.whl
Installing collected packages: sty
Successfully installed sty-1.0.0b8

Adding sty to Pipfile's [packages]…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Could not find a version that matches sty
Tried: (no version found at all)
Please check your version specifier and version number. See PEP440 for more information.
Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Could not find a version that matches sty
Tried: (no version found at all)
Please check your version specifier and version number. See PEP440 for more information.

Background colors leak through to end of line on multilined text

In Python on Mac OS 12 (zsh), while doing

print(bg.blue + "some long line of text" + bg.rs)

if "some long line of text" wraps to the next line in the terminal (say because the text hits the right edge of the terminal after "of"), then in the second line, the blank space after "text" will also be background-colored through to the right edge of the terminal window.

I can sorta fix it by doing

print(bg.blue + "some long line of text" + bg.rs + "\033[0m\033[K")

but it's unclear if this will work in all environments.

Implement rs.bold, rs.b and rs.dim in addition to rs.bold_dim and rs.dim_bold

Sty uses rs.bold_dim and rs.dim_bold over rs.bold and rs.dim for the following reason:

The ANSI "SGR (Select Graphic Rendition) parameters" which are used by terminals, do not allow resetting bold and dim separately, there is only parameter 22 which resets both bold and dim. That means we cannot implement a resetter in sty which allows a user to reset bold only or dim only. When I implemented the resetters for bold and dim I decided to make this explicit, thus we have rs.bold_dim / rs.dim_bold. I chose explicitness/correctness over beauty.

After I read #41 I decided to create this ticket and leave it open for discussion if rs.bold, rs.b and rs.dim, should be added, even with the shortcomings (described above).

I wrote down the pros/cons for both options.

A) Only offer rs.bold_dim / rs.dim_bold (as implemented right now)

• PRO: It's explicit. It describes exactly what happens. No confusion in situations where a user wants to reset bold but not dim or vice versa.
• CON: As #41 indicates, it may still be confusing for people, because it looks strange.
• CON: It's really ugly and verbose.

B) Add rs.b / rs.bold / rs.dim and make it very clear in the docs, that each flag always resets both bold and dim.

• PRO: Consistent with the rest of the interface.
• PRO: Intuitive: open with ef.bold, close with rs.bold.
• PRO: Beautiful and non verbose. rs.b vs rs.bold_dim.
• CON: It can be really nasty, confusing, time consuming for a user who wants to reset bold bot not dim or vice versa.

Right now I'm thinking, maybe B) is the more pragmatic solutions because:

• The situation in which a user wants to reset bold but not dim and vice versa, might be very rare and the pain from that may be smaller than the pain of all users who have to deal with bold_dim / dim_bold.
• It's frontend/styling code, which is not critical, so we can go with beauty over correctness.

I'm not sure about this, since there will be pain either way ;-)

I'd love to hear your opinios! You can also use the next two comments to vote for A) or B).

Shortcuts module to easy use

Hello. With string interpolation on Python3.6 it's really easy to use colors with print, but it may be even less verbose, even if it's much better than colorama in that way.
Maybe it will be good choice to support some shortcuts module?
For example,

import sty.shortcuts as f
print(f'Hello, {f.bred}hello{f.rs}')

f.bred = ef.b + fg.red
f.ured = ef.u + fg.red
f.ired = ef.i + fg.red,
f.rs = rs.all
f.xgreen = bg.green

I mean - I understand that we're talking about couple less symbols, but it would be very cool when you're hard working with colored output, plus - we have only one var in namespace.

Add "not messing with globals" goal to docs

There are styling libraries such as colorama which seem to implicitly mess with globals such as sys.stdout. (See: #15 #43). I really don't like this. No function should ever implicitly mess with something like sys.stdout...

I'll add it as a goal for sty:

• Sty does not implicitly mess with globals. E.g.: colorama overrides sys.stdout which causes a lot of trouble.

Inconsistent documentation

Hi, thank you for making sty. I'm using Python 3.9 with sty 1.0.0rc1 and I use it extensively in my projects.

However, the documentation doesn't seem to be up to date.
Here it says rs.bold_faint / rs.faint_bold,
but the actual implementation provides rs.bold_dim / rs.dim_bold.

Moreover, what is the reason for not simply calling this one rs.bold?
This is confusing for me at least, and I find it ugly because it is not symmetric to ef.bold.

Have a great evening!

Add effect resetter `ef.rs`

Add ef.rs to the default register.

Change grey tones for the default register

You currently have this in the register for black, white and greys:

li_black = Rule(Render.sgr, 90)
black = Rule(Render.sgr, 30)
da_black = Rule(Render.eightbit_fg, 0)

li_white = Rule(Render.sgr, 97)
white = Rule(Render.sgr, 37)
da_white = Rule(Render.eightbit_fg, 249)

black and da_black render the same color...

I think a palette like this would make more sense:

black = Rule(Render.sgr, 30)
da_grey = Rule(Render.sgr, 90)
grey = Rule(Render.eightbit_fg, 249)
li_grey = Rule(Render.sgr, 37)
white = Rule(Render.sgr, 97)

More docstrings?

I often view documentation with help(foo), possibly more often than viewing documentation on websites.
Currently help(sty) doesn't offer much info, and usage like help(sty.ef) will display the inherited docstring from the base Register class instead of describing what ef can do.

Missing effect

Hey,

I tried the test example on my windows 10 machine. However, the results look like in the image: only the red-foreground option and the blue-background option show an effect.

Can somebody help?

Show wrong style when importing `tqdm`

Testcase:

import tqdm
from sty import fg, bg, ef, rs

foo = fg.red + 'This is red text!' + fg.rs
bar = bg.blue + 'This has a blue background!' + bg.rs
baz = ef.italic + 'This is italic text' + rs.italic
qux = fg(201) + 'This is pink text using 8bit colors' + fg.rs
qui = bg(255, 10, 10) + 'This is red text using 24bit colors.' + bg.rs

# Add custom colors:

from sty import Style, RgbFg

fg.orange = Style(RgbFg(255, 150, 50))

buf = fg.orange + 'Yay, Im orange.' + fg.rs

print(foo, bar, baz, qux, qui, buf, sep='\n')

after importing tqdm, the sty becomes invalid.

It is tested under the environment of python 3.7/3.10, Windows 10, and VS Code 1.6.2. However, I guess other environments are also ok to observe this error.

If tqdm is not imported, it display is right.

Could anyone figure out what's wrong with it and how to fix this bug?

Release please :)

Hi,

currently it seems that we have to install with --pre or add allow_prereleases = true to Pipfile if we bundle your library, which is a thing I generally try to avoid.

Since you are in beta for 2.5 years now, it may be about time for a release?
I don't see stoppers in the issue tracker, and bumping the major version later if you need to implement breaking changes later is no big deal either.

Thanks
Martin

colors not working correctly in macOS HighSierra default Terminal.app

Using fg(121, 2, 7), for example, leads to wrong colors appearing. For example, consider the input fg(246, 246, 246) + ' ' + fg.white + ' ' + '\n' + fg.white + ' ' + fg(253, 240, 239) + ' ' + fg(242, 139, 132) + '*' + fg(235, 76, 66) + '(' + ...

in Terminal.app (not working):

in iTerm2.app (working great):

Thanks. Using in conjunction with colorama. Let me know what other info you need.

Broken Python attribute protocol.

Hi.

It's a very nice module. Could you fix attribute protocol?
You have:

    __getattr__: Callable = dict.__getitem__
    __setattr__: Callable = dict.__setitem__
    __delattr__: Callable = dict.__delitem__

and now I have:

>>> from sty import ef
>>> print(getattr(ef, 'underline', ef.underl))
KeyError: 'underline'

__getitem__ should raise KeyError and __getattr__ should raise AttributeError.

I know, I can use item protocol (ef['underline'] or 'underline' in ef), but object should API be pythonic IMHO.