#!/usr/bin/env python3
import inspect
def frobnicate(unfrobbed: any) -> None:
frame = inspect.currentframe().f_back
for name in [name for name, value in frame.f_locals.items() if value is unfrobbed]:
del frame.f_locals[name]
for name in [name for name, value in frame.f_globals.items() if value is unfrobbed]:
del frame.f_globals[name]
foo = open("bar.txt")
answer = frobnicate(foo)
print(foo)
Traceback (most recent call last):
File "hackers.py", line 20, in <module>
print(foo)
^^^
NameError: name 'foo' is not defined
Be careful with the absolutes now :)
Not that this is is reasonable code to encounter in the wild, but you certainly can do this. You could even make it work properly when called from inside functions that use `fastlocals` if you're willing to commit even more reprehensible crimes and rewrite the `f_code` object.
Anyway, it's not really accurate to say that Python passes by reference, because Python has no concept of references. It passes by assignment. This is perfectly analogous to passing by pointer in C, which also can be used to implement reference semantics, but it ISN'T reference semantics. The difference comes in assignment, like in the following C++ program:
#include <print>
struct Object
{
char member{'a'};
};
void assign_pointer(Object *ptr)
{
Object replacement{'b'};
ptr = &replacement;
}
void assign_reference(Object &ref)
{
Object replacement{'b'};
ref = replacement;
}
int main()
{
Object obj{};
std::println("Original value: {}", obj.member);
assign_pointer(&obj);
std::println("After assign_pointer: {}", obj.member);
assign_reference(obj);
std::println("After assign_reference: {}", obj.member);
return 0;
}
$ ./a.out
Original value: a
After assign_pointer: a
After assign_reference: b
Just like in Python, you can modify the underlying object in the pointer example by dereferencing it, but if you just assign the name to a new value, that doesn't rebind the original object. So it isn't an actual reference, it's a name that's assigned to the same thing.
ANYWAY, irrelevant nitpicking aside, I do think Python has a problem here, but its reference semantics are kind of a red herring. Python's concept of `const` is simply far too coarse. Constness is applied and enforced at the class level, not the object, function, or function call level. This, in combination with the pass-by-assignment semantics does indeed mean that functions can freely modify their arguments the vast majority of the time, with no real contract for making sure they don't do that.
In practice, I think this is handled well enough at a culture level that it's not the worst thing in the world, and I understand Python's general reluctance to introduce new technical concepts when it doesn't strictly have to, but it's definitely a bit of a footgun. Can be hard to wrap your head around too.
The way it would likely work is that a cryptographically secure open source random algorithm is made known long in advance which takes, say, a full hour to run on top of the line computers. In the hour before it is run, anyone can send in a number of their choosing, which are all added up (or rather their concatenation is cryptographically hashed) to make the seed. Then anyone can check that their number was indeed included and run the algorithm themselves to verify. It really only takes a single honest person to send in a 20-digit number to make it basically impossible to manipulate. Maybe I'm missing something.
One way to resolve the issue is to use a distributed randomness generator like DRand which is threshold decryption based and hence can offer some robustness as well.
Why take random samples if you tell your citizens that everyone has a vote? How do you proof it was random, and what do you do if by random chance you got a really on sided group? Sorry we have now a fascist state but it was random so it's fair.
Completely unrelated concept: unit testing is part of a regression testing framework while OFAT is a (almost always suboptimal) test strategy for designed experiments.
> but you can for other internet connected professions in the private sectors
You can certainly try, but the quality will be noticeably poorer. You can get away with that for a while, especially as a big business, but I think the tide is already turning there. Everyone's tired of broken shitty tech that doesn't work properly with no one to really contact about it. Skilled IT professionals are in huge demand nowadays, it's only the fleas on the rats complaining that the ship is sinking. Rats can swim, they'll be fine as long as land isn't too far. Mechanics and firefighters that can actually keep the ship going (if you pay us well enough), are on the other hand doing quite well these days. Unions are great, especially for tech professionals. As long as you're still allowed to negotiate personally as well, there's no reason not to.
>You can certainly try, but the quality will be noticeably poorer.
I know HN loves repeating this outdated trope to feel good, but that's not always the case and not in many I saw where they offshored and product quality didn't drop because they made sure to hire qualified people and managers, and not bottom of the barrel on the cheap.
Sure, you won't find many rockstar workers abroad, but most companies don't need that many rockstar engineers especially for CRUD work which is a commodity now, and plenty of countries have upskilled their workforce in the last 20 years especially in web CRUD, that they can take on the maintenance of stable products on the cheap.
>Everyone's tired of broken shitty tech that doesn't work properly with no one to really contact about it.
You mean like the one Google, Microsoft, Crowdstrike, etc. build in he US and not by offshore workers?
>Unions are great, especially for tech professionals. As long as you're still allowed to negotiate personally as well, there's no reason not to.
That's not how unions work in France and Germany. The unions set strick salary bands so that a newcomer can't earn more than someone who's been longer in the company so your negotiation doesn't get you anything, you let your union negociate for you.
> product quality didn't drop because they made sure to hire qualified people and managers, and not bottom of the barrel on the cheap.
So they didn't save much money, they just chose not to pay their domestic talent. Much better.
>Sure, you won't find many rockstar workers abroad, but most companies don't need that many rockstar engineers especially for CRUD work which is a commodity now,
Sure, we're mostly in tech and tech is one of the "easier" factors to outsource. I think your underrating how much even Crud work needs, but that's besides my main point.
You can't outsource everything. If you need people in a physical store, or on a physical setting in a building or in government land, you'll need to negotiate with your labor or shut down the project. I guess you can immigrate aliens who you can pay under minunum wage with the promise of citizenship, but that's clearly beyond the gray area at this point.
>You mean like the one Google, Microsoft, Crowdstrike, etc. build in he US and not by offshore workers?
In the grand scheme of things, most of my CS nightmares came from financial issues, not technical. And yes, they want to make that experience painful.
Sure, Crowdstrike happens but domestic labor means it's mostly fixed (and actually fixed) in a weekend instead of a week with precarious results.
If you're a schizo, it's probably pretty easy to rationalize: you've heard your god talk to you and tell you these things. It's easy to go "You're obviously crazy, this can't have happened!" from the outside looking in, but it's far harder to reject your own experiences out of hand as obviously false.
Doubly so because the types of experiences you get tend to be very hard to disprove. It's usually not something like "There's a yellow demonic entity running around deep in the valley by the mountain" where it's something that can be checked and explained, like actually just a moose who got tangled up in a yellow wintercoat or something, and is running around irritated trying to get it off. Rather it tends to be more "God is speaking to me through my mind, and only does so to special people" or "These people are trying to make me be as miserable as I was before I found God by making me reject him, they must be servants of Satan".
Really, if anything, I would say gifted people are probably way more likely to become religious fanatics if they have these experience. We do not have a good explanation for these things (you're sick in the head, something something dopamine does not work too well for otherwise perfectly functional and rational people), and the explanations that we do have must more or less be taken on faith. You need to trust that the person explaining these things to you is both more capable of judging the situation than you are, and has your best interests in mind. For most gifted people, the chance of both of these being true in any particular situation is abyssmally small.
This applies even more so in mental healthcare, where we're practically at the same stage of technological advancement as we were when trepanation and bloodletting were state of the art in physical medicine. We have a long way to go before we can truly make the "You're crazy!" explanation stick for those who are used to living in a world that is inevitably wrong about most things, whether subtly or overtly. Really, if you're used to being the smartest guy in the room, what choice do you have? What choice do you have but to trust yourself? Yes, you might be delusional and wrong, but you know the world at large is delusional and wrong on countless subjects as well. Why trust them more than you trust yourself, when just about every single experience you've had in life has fed into your belief that you are fundamentally better at judging reality than most people are?
There is none. The word has been misused to the point of ambiguity being an accepted part of its definition, and we are all worse off for it. The language is now less expressive, and you need to use more words to add context and remove ambiguity when you really do mean "literally" in the literal sense.
Why in the world would you try to put a positive spin on it? It's bad behaviour, and you should feel bad for engaging in it. It's greedy and dishonest. Pass.
Not that this is is reasonable code to encounter in the wild, but you certainly can do this. You could even make it work properly when called from inside functions that use `fastlocals` if you're willing to commit even more reprehensible crimes and rewrite the `f_code` object.
Anyway, it's not really accurate to say that Python passes by reference, because Python has no concept of references. It passes by assignment. This is perfectly analogous to passing by pointer in C, which also can be used to implement reference semantics, but it ISN'T reference semantics. The difference comes in assignment, like in the following C++ program:
Just like in Python, you can modify the underlying object in the pointer example by dereferencing it, but if you just assign the name to a new value, that doesn't rebind the original object. So it isn't an actual reference, it's a name that's assigned to the same thing.ANYWAY, irrelevant nitpicking aside, I do think Python has a problem here, but its reference semantics are kind of a red herring. Python's concept of `const` is simply far too coarse. Constness is applied and enforced at the class level, not the object, function, or function call level. This, in combination with the pass-by-assignment semantics does indeed mean that functions can freely modify their arguments the vast majority of the time, with no real contract for making sure they don't do that.
In practice, I think this is handled well enough at a culture level that it's not the worst thing in the world, and I understand Python's general reluctance to introduce new technical concepts when it doesn't strictly have to, but it's definitely a bit of a footgun. Can be hard to wrap your head around too.