A bite of Python • Hacker News Board

Re: A bite of Python

#111

Post by michaelfeathers » Thu, Sep 08, 2016, 4:55 PM UTC

p4wnc6 wrote: post #101

humanrebar wrote: post #78

Earlier quoted context omitted.

That is certainly one approach, and the article agrees. > The root cause of this weakness is that the assert mechanism is designed purely for testing purposes, as is done in C++. However, C and C++ are perhaps unique in how much undefined behavior is possible and in how simple it is to create. Inserting into a vector while iterating through it, for instance. Or an uninitialized pointer. That's why many C++ experts be…

All of the C/C++ experts I know, as well as people who have interviewed me coming from primarily that background, have always been among the most adamant to stress that an application crashing unexpectedly should never happen and is always the wrong outcome. I imagine they would say that your statement about crashing vs. e.g. launching the missiles is a false dilemma. You don't crash and you don't incorrectly launch…

I think the industry is on the cusp of settling on the Erlang model which is essentially allowing pieces of a program to crash so that the whole program doesn't have to. It will take time for practices and tools to spread.

Re: A bite of Python

#112

Post by wyldfire » Thu, Sep 08, 2016, 4:55 PM UTC

dec0dedab0de wrote: post #66

pvdebbe wrote: post #56

One Python gotcha that has bitten people in my company a lot: fun_call('string1', 'string2' 'string3') That is, missing commas and subsequent string concatenations can lead to nasty errors. I wish Python didn't nick this from C and would have just enforced the use of + to concat over-length strings, if they need to be split to multiple lines.

I love Python, but I have to agree on this one.

In many cases, this invocation of fun_call() would not match its definition signature and it would generate an exception. When that's the case it's not at all a Python gotcha because it halted and forced you to fix the error.

I like this string catenation behavior and I prefer it, even if it causes some confusion in (IMO rare) cases.

Re: A bite of Python

#113

Post by viraptor » Thu, Sep 08, 2016, 4:57 PM UTC

wyldfire wrote: post #100

viraptor wrote: post #10

Earlier quoted context omitted.

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?

Which version of pypy are you using? I can't reproduce the issue with 5.1.2 (ubuntu packaged one).

The config uses YAML format.

Regardless, config errors should be more verbose. I raised https://bugs.launchpad.net/bandit/+bug/1621552

Re: A bite of Python

#114

Post by dcuthbertson » Thu, Sep 08, 2016, 5:00 PM UTC

p4wnc6 wrote: post #101

humanrebar wrote: post #78

Earlier quoted context omitted.

That is certainly one approach, and the article agrees. > The root cause of this weakness is that the assert mechanism is designed purely for testing purposes, as is done in C++. However, C and C++ are perhaps unique in how much undefined behavior is possible and in how simple it is to create. Inserting into a vector while iterating through it, for instance. Or an uninitialized pointer. That's why many C++ experts be…

All of the C/C++ experts I know, as well as people who have interviewed me coming from primarily that background, have always been among the most adamant to stress that an application crashing unexpectedly should never happen and is always the wrong outcome. I imagine they would say that your statement about crashing vs. e.g. launching the missiles is a false dilemma. You don't crash and you don't incorrectly launch…

I've been writing software in C and C++ for a long time. Crashing is never a good user experience, so avoid it. If something unexpected happens, catch and report the error, then carry on, if possible, or gracefully exit otherwise.

Re: A bite of Python

#115

Post by zardeh » Thu, Sep 08, 2016, 5:23 PM UTC

mkesper wrote: post #27

guyzmo wrote: post #22

The part of the article about an issue with name mangling of private fields is somehow misleading. The feature is just some syntactic sugar. When within a class, private fields such as: class Foo: def __init__(self): self.__bar are accessible from within other methods of class Foo as `self.__bar`. But that's just syntactic sugar, the real name of `self.__bar` is `self._Foo__bar`. So from the outside "world", includin…

"Private" fields and methods should use one underscore. Two underscores are for name mangling issues and __method__ is for "magic" methods.

I'd say that private methods are double underscored, and protected methods are single underscored, since the goal of the __ is to prevent child classes from being able to use the parent implementation via self.__meth.

Re: A bite of Python

#116

Post by catnaroek » Thu, Sep 08, 2016, 5:24 PM UTC

coldtea wrote: post #91

catnaroek wrote: post #83

Earlier quoted context omitted.

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

> That's why the need for assertions to check that invariants hold.

No, you need proof.

> Until we all program in Coq or similar

So you're saying humans are fundamentally incapable of establishing the logical validity of what they assert by themselves? This contradicts historical evidence that people have done this for well over 2 millennia, using various methods and tools.

> A correct program is a spectrum, not a binary option.

Some errors might be easier to fix or have less disastrous consequences than others, but a correct program is one that has no errors, so I don't see where the spectrum is.

Re: A bite of Python

#117

Post by catnaroek » Thu, Sep 08, 2016, 5:25 PM UTC

coldtea wrote: post #93

catnaroek wrote: post #85

Earlier quoted context omitted.

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

> He meant from being false subsequently in the program.

But, you see, the assertion is no less false just because the process was aborted. The fact remains that there exists a reachable state for which the assert fails. So apparently what I meant is no more obvious to you than it was for JonnieCache.

Re: A bite of Python

#118

Post by ekimekim » Thu, Sep 08, 2016, 5:25 PM UTC

swampthinker wrote: post #12

I love that the header and navbar is responsive, but the content itself is not. Also input is truly baffling to me. Such a small mistake that could allow write access to your code.

it's historical - python was originally conceived as a toy language for teaching, in which context being able to do x = input(), type 2, and get an integer, is a desirable property.

Then we got stuck with it because backwards compatibility.

Re: A bite of Python

#119

Post by drauh » Thu, Sep 08, 2016, 5:32 PM UTC

skywhopper wrote: post #95

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

I'm afraid I disagree. I programmed in a variety of languages in grad school (physics): C, C++, Fortran 77, Tcl, Perl, Matlab, Maple, Mathematica, IDL, Emacs LISP, etc. Not to mention the stuff I started on in high school.

When I switched my analysis to Python, I became so much more productive. And other science researchers I have known have echoed this sentiment. Even writing a C module to speed up my Python was pretty straightforward, if tedious.

Python had the fewest surprises. And debugging other people's Python is exponentially less annoying than debugging other people's Fortran or C. It's still my go-to language to get stuff done without fuss.

Re: A bite of Python

#120

Post by metaphorm » Thu, Sep 08, 2016, 5:37 PM UTC

skywhopper wrote: post #95

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

every language has warts and gotchas. I judge a language by how nice its _idiomatic_ patterns are, rather than by how bad its warts are (unless there are an overwhelming number of warts that can't be avoided even in idiomatic code).