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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)