81–90 of 168 posts
Earlier quoted context omitted.
The single leading underscore?
Is conventional, it doesn't do anything at the language level.
Earlier quoted context omitted.
I mean, this one is solvable by not using magic constants. Pretty easy to avoid. Can also lint it.
I don't get what you're saying. How is it possible to write code without string literals? subprocess.check_call([ "/usr/bin/env", "echo" "hello world" ])
Earlier quoted context omitted.
> An asserts checks DESIRED constraints. Then imagined it is. Your desires are totally a part of your imagination, unless you make them become real. > Depending on the implementation, an assert can either merely log or absolutely stop a program that doesn't pass its test, so it very much has a bearing on what the program will actually do. Point taken. Unfortunately, logging errors or aborting the program won't make a…
> Then imagined it is. Only in the most pedantic and useless sense of the term. Asserts are not just some random imagination, they are added based on the program's specifications and expected/desired functionality and constraints. The CS term for those kind of constraints are "invariants", and asserts are a way to be notified if those invariants are violated. > unless you make them become real. Only there are no assu…
An “invariant” is a function of the process state whose value remains constant (hence “invariant”) in spite of changes to the process state. Perhaps you meant “precondition” or “postcondition”?
> Only there are no assurances for that. If the invariants in your program were somehow guaranteed to be "real"
Guaranteeing that preconditions, postconditions and invariants hold when they're supposed to hold is your job, not the computer's.
> then you wouldn't need asserts.
I absolutely don't need asserts. An assert merely describes what you want, but that's useless to me, unless you establish a relation between what you want and what your program actually does - with proof.
> Asserts are there because whether you tried to make your invariants "become real" or not, you'll still miss things, have bugs,
It will become patently clear when the proof doesn't go through.
> have unexpected interactions with code/systems outside your control etc.
What happened to sanitizing input at system boundaries?
> Assertions are not expected to "magically become true"
Of course. Assertions are expected to always be true.
Earlier quoted context omitted.
I mean, this one is solvable by not using magic constants. Pretty easy to avoid. Can also lint it.
I don't get what you're saying. How is it possible to write code without string literals? subprocess.check_call([ "/usr/bin/env", "echo" "hello world" ])
Earlier quoted context omitted.
> If you have the process quit it definitely stops them from being false though. The assertion remains false for the final process state, before the process quits. Outside of the process, the assertion is simply meaningless (neither true nor false), because the assertion's free variables are only bound inside the process.
> The assertion remains false for the final process state, before the process quits. Which is inconsequential. Programmers don't expect automatic "recovery" from assertions, they expect them to notify them of the violated constraint, and/or to ensure that a program wont go on and use a value that violates an assertion further down -- which program termination achieves. > Outside of the process, the assertion is simpl…
Users don't expect failed asserts at all.
> Captain Obvious?
Apparently not obvious enough for JonnieCache, who said: “If you have the process quit it definitely stops them from being false though.”
Earlier quoted context omitted.
I don't get what you're saying. How is it possible to write code without string literals? subprocess.check_call([ "/usr/bin/env", "echo" "hello world" ])
I think she meant to not pass the strings but assign them to constants and then pass those.
Earlier quoted context omitted.
I love Python, but I have to agree on this one.
I mean, this one is solvable by not using magic constants. Pretty easy to avoid. Can also lint it.
Then yes, I rely on the linter and testing.
"Being easy to pick up and progress quickly towards developing larger and more complicated applications, Python is becoming increasingly ubiquitous in computing environments".
Why would you change the order of the subject in such an unreadable way? Isn't much easier to say:
"Python is becoming increasingly ubiquitous in computing environments, as it's easy to pick up and progress quickly towards developing larger and more complicated applications"
I'm not expert in writing, it just sounded weird. If anyone can explains what's going on there, really appreciated.
Completely out of context, sorry, but couldn't avoid to note this: "Being easy to pick up and progress quickly towards developing larger and more complicated applications, Python is becoming increasingly ubiquitous in computing environments". Why would you change the order of the subject in such an unreadable way? Isn't much easier to say: "Python is becoming increasingly ubiquitous in computing environments, as it's…
Completely out of context, sorry, but couldn't avoid to note this: "Being easy to pick up and progress quickly towards developing larger and more complicated applications, Python is becoming increasingly ubiquitous in computing environments". Why would you change the order of the subject in such an unreadable way? Isn't much easier to say: "Python is becoming increasingly ubiquitous in computing environments, as it's…