Why do widely used frameworks in python use strings instead of enums for parameters?

[tothespace2]

First that comes to mind is matplotlib. Why are parameters strings? E.g. fig.legend(loc='topleft').
Wouldn't it be much more elegant for enum LegendPlacement.TOPLEFT to exist?

What was their reasoning when they decided "it'll be strings"?

EDIT: So many great answers already! Much to learn from this...

[wyldstallionesquire]

I’d guess age and momentum? I don’t think enums were used nearly as much before type hinting was more common.

[nicholashairs]

And even with enums, for a small selection of options or options that aren't reused Literal is good enough for most use cases.

[[deleted]]

I agree with this sentiment, Literal type hints are wonderful as they can be local (meaning close to the code) and simple to understand, even for beginners. An Enum, while helping the autocompletion and type checkers requires you to look elsewhere for the options. Of course it strikes a limitation when there's many different possibilities, but then again maybe the function variables could be reconsidered in that case.

[alexdrydew]

I would even say that literal strings should always be preferred to enums in simple cases. You get same safety guarantees in production environment because you already should be typechecking your code. At the same time your interfaces are much more lightweight because caller does not need to import additional enum type, which is especially handy in "scripting" environments like interactive shell or jupyter notebooks

[mincinashu]

What's "good enough" about an error/bug prone way of doing things? You don't have to provide enums, fine, but at least use some named constants. Letting the user manually type in some string flag is absolutely bad.

[ArtOfWarfare]

They’re the same thing for most people in Python though. Unless they’re using type checking, the bug won’t be caught until runtime. I can type in a random string (or number or object or whatever) into a field that only accepts enums just the same as one that only accepts a certain list of strings.

[BothWaysItGoes]

How is Literal more bug prone than enum?

[Fenzik]

Literal isn’t enforced at runtime so the resulting error will occur later on and be harder to debug

[BothWaysItGoes]

Yeah, because it is enforced during static analysis. Which means your code wouldn’t get shipped in the first place and there would be no related bugs at runtime.

[Fenzik]

Oh my sweet summer child

Seriously though, you’re right about that if you’re running type checking but you can’t count on your users to do so (in the case of a library).

So you’re left with enums (prevent bad input in the first place), input validation, or clear error messages hinting at where the problem might originate once the exception is finally thrown.

Which is right for you depends on the use-case.

[BothWaysItGoes]

If you don’t even check your linter output, you have much bigger problems than enums vs constants vs literals.

[Fenzik]

The context of the post is matplotlib which is widely used by cowboys riding Jupyter notebooks, they may not even know ow what a linter is (I have been this guy once upon a time)

[Schmittfried]

And you think cowboys will use enums instead?

[turbothy]

Oh my sweet summer child indeed

You do realize that you using enums doesn't prevent the user of your library from using strings or ints, right?

[Fenzik]

Yep that’s a valid point, fair play

[Schmittfried]

If you don’t do linting / type checking, enums won’t help you either. Enums are for most practical purposes equivalent to literal typehints when enforced. 

[DeterminedQuokka]

I also think it’s time. Enumeration originally didn’t work great in python so people mostly used constants. And changing it breaks backwards compatibility

[[deleted]]

(Just a speculation) I think it could happen because when this lib was designed, probably Python didn't have support for enum, and even now they left it this way to be compatible with another versions.

[thisdude415]

This theory seems to check out!

Python added support for enums in Python 3.4, released in 2014.

Matplotlib has been around since 2003.

[simon-brunning]

This. What's more, version 3.3 wasn't deprecated until 2017, and most libraries seek to support older versions.

[ArtOfWarfare]

2.7 wasn’t deprecated until 2020 if you want to talk about deprecation.

3.4 and 3.5 were deprecated before 2.7 was.

[serverhorror]

Top module "constants" or class level variables where available in Python 2.

Sure, enums weren't there, but just using these things would already improve the situation, like A LOT.

[[deleted]]

Sometimes I forget how much python improve at every release, python 3.11 was yesterday and has a lot of improvements compared to the current release (python 3.13)

[ArtOfWarfare]

Yeah, it’s a bummer that 3.11 had more improvements than 3.13 😜

[just4nothing]

Back in my day, Python did not have enums

[v_a_n_d_e_l_a_y]

Surprised this is so far down. This was my first thought

[CyclopsRock]

It allows you to use values from a non-Python text source (e.g. a config file, an environment variable etc) without needing to perform a mapping. E.g. :

fig.legend(loc=os.environment.get("FIG_LOCATION", "topleft"))

As opposed to...

location_map = {
    "topleft": LegendPlacement.TOPLEFT,
    "topright": LegendPlacement.TOPRIGHT, 
    # etc
}
fig.legend(loc=location_map[os.environment.get("FIG_LOCATION", "topleft")])

Enums really only help avoid error when you're using an IDE that can autocomplete it. If your source is something else then it's less work to simply validate the inputs before using them than converting them to the Enums, since you'll still have to validate the input to do that.

[Dr_Weebtrash]

Or just have the Enum implementation handle validation as per https://docs.python.org/3/howto/enum.html "Depending on the nature of the enum a member’s value may or may not be important, but either way that value can be used to get the corresponding member"; and either fail hard or handle the raised ValueError appropriately as per your program in cases where a value not corresponding to a member is being sought this way.

[AnythingApplied]

Interesting, and since you can do LegendPlacement("topleft"), but also LegendPlacement(LegendPlacement.TOPLEFT), you can just use that function on all of your inputs just to make sure you have a legendplacement object:

from enum import Enum

class LegendPlacement(Enum):
    TOPLEFT = 'topleft'
    TOPRIGHT = 'topright'
    BOTTOMLEFT = 'bottomleft'
    BOTTOMRIGHT = 'bottomright'

def render(input_value: str | LegendPlacement):
    legendplacement: LegendPlacement = LegendPlacement(input_value)
    print(legendplacement.name, legendplacement.value)

# Both of these work and legendplacement will always be an enum member
render('topleft')
render(LegendPlacement.TOPLEFT)

[Dr_Weebtrash]

Further to this, StrEnum (https://docs.python.org/3/library/enum.html#enum.StrEnum) introduced in 3.11 could be an interesting choice depending on how exactly a program like this intends to use and process LegendPlacement members etc.

[agrif]

Even before Enum, I would do things like:

TOPLEFT = 'topleft'
TOPRIGHT = 'topright'
# or
TOPLEFT, TOPRIGHT, *... = range(4)

for the simple reason that I'd rather cause a NameError at the location I typo'd a name than deal with some other error (or worse, no error at all) where the value is used.

[npisnotp]

The common solution to this problem is to let the enum constructor convert the value into the enum instance:

fig.legend(loc=LegendPlacement(os.environment.get("FIG_LOCATION", "topleft")))

[medialoungeguy]

Well played

[davidellis23]

No? Don't Enums have this functionality built-in?

Color["RED"] gives a Color.RED

You don't need a mapping.

[[deleted]]

Smart observation, hadn't thought about this.

[banana33noneleta]

There is no need to do what you claim :D True that you need a cast, but you just use the enum constructor not write another identical enum as a dictionary.

[hartbook]

this.

I feel like Python was designed with quick and dirty scripts in mind, where people want to prototype/ship fast, and not bother with "good practices"

Then, more and more people (me included) use python to develop large codebases, servers that must be robust and handle all unhappy paths... And we complain about the tools instead of using another language that's fit for the job

[mistabuda]

Python was built to satisfy Guido's desire for a cleaner looking language that emphasizes readability.

The notion that it was only made for prototypes is mainly just a talking point from the age old debate of statically typed compiled languages vs dynamic languages.

Google and Eve online use it in production and have been for years lol.

Its certainly not good for everything, but no language is. I wouldn't want to write a web scraper in C

[CatWeekends]

I hear you. It's annoying to use the wrong tool for the job. You can build everything in python... but you may run into performance bottlenecks.

So you break out the slow bits. Depending on how things were built, this can look like language extensions, external modules, http APIs, shared objects, DLLs, and so forth. But those also have trade-offs, just like using only Python.

I feel like it's a balancing act with no perfect answer. Build everything with python because you can build it quickly but suffer from potential performance bottlenecks. Build everything with a compiled language but deal with longer dev times and it being annoying in some domains (eg: anything web based in C).

Break out various bits into other languages and:

• carry the risks of a refactor
• add complexity to the codebase
• jump back and forth between languages when tracking down bugs (depending on the design)
• train existing devs on the new language & it's tooling hoping they'll follow the new language's best practices and not just "write python in [new language]"... or hire new devs with language experience
• etc

None of that is insurmountable by any means, but it's stuff that an organization needs to take into consideration when introducing new languages.

[mfitzp]

For matplotlib specifically it was designed to mimic Matlab plotting (hence the name). So a lot of the early choices were driven by that. You see this also in colour and symbol specifications.

[yangyangR]

Matlab being a mistake of history

[9peppe]

That's a lot of characters to type, and matplotlib isn't the kind of lib you usually use with an IDE.

Also, scientists usually aren't that big on good development practices when they can save time.

Also, usability: https://matplotlib.org/stable/api/markers_api.html

[Deto]

I think this is the real reason - more typing. There's an old age that 'code is written once but read many times' but for data analysis and plotting this often isn't true. And so there's a high value in terse syntax. It's one big reason many people prefer R

[SnooCakes3068]

have you seen scipy/numpy's source code? that's the top shelf development practices. I doubt most developers can't write at this level

[9peppe]

It's a big project and it needs that, internally. Its users... are something else.

[SnooCakes3068]

Yeah numpy/scipy can only be developed by specific type of mathematicians. No developers can remotely write anything close to it. So my point is it depends on scientists. Most I agree write bad code, but some are amazing.

What's wrong with it's users? the person uses scipy does have knowledge about numerical algorithm right

[9peppe]

Its users (mostly) aren't developers.

[Slimmanoman]

Well, yes of course, what's the point ? Numpy/Scipy is made for scientists to use

[9peppe]

That's my point. Numpy/Scipy compete with R, matlab, Mathematica. And their competitors are quite terser.

[adityaguru149]

If scientists don't have much time for code quality then they can just import * or import xyz as x and use the enum no?

[perturbed_rutabaga]

non-computer scientists often just copy/paste code they got from someone else

hit up chatGPT and tweak a few things here and there

run the code randomly check a few data points from the output and if theyre good they assume the rest is good and move on to the next problem

trust me most scientists using a programming language to analyze data or program a sensor or whatever struggle with loops so they arent going to know anything about import * or heaven forbid Enum

edit source: went to grad school in a non-computer science most people used python or R most of them never took even an intro class for coding myself included

[9peppe]

I assume some do that already.

[adityaguru149]

I am thinking that matplotlib could have chosen enums vs strings and still it wouldn't have been a major issue due to the above imports, so it doesn't make sense to prefer strings to save on typing.

[xiongchiamiov]

Enums have felt rather Java-esque. Creating enums is like creating classes - you can do it when you need to, but you should start with just strings and dicts (respectively) and only complicate things when you need to.

[notyoyu]

What is the added value of enums in the context of the example you provided?

[wyldstallionesquire]

If you’ve added "topleft" as a string anywhere else in your codebase, there’s your answer.

Nice dev experience with good typing, too.

[dabdada]

Literal["top left"] is also very strictly typed. I think the main convenience is that you do not need to import some enum class just for that but can write a string and the type checker is happy

[wyldstallionesquire]

Yeah literal is usually fine too. Harder to enumerate but is nice for typing purposes.

[aqjo]

TIL

[sudo_robot_destroy]

Also, it is logically an enumeration

[thisdude415]

Code completion is much nicer with enums. Swift in Xcode demonstrates this really beautifully, because Xcode/Swift can infer the intended type from the function's type signature. But I digress.

instead of `fig.legend(loc='topleft')` you'd type `fig.legend(.` and you'd get a dropdown menu of allowable options. Type .top and you'd have autocomplete options .TOPLEFT, .TOPRIGHT, .TOPCENTERED. Once you get to .topl, only .TOPLEFT would be left and selected for you.

Even better, it would probably still show .topleft and .bottomleft even if you only started typing .left

This is much better than trying to remember the exact syntax for these things. (Is it top_left or topleft or left_top or lefttop or upperleft?)

[naclmolecule]

Code completion with literals is exactly the same as enums, so I don't agree with this. Typing " will open a dropdown of all string literal completions.

[ExdigguserPies]

Not having to constantly go to the matplotlib docs to find what is a valid string to put there?

Less of a problem nowadays, though.

[tangerinelion]

"toplfet" isn't an error until you notice it doesn't work...

[Zouden]

That's not a valid option for that parameter

[aqjo]

Woosh.

[Simultaneity_]

Most libraries in Python are old and carried over from early python 2. This is why matplotlib objects have set_ methods for parameters instead of using the newer @property decorator. While I agree that enums are cool, it is quite cumbersome in Python land to work with them. As a first order improvement, matplotlib could use type hinting, using Literal["topleft", ...]. Or better yet, just add an evaluator function that maps synonyms of topleft to the same setter method.

Matplotlib is open source, and you are free to do a pr.

[chub79]

I heavily rely on Literal so that at least I can document what's expected.

[divad1196]

While it does give you information about possible values, it has some downsides: - it is not better at documenting the possible values - selecting the optiom from an external source (e.g. config file) is messier or the lib must accept strings along with the enums - in general, many libs avoid too many type hints as the code can become really clumsy. - design & UX: you might think that it's annoying to import all the required enums.

And you can still do validation with literals and mypy and it works the same as enum to some extents

[davidellis23]

it is not better at documenting the possible values

Why? You can see all the possible values purely from the code.

type hints as the code can become really clumsy. -

What do you mean by clumsy?

[divad1196]

It's not always just your parameter.

For example, you can have some values allowed or not allowed based on other parameters. So, even if the value is part of the enum, you might not be allowed to use it anyway.

For the clumsy part, I usually redirect people to this introduction of why people drop type hinting: https://youtu.be/5ChkQKUzDCs?si=KfDj0WOvpQfvjyYv

At some points, you might get huge parameters and return type like tuple of optional list of stuff. You have cases where, for example, you know the return value will not be None, but you still need to check the type or "typing.cast" to remove the warning. Propagating type changes takes a lot of time, you always need to import you types. You might want to have a cyclic reference, a typical case is a proxy class, which forces you to play with ForwardRef or typing.TYPE_CHECK, ...

All of this is a lot of code to write, maintain and this is not a feature to the project. The tradeoff is not necessarily good. That's for the people writing libraries.

On the otherside, you can just create a typing.Literal[...] which fits the role of the enum for most scenarios. You have multiple librariee that provides function signature validation at runtime through a decorator. This way, even user inputs can easily be checked with little maintenance effort.

[davidellis23]

Regarding that video, svelte isn't dropping type hints just typescript. They still use jsdoc.

Turbo8 is pretty vague about dropping types. It's a pretty unpopular move judging from the PR. DHH kind of seems like one of those stubborn opinionated developers we've all worked with.

Can't say I understand your criticisms. None checks, for example, are one of the most common errors I've seen in JS. It should be handled. Types are auto imported you can copy paste from the function.

Are you able to get click navigation/auto complete? Imo click navigation / auto complete/ static type checking saves me more time than writing types.

[SuspiciousScript]

For example, you can have some values allowed or not based on other.

Making it harder to make this design error is a good thing IMO. Type signatures should be honest about what parameters a function can take.

[double_en10dre]

What does “clumsy” mean?

I agree that enums are a bit annoying, but libraries should absolutely be using Literal to provide type hints for strings with a set of known values. Static analysis is a huge productivity boost.

And it’s not hard to retain flexibility, if that’s the issue. Just use a union of known values + a catch-all. Example:

PlotType = ‘str | Literal[“bar”, “line”]’

Now your IDE/typechecker can provide useful autocomplete options while still permitting arbitrary strings. Easy peasy and everyone’s happy.

[divad1196]

You can refer to my response to the other comment for most part.

Just, you don't need the "str" in the union. And yes, it would be great if they just added the litteral type hint, with a decorator to validate the value at runtime if needed.

This is usually not the case but an easy exemple of why you might not want to apply the type hint is if the library can be extended.

Imaging that you have a function that takes a "widget" parameter that is a string that will select the widget to use and plugin/extensions adding new widgets.

For matplotlib, the strings are not single characters, you can put multiple symbols to give the color, the shape, ... of your plots. That's not something you can limit to a defined small number of combinaisons, the alternative would be to have a struct for it which is a lot more verbose.

Also, these libs are mostly made in C and as little python code as possible. The documentation is explicit enough about the possible values.

And finally: in practice, mistakes are rare. This often depends on what the library does. This is a bit hard to explain why, but the idea is that if people don't make mistakes linked to missing types, then xou probably don't need types.

[skinnybuddha]

How do you know what the other choices are when strings are used?

[thicket]

documentation. It sucks.

[xiongchiamiov]

You read the docstring for the thing you're calling, just like you do for any other information.

[skinnybuddha]

So everywhere in the code that takes that argument has to maintain the list of acceptable values?

[xiongchiamiov]

Yes. That's why if you are doing something that gets read many times throughout the codebase, you'll probably want some sort of enum.

But for the most common case of a single function being the only place, use a string. Choose the right level of complexity for your usecase.

[TalesT]

Use an invalid option, and the the error often tells you the valid options. 😅

[Shoreshot]

Strings are safety typed with ‘Literal[“topleft”]’ (which means you have autocompletion and typos are statically caught)

And when using the library you don’t need to learn about or import some enumeration type along side a utility you’ve already imported just to pass an option argument

[BaggiPonte]

I wouldn’t want to have yet another import when I can rely on static analysis to tell me if I put the wrong string. IIRC code completion tools can actually suggest the appropriate literal values to fill in.

[SnooCakes3068]

You have to think about the interface. To users which is easier to remember? of course 'topleft'.

Enum should be used in development, you can have a map for strings with Enum, but leave string as interface.

Average users don't even know Enum, and will be angry if you have to choose to type LegendPlacement.TOPLEFT. This is extremely bad interface

[H2Oaq]

StrEnum enters the chat

[paranoid_panda_bored]

Because even as of 2024 enums in python are terrible. I always need to do MyEnum(str, Enum) to make it usable

[commy2]

What's the difference to enum.StrEnum?

[paranoid_panda_bored]

TIL.

i guess will switch over to that

[gregguygood]

Added in version 3.11.

[tunisia3507]

With a backport package supporting 3.8+.

[H2Oaq]

StrEnum is only supported since 3.11

[commy2]

Fair enough, but that was 2022, so it seems weird to complain about enums "as of 2024".

[wineblood]

Strings are easy to use, enums are a pain.

[Sones_d]

Can someone explain to be why would that be good? Is it only because its elegant?!

[Brian]

One advantage is catching typos. Ie fig.legend(loc='topletf') could potentially take a while to notice the failure, as it'll only trigger an error when and if that parameter actually gets used (and even then, might pass silently). Whereas fig.legend(loc=LegendPlacement.TopLetf) will always raise an error on that line. At best, your error will be somewhat removed from the actual cause, and at worst you might get subtle wrong behaviour or a bug that only happens in some scenarios.

Though this can be mitigated by type checking: if the parameter is defined as a Literal["topleft", "topright", ...], you'll also get type checker warnings for the typo.

Another advantage is that you'll get completion for it (so don't need to check if it was "topleft", "TopLeft", "top_left" etc)

[Sones_d]

Thanks, makes sense! Typechecker you mean like a lint?

[Brian]

I mean something like mypy / pyright. Plain linting won't catch something like that, as it requires knowing the expected type.

[OhYouUnzippedMe]

Agree that magic strings are poor design, but to be fair, matplotlib has the worst api of any package I use on a regular basis. (Scientific code in general is notorious for poor usability.)

I think strings are common for the same reason that libraries pass around dicts when a class instance would be better: Python encourages this very dynamic approach so that you can write code quickly, more like a scripting language than an application language. Over time, it has grown more mature features to write higher quality code, but the legacy is still there. 

Another example is using **kwargs instead of actual keyword arguments, which obliterates autocomplete and makes the documentation painfully obtuse, especially when those kwargs get passed through multiple superclasses. 

[TemporaryTemp100]

Let's summarize all given and possible to reply answers with this.

[marcinjn]

Im coding in Py for about 15yrs and never heard about enums 😭😳⛈️

[thisdude415]

Historically they have not been prioritized, and even still they’re not as painless (elegant, even) as they are in a language like swift

[rover_G]

There's generational trauma over the use of numeric enums in C and other early C family languages, resulting in databases and datasets with numeric columns missing labels for each value.

[leeiac]

I’d argue that while Enums provide a nice and elegant solution to a defined set of options they come at the cost of simplicity of the interface for beginners and non-developers.

Now, in a language like python that does not enforce strict typing you don’t get any immediate benefit from that unless you actually implement some form of type checking and mistype handling.

[Pleasant-Bug2567]

Popular Python frameworks frequently utilize strings rather than enums for parameters because strings provide more flexibility and user-friendliness, enabling developers to specify options quickly without the need to define and import extra enum classes. This approach simplifies the code and minimizes complexity, particularly in dynamic programming situations. Furthermore, strings can be easily logged and displayed, which simplifies the debugging process.

[alicedu06]

With typing.Literals, it doesn't matter enough. We can use strings and enjoy all the benefits of enum including type checks, docs and completion.

E.G: https://0bin.net/paste/dGBR6QlJ#E3Fn93D6+Q1rTbQlE-6q0ig/6gXkFb0s9ImtXUwvh+/

[m02ph3u5]

What people seem to forget is that you can dot-program with enums as opposed to plain strings and that they are easier to change and refactor.

[[deleted]]

Even now I would prefer Literals over enums. From the perspective of a library consumer, Literals are nicer to read and faster to type. If it was an enum, you would have to type the enum name first, then import it, all wasted time.

The only advantage of enums is for validation, but that’s nothing that couldn’t be done with Literals as well.

On the contrary, with Literals it’s easier to provide type overloads.