Skip to content

Add a document of 'best practices' on designing with traitlets - #957

Merged
Carreau merged 3 commits into
ipython:mainfrom
yuvipanda:tips
Jul 29, 2026
Merged

Add a document of 'best practices' on designing with traitlets#957
Carreau merged 3 commits into
ipython:mainfrom
yuvipanda:tips

Conversation

@yuvipanda

Copy link
Copy Markdown
Contributor

The Jupyter ecosystem uses traitlets a lot, but there's not a lot of 'design documentation' that tells you how to design your applications to use traitlets. This is the start that at least provides a collection of tips for folks

yuvipanda and others added 3 commits July 22, 2026 13:17
The Jupyter ecosystem uses traitlets a lot, but there's not
a lot of 'design documentation' that tells you how to design
your applications to use traitlets. This is the start that at
least provides a collection of tips for folks
@yuvipanda yuvipanda changed the title Add a document of 'tips' on designing with traitlets Add a document of 'best practices' on designing with traitlets Jul 24, 2026
@Carreau

Carreau commented Jul 26, 2026

Copy link
Copy Markdown
Member

A few notes:

  • It may seem obvious but this makes any classname and traitlets part of public API that can't be changed without breaking backward compatibility.

  • If you think come config will be useful by multiple classes you can actually create a empty superclass just with configuration option.

  • Traitlets can, load config from .py files, json files and from environment variable though this is opt-in in the app that need to load from env explicitely (all config have a APPLICATIONNAME_TRAIT_PATH=VALUE that is automatically exposed). But this can have security implication as thos could contain executable code.

  • register your configurables with the app to be shown when using --help and --help-all

  • Maybe think / speak about parents:

class MyLeaf(Configurable):
	...

class SuperFoo(Configurable):
    
	def __init__(self):
		self.leaf = Leaf(parent=self)



class UltraBar(Configurable):
    
	def __init__(self):
		self.leaf = Leaf(parent=self)

then

C.MyLeaf.values = ...
c.SuperFoo.MyLeaf.values = ...
c.UltraBar.MyLeaf.values = ...

Are all valid config options that apply in right context and can allow to avoid defining options with different names.

I would also add that it is tempting to add config options of everything, but it might be easier to rely on DottedObjectName and Instance, and usually just subclass in a config file to patch just what is needed, than to provide hooks for anything and everything

@yuvipanda

Copy link
Copy Markdown
Contributor Author

Ty @Carreau!

Does the PR as is feel valuble enough to merge?

@Carreau

Carreau commented Jul 29, 2026

Copy link
Copy Markdown
Member

Always, i thought you wanted to expand on it :-) merging

@Carreau
Carreau merged commit 6317a44 into ipython:main Jul 29, 2026
32 of 34 checks passed
@yuvipanda

Copy link
Copy Markdown
Contributor Author

ty ty @Carreau :) I appreciate the merge! I think all the ones in your comments are great, and I learnt a few things from there too (like env vars!)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants