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.

On Fri, 20 Sep 2024 10:42:14 +0200, Loris Bennett wrote:

> 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/>

> 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)

Barry

>
> Cheers,
>
> Loris
>
> --
> This signature is currently under constuction.
> --
> https://mail.python.org/mailman/listinfo/python-list
>

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.

On Sat, 21 Sep 2024 06:40:37 -0400, 2QdxY4RzWzUUiLuE wrote:

> 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.

> On 21 Sep 2024, at 11:40, Dan Sommers via Python-list <python-list@python.org> wrote:
>
> 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

On 2024-09-23 at 19:00:10 +0100,
Barry Scott <barry@barrys-emacs.org> wrote:

> > On 21 Sep 2024, at 11:40, Dan Sommers via Python-list <python-list@python.org> wrote:

> 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!

On 9/23/24 22:51, Dan Sommers via Python-list wrote:
> On 2024-09-23 at 19:00:10 +0100,
> Barry Scott <barry@barrys-emacs.org> wrote:
>
>>> On 21 Sep 2024, at 11:40, Dan Sommers via Python-list <python-list@python.org> wrote:
>> 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.