Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A bite of Python

access.redhat.com

Post reply on HN
Print view View original

91–100 of 168 posts

Re: A bite of Python

#91

Post by coldtea »

catnaroek wrote: post #83
coldtea wrote: post #53

Earlier quoted context omitted.

> 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…

> The CS term for those kind of constraints are "invariants", and asserts are a way to be notified if those invariants are violated. 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 guara…

>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”?

No, I meant invariant. An invariant is something that is supposed to hold true, not just things that are guaranteed to hold true (e.g. a constant that can't ever change anyway). That's why the need for assertions to check that invariants hold.

From Wikipedia:

"In computer science, an invariant is a condition that can be relied upon to be true during execution of a program, or during some portion of it. It is a logical assertion that is held to always be true during a certain phase of execution. (...) Programmers often use assertions in their code to make invariants explicit."

Preconditions and postconditions are similar in concept, but are supposed/wanted to hold true before (pre) or after (post) a method runs.

>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.

Well, asserts weren't created specifically for you. Feel free not to use them.

They are useful to me, and assuming from their widespread use, others, even if they don't formally prove the program does 100% that it needs to (which nobody expected them to anyway).

Until we all program in Coq or similar, they will be useful for all kinds of checks. A correct program is a spectrum, not a binary option.

>Of course. Assertions are expected to always be true.

No, they are also expected to be false -- that's why we add assertion statements to check whether our assertions hold. But we're splitting hairs twice or three times here.

Re: A bite of Python

#93

Post by coldtea »

catnaroek wrote: post #85
coldtea wrote: post #57

Earlier quoted context omitted.

> 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…

> Programmers don't expect automatic "recovery" from assertions, 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.”

>Apparently not obvious enough for JonnieCache, who said: “If you have the process quit it definitely stops them from being false though.”

He meant from being false subsequently in the program.

I see we were joined by Technically Correct Man too.

http://9gag.com/gag/a5PmrLq/technically-correct-man-the-man-...

Re: A bite of Python

#94

Post by dfox »

sitkack wrote: post #70
sangnoir wrote: post #52

Earlier quoted context omitted.

Unless the article was updated after your comment: the reason is right there in the article: "However, Python does not produce any instructions for assert statements when compiling source code into optimized byte code (e.g. python -O). That silently removes whatever protection against malformed data that the programmer wired into their code leaving the application open to attacks. The root cause of this weakness is t…

I would argue that one should never use '-O' it also strips doc strings from running code. Not really an `optimization` but they had do something right? One couldn't run __unoptimized__ in production could they?

I assume that almost nobody uses -O in production.

Re: A bite of Python

#95

Post by skywhopper »

I would never accuse Python of "language clarity and friendliness". Far from it. For someone who came up through C, Java, Perl, and Ruby, but who's wrangled with Python, Javascript, Go, and even Haskell in recent years, I still find Python mysterious, self-contradictory, and filled with implicit rules and assumptions that are entirely un-intuitive to me far more than other languages. And yet, people seem to like it. Certainly this article does. It's an interesting effect.

Re: A bite of Python

#96

Post by tomato123 »

amyjess wrote: post #75

On the float behavior: I really wish Python 3 had the sense to do what Perl 6 did and interpret all literals with decimal points (except those that use scientific notation) as Fractions instead of floats. That would solve all these floating-point errors without requiring significant modification of code, plus Python 3 would be the perfect time to do it because they're already throwing out backwards compatibility beca…

That would kill Python for scientific use. Also, while nice, Fractions have their own pitfalls due to potentially catastrophic runtime behavior.

Re: A bite of Python

#97

Post by tolmasky »

michaelfeathers wrote: post #6

The behavior of 'assert' is not an anomaly. It comes from 'design by contract.' Assert is primarily meant to be documentation of constraints in code and secondarily a way of catching errors during development. "Contract conditions should never be violated during execution of a bug-free program. Contracts are therefore typically only checked in debug mode during software development. Later at release, the contract che…

Couldn't the assert message just say something like ", warning: this is only checked in development". I don't know, requirement of knowing how something works are always kind of tough since a lot of people's first interactions with things are in the code (like if they've just joined a new project), and they may assume they understand the functionality, and their assumptions may initially seem correct as they test it themselves. Its one of those "don't know what you don't know" scenarios, and "look up every function you ever see just in case what you think it does isn't what it actually does!" can be a bit impractical. So if this is known to be a gotcha, making the function itself speak that gotcha might be useful.

Re: A bite of Python

#98

Post by Twirrim »

sitkack wrote: post #70
sangnoir wrote: post #52

Earlier quoted context omitted.

Unless the article was updated after your comment: the reason is right there in the article: "However, Python does not produce any instructions for assert statements when compiling source code into optimized byte code (e.g. python -O). That silently removes whatever protection against malformed data that the programmer wired into their code leaving the application open to attacks. The root cause of this weakness is t…

I would argue that one should never use '-O' it also strips doc strings from running code. Not really an `optimization` but they had do something right? One couldn't run __unoptimized__ in production could they?

So far as I've ever read, literally all -O does is strip asserts and docstrings. It doesn't really optimise anything.

Re: A bite of Python

#99

Post by viraptor »

greggyb wrote: post #72
viraptor wrote: post #19

Earlier quoted context omitted.

> The point the article makes on comparing floating point values and the floating point type is true, but it's not because of any rounding error. Do you mean this example? (it's the only one I can find about floating point comparison) > 2.2 * 3.0 == 3.3 * 2.0 It's definitely due to accuracy error. (rather than type comparison) How would you explain it otherwise?

There is another snippet near that section which evaluates the following. >>> float > float('infinity') True

Bah, you're right, missed that example :(

Re: A bite of Python

#100

Post by wyldfire »

viraptor wrote: post #10
ubernostrum wrote: post #5

Earlier quoted context omitted.

I looked at Bandit earlier this year, but had to put it down when I discovered it didn't have a way to fill in default config -- the instant I specified anything in the config file, I had to supply a complete config, including literally every single check it's capable of doing, because Bandit would discard all its defaults on encountering that single line of custom config. Don't suppose you know if that's gotten bett…

It's not ideal - the config file is still a complete list, but there are a few things you can do. - `bandit-config-generator` will give you a file filled with the current/default configuration, so it's a simple way to start with the defaults and modify just what you need - if you just need to enable/disable tests rather than reconfigure, you can do that in command line options - if you want to get rid of specific war…

FYI when using pypy bandit fails to discover tests for some reason (could be a pypy bug?). In this case, the default output generated by bandit-config-generator is mostly empty and bandit fails to parse it. It doesn't indicate what the nature of the parse failure is (what line, what rule(s) were violated), even with verbose mode. The readme doesn't cover the format of the config file. Is it YAML/TOML/JSON/other?
Post reply on HN