I’m a mathematician too. They’re probably speaking from an intuitive grasp of utility.

“I love life on Earth… but I love capitalism more.”

I have observed people taking Rust seriously. You need to reexamine your assumptions.

We have an evolved capability to short-circuit decisions with a rapid emotional evaluation. It means as a species we didn’t die out early [“that’s a lion; I’m a oerson; lions eat people ergo… Agh!” is not a sustainable strategy] - what’s amazing is that we can also apply it to elarned abstract things like an aestetic sense about programming languages. Such instincts aren’t always perfect, but they’re still worth paying attention to. I don’t see a reason not to express that in a blog post, but you can replace it with “this is unergonomic and in some cases imprecise” if you prefer.

That seems like quite a lot of booms.

Netware was rock solid.

Minimise your windows one at a time and check that the gnome keyring hasn’t popped up a dialog box sonewhere behind everything else that’s asking you if it’s okay to proceed.

It’s the gnome key ring ssh agent.

It’s possible that this has popped up a window asking gor permission / a passphrase / something and you’re not seeing that.

That’s only part of the handshake. It’d require agent input around that point.

Is this problem a recurring one after a reboot?

If it is it warrants more effort.

If not and you’re happy with rhe lack of closure, you can potentially fix this: kill the old agent (watch out to see if it respawns; if it does and that works, fine). If it doesn’t, you can (a) remove the socket file (b) launch ssh-agent with the righr flag (-a $SSH_AGENT_SOCK iirc) to listen at the same place, then future terminal sessions that inherit the env var will still look in the right place. Unsatisfactory but it’ll get you going again.

Okay, that agent process is running but it looks wedged: multiple connections to the socket seem to be opened, probably your other attempts to use ssh.

The ssh-add output looks like it’s responding a bit, however.

I’d use your package manager to work out what owns it and go looking for open bugs in the tool.

(Getting a trace of that process itself would be handy, while you’re trying again. There may be a clue in its behaviour.)

The server reaponse seems like the handshake process is close to completing. It’s not immediately clear what’s up there I’m afraid.

Please don’t ignore the advice about SSH_AGENT_SOCK. It’ll tell yoy what’s going on (but not why).

Without the ssh-agent invocation:

• what does ssh-add -L show?
• what is the original SSH_AUTH_SOCK value?
• what is listening to that? (Use lsof)

This kind of stuff often happens because there’s a ton of terrible advice online about managing ssh-agent - make sure there’s none if that baked into your shellrc.

Have you seen pictures of the sub? What makes you think the wiring was all hidden?

You joke, but watch this:

https://archive.org/details/take-me-to-titanic

from 29 minutes in. A last-minute adjustment before launch plugged in a thruster backwards; no protocol to check the behaviour prelaunch. They doscovered it when they got to the bottom.

The “why” is that the import system is caching modules in sys.modules.

The “what to do about it” is “not this”. Use a package layout with explicit names (p1.generic_name etc) instead.

You can use relative imports under those packages if you prefer (from .generic_name import ...).

If you want executables on the path look at setup.py or any of the myriad of overlapping modern equivalents that’ll let you specify a command-libe executable to install, then pip install -e . to install it in your venv’s bin dir.

If things are changing a bit each month, then in your module rather than a plain variable assignment

darabase = ...

you might want a function that you can pass in parameters to represent the things that can change:

def database(dir, ...):
    ...
    return ...

Then you can call it like this:

from database import database
db = database("/some/path")

… gope that makes some sense.

If it is the first thing, just put the db setup code you’re using in one file, call it “database.py”

database.py

# the code you commonly use, ending with
database = ...

From a second file in the same directory, write: main_program.py

from database import database
# The first "database" here is the module name.
# The second "database" is a variable you set inside that module.
# You can also write this as follows:
# import database
# ... and use `database.database` to refer to the same thing
# but that involves "stuttering" throughout your code.

# use `database` as you would before - it refers to the "database" object that was found in the "database.py" module

then run it with python main_program.py

The main thing to realise here is that there are two names involved. One’s the module, the other is the variable (or function name) you set inside that module that you want to get access to.

There’s not much here to go on. Are you asking how to write a module that you can import?

Are these the same set of DB files every time? Are the columns and other configurations the same? Are you writing new python code every month?

Are you using some ETL process to spit out a bunch of files that you’d like to have imported and available easily? Are the formats the same but the filenames differ?

I think it’s the first thing you’re after. There are a bunch of tutorials knocking around about this, eg, https://www.digitalocean.com/community/tutorials/how-to-write-modules-in-python-3

You might also be asking: if I write a module, how do I make it available for all my new python projects to use? You could just copy your whatever-my-module-is-called.py file around to your new projects (this might be simplest) but if you’re also expecting to be updating it and would like all of your projects to use the updated code, there are alternatives. One is to add the directory containing it to your PYTHONPATH. Another is to install it (in edit mode) in your python environment.

[I get the impression you’re a data person rather than a programmer - perhaps you have a colleague who’s more of the latter you can tap up for this? It doesn’t have to be difficult, but there’s typically a little bit of ceremony involved in setting up a shared module however you choose to do it.]

Incidentally, this kind of passive-aggressive pressure is the kind of thing that might be considered a legitimate security threat, post xz. If you need to vent, vent in private. If “it works for you” but the maintainer is asking legitimate questions about the implementation, consider engaging with that in good faith and evaluating their questions with an open mind.

Which mantra is that? The ellipsis doesn’t offer a clue.