undefined variables

[Skaperen]

i run into this problem a lot. i'm writing a new script that does some major stuff like create lots of processes on my laptop for so purpose or downloads a bunch files or creates lots of a cloud resource. the script is done (roughly) and i want to test it out. but some of the call can be very dangerous if the script misbehaves. so what i like to do is comment out the dangerous functions for a while until i am sure it will call them appropriately. what i run into is that these calls were coded to assign results to a variable. when i comment the line,the variable is not assigned, later code that uses that variable will fail. in C at least the variable continues to exist even if it has a wrong value. i wish python had some way to easily deal with this on one line, keeping the variable but not doing the action.

[perfringo]

I am probably not the brigthest and my feeble mind don't get it. Probably I misinterpret the question or don't comprehend it.

If one will 'comment out the dangerous functions for a while until i am sure it will call them appropriately' how can these functions 'to assign results to a variable'? There is no variable/value 'to exist' (keep) because it has not created in the first place.

If one tries to assign name to non-existing function result then it will raise NameError and variable will not come into existance:

>>> meaning_of_life = fourty_two()
/.../
NameError: name 'fourty_two' is not defined
>>> meaning_of_life
/.../
NameError: name 'meaning_of_life' is not defined

My understanding is that in order to 'continue to exist' one must run 'dangerous' function at least once.

On unrelated note:

If I want to check whether value exists then I would do simple try..except:

try: 
    x
except NameError:
    x = # assign some value

If I want to have some predefined variables then I put them at the start of the script. If I uncomment function then it just overwrites predefined value.

[ThomasL]

when i comment the line, the variable is not assigned, later code that uses that variable will fail.

So just commenting is not enough, create a new line and assign some dummy value to your variable that is needed in later code.
Don´t put the blame on Python, blame yourself for not being that smart to think about easy solutions.

[Skaperen]

the easier solution is to assign the dummy value before the code that might be commented out. then, people will wonder why it is there.

    fruitbar = 0 # why is this here?
    ...
    fruitbar = create_many_fruity_processes(list_of_fruits_to_go_search_for)
    pr(f'created {fruitbar} fruity task{"s"[fruitbar==1:]}')

[ndc85430]

It sounds like if you're having to comment out parts of the code while you're developing, you're going about things the wrong way. Why not at least write unit tests for the components in this system, so you're sure they're behaving as you expect (and test driven development is a great way to write software incrementally)? You haven't said what is meant by "dangerous" in your context, but you can at least mock out those calls in your tests, so you're not calling the real thing.

[Skaperen]

"dangerous" is stuff that can crash my system or wipe out files or overload someone's server with too many processes. so, instead of creating a process or deleting a file, i just have the code output a message of what it would do. once the messages reflect the intended action, then i can have it actually do that action. for example, i don't want a flood of processes launching thousands of cloud instances costing me lots of money.

[ichabod801]

I'm going to agree with Thomas and ndc here, the problem is your process. If you are designing something dangerous you need to make sure the dangerous parts are working correctly before you start designing an interface around them. If you must do the interface first then you should be using mock functions, and then going back making sure the dangerous parts work first. And you need a plan ahead of time before diving into this.

I don't always follow proper software design techniques, but I'm writing ditzy text games. If you are writing stuff that could screw up critical data or cost excessive amounts of money, you need to follow proper software design techniques and be careful. Randomly commenting out function calls is not the way to go about it. You're worried about undefined variable names but you haven't even touched on possible side effects.

[Skaperen]

i can't test the dangerous stuff to see if it works right because the stuff around it is what can make it work right or work wrong. another script similar to what i am working on now did have a failure due to the stuff around the part that was creating processes. it was supposed to create just 15 processes. but it ended up doing the recursion wrong and each of those 15 processes created 15 processes, and each of those ... i couldn't even shutdown ... i had to just power off. i then commented out the call to create a process and added a print('new process',flush=1). then i had to comment out a bunch of code because a variable was now not being set. setting it to some value would not be workable, either.

testing new code is always hard when testing parts that must not be allowed to fail.

[ndc85430]

Again, you can use a mock (i.e. a test double) to simulate the failure(s) so you can test the thing that uses it.

[Skaperen]

doing that for processes is harder. a mock itself would be so big it needs to go through its own testing.

i've got the program working, now. it lost the command line argument and that caused the explosion. without an argument, it starts 15 copies of itself, one for each AWS region, passing along a single region name as on argument. of it gets no arguments, it does all regions. if it gets exactly one argument, it processes that region itself. that' what happens with all th child processes. they each process one region. two or more arguments mean to make that many child processes.