On 2024-09-21 at 06:38:05 +0100,
Barry via Python-list <python-list@python.org> wrote:

> > On 20 Sep 2024, at 21:01, Loris Bennett via Python-list 
> > <python-list@python.org> wrote:
> > 
> > Hi,
> > 
> > Apologies if the following description is to brief - I can expand if no
> > one knows what I'm on about, but maybe a short description is enough.
> > 
> > I am developing a command line application using Typer.  Most commands
> > need to do something in a database and also do LDAP stuff.  Currently
> > each command creates its own Database and LDAP objects, since each
> > command forms an entry point to the program.
> > 
> > With Typer, is there a way I can define the equivalent of class
> > attributes at a single point which are then available to all commands?
> 
> I do not know typer. But the general solution is to create an instance of 
> your class
> and tell typer to call member function of the instance.
> 
> app = Application()
> …
> typer.set_callback(app.my_handler)

Despite the fact that "everything is an object" in Python, you don't
have to put data or functions inside classes or objects.  I also know
nothing about Typer, but there's nothing wrong with functions in a
module.

There's also nothing wrong with writing a function that creates and
returns the database and LDAP connections (perhas as instances of
application-level classes), amd calling that function from within each
command.

DRY.  Yeah, yeah, yeah.  :-/ So there's one line at the top of each
comamnd that initializes things, and possibly a line at the bottom to
close those things down.  Turn those lines into a context manager, which
is actually a sub-framework inside Typer.  Don't convolute/compilicate
your design to eliminate one line at the top of each command.

Go ahead, accuse me of writing FORTRAN (all caps, no numbers or
qualifiers, as $deity intended) in Python.  But neither optimize
prematurely nor invoke the Inner Platform Effect to save one or two
lines in your not-yet-written commands, either.

Sorry for the rant.  :-)

Simple is better than complex.
Complex is better than complicated.

HTH.
-- 
https://mail.python.org/mailman/listinfo/python-list

Reply via email to