Discussion:
Common objects for CLI commands with Typer
(too old to reply)
Loris Bennett
2024-09-20 08:42:14 UTC
Permalink
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?

Cheers,

Loris
--
This signature is currently under constuction.
Lawrence D'Oliveiro
2024-09-20 21:28:58 UTC
Permalink
Post by Loris Bennett
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?
Never used Typer, but I see some details about more advanced use that
might be relevant here:

<https://typer.tiangolo.com/tutorial/subcommands/single-file/>
Barry
2024-09-21 05:38:05 UTC
Permalink
Post by Loris Bennett
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)

Barry
Post by Loris Bennett
Cheers,
Loris
--
This signature is currently under constuction.
--
https://mail.python.org/mailman/listinfo/python-list
2***@potatochowder.com
2024-09-21 10:40:37 UTC
Permalink
On 2024-09-21 at 06:38:05 +0100,
Post by Barry
Post by Loris Bennett
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.
Gilmeh Serda
2024-09-22 17:33:45 UTC
Permalink
Post by 2***@potatochowder.com
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.
Hear, hear!

Yet, lots of people put the word class in every module they ever create
and add the notion of @property readers/writers in as well, just because
that's what they always do.

More people (mainly Java and C++ folks, I suppose, and a few Delphi
ditto's) should watch and listen to what Hettinger has to say about _ and
__ and classes and how to use them and why those things were invented.

Python != (Java || C++ || Delphi)

Python == language_for_consenting_adults
--
Gilmeh

It pays to be obvious, especially if you have a reputation for subtlety.
Barry Scott
2024-09-23 18:00:10 UTC
Permalink
Post by 2***@potatochowder.com
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.
Python is great in allowing you to pick your style.
A few lines in a module, a couple of functions or use classes.

But once your code gets big the disciple of using classes helps
maintenance. Code with lots of globals is problematic.

Barry
2***@potatochowder.com
2024-09-23 19:51:49 UTC
Permalink
On 2024-09-23 at 19:00:10 +0100,
Post by Barry Scott
But once your code gets big the disciple of using classes helps
maintenance. Code with lots of globals is problematic.
Even before your code gets big, discipline helps maintenance. :-)

Every level of your program has globals. An application with too many
classes is no better (or worse) than a class with too many methods, or a
module with too many functions. Insert your own definitions of (and
tolerances for) "too many," which will vary in flexibility.

(And as was alluded to elsewhere in this thread, you could probably
deduce the original and/or preferred programming languages of people
with certain such definitions. But I digress.)

$ python -m this|grep Namespaces
Namespaces are one honking great idea -- let's do more of those!
Roland Müller
2024-10-16 18:32:32 UTC
Permalink
Post by 2***@potatochowder.com
On 2024-09-23 at 19:00:10 +0100,
Post by Barry Scott
But once your code gets big the disciple of using classes helps
maintenance. Code with lots of globals is problematic.
Even before your code gets big, discipline helps maintenance. :-)
Every level of your program has globals. An application with too many
classes is no better (or worse) than a class with too many methods, or a
module with too many functions. Insert your own definitions of (and
tolerances for) "too many," which will vary in flexibility.
I think the need of classes comes when you need objects thus a set of
variables with an identity and that may be created N times. Classes are
object factories.

A second aspect is inheritance: classes may inherit from other classes
and reuse existing functionality and data structures for their objects.

In cases where you only need to encapsulate a single set of data and
functions modules are the best choice.

Loading...