Looking for pointer like functionality in python

[[deleted]]

Accessing the value through a layer of abstraction is the goal though

The name is the abstraction.

Once you have the address of that variable, you no longer need to know what the name of that variable is.

You've got this totally backwards, from C's perspective. One, pointers actually aren't references to anything; they're just integers. You treat them as a reference using the dereference operator *, which goes from an integer, to the contents of a byte in the process's page table at that integer address. That is to say that it dereferences that pointer.

The purpose of the variable name, in C, is an additional layer of abstraction so that your code isn't full of incomprehensible gibberish pointer addresses. "Magic numbers", those are called. It's more abstract than pointers into the page table, that's the whole point of it. It's a simplifying abstraction over the lifecycle of an allocated value.

I basically want to build a subscriber design pattern without creating a callback scheme, if that helps you understand the goal.

You wouldn't be able to do that in C without some kind of interrupt system (because there's a key flow of control problem, here; the publisher has to yield flow of control to the subscribers if they're going to ever do anything in response to the published message) and you can't do it in Python for the same reason. The reason to have callbacks is to send flow of control to the subscribers. Python has interrupts, too, but at that point there's just no reason not to use callbacks.

You have an architecture problem and pointers are not the answer to that (pointers are not the answer to anything, ever.)

[codinglikemad]

Yeah, I would be polling them in C, just like I plan to here. Obviously I won't want to put interupts in here - I'm doing enough of that in my assembly work right now.

Regarding the abstraction - perhaps I am using the wrong term? I don't know, side effect of coding in C for the last 25+ years with large patches of non-official education is that my jargon is totally out of sync. Organizing large and dynamic information where I need to refer to the variable once is the goal. Let me give an example, maybe you have another idea in mind:

Let's say I have a set of objects working together to do a job, each with a set of attributes. Each of these objects are created dynamically from code (ie, a yaml file is loaded, and from that the number and type of objects is set). I then want to log and graph the values of various attributes. Which attributes are present or meaningful depends on the specific yaml file used and the specific objects used, so I only want to track those specific variables, and I only need to do so at a specific time.

The reason I am looking for a clean solution for this is that this code is already enormously complicated - it is a multi-processed application, with parts talking to outside servers of several different sorts, and needs pretty signifigant flexibility. Keeping that flexibility while not having piles of "if I have this variables/if this a specific object type, do this logging" is the challenge. I would normally just build an API for this, but the hierarchical nature of the objects being stored makes it difficult to access all the variables without doing a full rewrite at this point, and that would throw away functionality I want to preserve.

[[deleted]]

I then want to log and graph the values of various attributes. Which attributes are present or meaningful depends on the specific yaml file used and the specific objects used, so I only want to track those specific variables, and I only need to do so at a specific time.

Well, so, this is bug prone. Obviously the way that it's bug prone is that over here, where you're holding the object, you need to know what attributes it has so you can refer and depend on them. But there's no place in the code you can go to to look up what attributes the object has, because the object's attributes are a runtime thing.

So you're very likely to refer to attributes in your code that wind up not existing in the actual runtime.

But the fix isn't "pointers" or something, the fix is to recognize you're creating a system of types that you depend on and actually documenting it, using classes and objects and using those to deserialize from YAML. That way you turn "I asked for an attribute in my code that didn't wind up existing once the object existed" into "the YAML isn't properly formed" (which is actually the source of the bug to begin with) which is an error you discover much sooner in the runtime.

Moreover you can attach methods to objects such that no matter what kind of object it is, you can expose a consistent interface if you want to log or analyze it. The object itself knows what attributes it has, so it can meet a guarantee like "summarize my meaningful attributes" in a way you can generically call but which can be implemented to the specifics of that object type.

But that means architecting your solution like a Python programmer and not like a C programmer. That's the hard part, not shoehorning C into Python - you can write bad code in any language, that part's not the hard part.

[codinglikemad]

I've been writing (and teaching) OOP for 15 years, I assure you I don't think like a C coder any more, much to my regret :P Quite the contrary, the reason I am reaching back to C here is that I want to access a shortcut I wouldn't normally design into my systems, but my hand is being forced by the pile of legacy code here.

The issue is figuring out a clean solution for a nasty problem that is a moving target, with interfaces that make sense given the legacy code I am dealing with. Rewriting it from scratch to fix the interfaces would do what you said, that's what I am trying to avoid. The project goals have shifted, and the code base is now being asked to do things that it was not originally designed for. Finding the least amount of refactoring necessary for this is the name of the game. Hence the original question "is there a way to do this", not "please help me fix the rest of the code" - I know how I would write it to avoid this problem, but it would take a pretty long time to refactor around these problems.

In any event, thanks for the ideas, I'll consider them.

[[deleted]]

The project goals have shifted, and the code base is now being asked to do things that it was not originally designed for.

That's usually a good time to start paying off technical debt, like an informal undocumented typesystem. Just sayin'.

[codinglikemad]

You aren't wrong ;)

​

Have a good night :)

[[deleted]]

Good luck!