A bite of Python • Hacker News Board

Re: A bite of Python

#101

Post by p4wnc6 » Thu, Sep 08, 2016, 3:34 PM UTC

humanrebar wrote: post #78

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…

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

I'm not a C++ developer so I can't say it with certainty. I more agree with what you're saying. I'm just relaying that my experience has been that out of many different language communities, C++ actually seems adamantly the opposite of what you're describing.

Re: A bite of Python

#102

Post by noobiemcfoob » Thu, Sep 08, 2016, 3:40 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.…

In my experience and implied by the rising popularity of python, you would be among the minority. Personally, I find python to be the most clear of any language I've worked with, most resembling natural language in the way I typically speak. Do you have some examples of how you find it self-contradictory?

Here's an example of its expressiveness a colleague and mine I discussing the other day: Python: [os.remove(i.local_path) for i in old_q if i not in self.queue] Java: old_q.stream().filter(i -> !self.queue.contains(i)).map(i -> new Path(i.local_path)).forEach(Files::delete);

I've programmed in both languages but joked I could only understand the Java line by using the Python line as documentation!

Re: A bite of Python

#103

Post by kstrauser » Thu, Sep 08, 2016, 3:55 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 find that with Python that's almost always caused by not quite understanding the underlying rules. Once understood, they're very consistent.

For example: does Python pass function arguments by value or by reference? Neither! It passes them by object reference - not by variable reference like C/C++.

Check out:

  >>> def foo(a):
  ...     a = 2
  ...
  >>> value = 1
  >>> value
  1
  >>> foo(value)
  >>> value
  1

and:

  >>> def mutate(dct):
  ...     dct['foo'] = 'bar'
  ...
  >>> value = {}
  >>> value
  {}
  >>> mutate(value)
  >>> value
  {'foo': 'bar'}

This apparent contradiction confuses a lot of people. The first example would imply that Python's pass-by-value, but the second looks a lot like pass-by-reference. If you don't know the actual answer, it looks magical and inconsistent, and I've heard all sorts of explanations like "mutable arguments are passed by reference while immutable objects are passed by value".

In reality, the object itself - not the variable name referring to the object - is passed to a function arguments. In the first example we're passing in the object `int(1)`, not the variable `value`, and creating a new variable `a` to refer to it. When we then run `a = 2`, we're creating a new object `int(2)` and altering `a` to point to the new object instead of the old one. Nothing happens to the old `int(1)` object. It's still there, and the top-level `value` variable still points to it. `a` is just a symlink: it doesn't have a value of its own. Neither does `value` or any other Python variable name. That's why the second example works: we're passing in the actual dictionary object and then mutating it. We're not passing in the variable `value`; we're passing in the object that `value` refers to.

The point of this long-windedness is that Python's rules tend to be very, very simple and consistent. Its behavior can be unexpected if you don't truly understand the details or if you try to infer parallels to other languages by observing it and hoping you're right.

Re: A bite of Python

#104

Post by philipov » Thu, Sep 08, 2016, 3:59 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…

In my experience, "You don't crash" means you catch the exception and exit gracefully, reporting a fatal error has occurred. Users don't distinguish between a crash and a fatal error.

Higher level languages are better at reporting uncaught runtime errors than C/C++ is, because they'll automatically do things like print useful stack traces and then exit gracefully even if you don't catch an exception. The interpreter doesn't crash when your code does.

Re: A bite of Python

#105

Post by Singletoned » Thu, Sep 08, 2016, 4:12 PM UTC

noobiemcfoob wrote: post #102

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

In my experience and implied by the rising popularity of python, you would be among the minority. Personally, I find python to be the most clear of any language I've worked with, most resembling natural language in the way I typically speak. Do you have some examples of how you find it self-contradictory? Here's an example of its expressiveness a colleague and mine I discussing the other day: Python: [os.remove(i.loc…

I've always found the fork bomb page on Wikipedia to be a good example of different languages. https://en.wikipedia.org/wiki/Fork_bomb

The Python is example is both short and obvious, whereas the other examples tend to be either cryptic or complicated.

Re: A bite of Python

#106

Post by [deleted] » Thu, Sep 08, 2016, 4:23 PM UTC

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…

[deleted]

Re: A bite of Python

#107

Post by warkdarrior » Thu, Sep 08, 2016, 4:26 PM UTC

riskable wrote: post #47

viraptor wrote: post #29

Earlier quoted context omitted.

> but come on, if an attacker has write access to your code Why is this relevant for this article? The article doesn't say anything about attackers having write access to the source.

Yes it does... One of the examples is monkey patching using bytecode. How are you going to do that without write access to the filesystem running your code? The same is true for module imports... If you have write access to the same directory as the code itself there's all sorts of havoc one can cause beyond merely substituting your own os.py.

You do not need access to the same directory as the code itself. Think of a Python program that can use plugins written by users. For example Django.

Re: A bite of Python

#108

Post by pklausler » Thu, Sep 08, 2016, 4:32 PM UTC

humanrebar wrote: post #78

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…

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…

Well, two things in the same set can't both be unique. Distinctive, sure, but not unique.

Re: A bite of Python

#109

Post by pstch » Thu, Sep 08, 2016, 4:35 PM UTC

amyjess wrote: post #77

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?

This really makes me wish they made the decision for Python 3 to auto-convert these literals to Fraction objects like Perl 6 does. Basically, autoconvert the above to this (and make Fraction a builtin instead of in the standard library, of course): >>> Fraction('2.2') * Fraction('3.0') == Fraction('3.3') * Fraction('2.0') True

The speed of these operations isn't on the same order of magnitude as floating-point operations. I do agree that literals for `Fraction` and `Decimal` would be interesting.

Also, I think that '2.2' is better represented as `Decimal`, as it's a decimal number (which is a subset of rational numbers, that are usually better represented using `Decimal`) (edit: that of course depends on the use case, as Decimal uses fixed-point precision).

Re: A bite of Python

#110

Post by xapata » Thu, Sep 08, 2016, 4:42 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 have occasionally needed to argue with a long-time C dev that crashing is exactly what I want my program to do if the user gives unexpected input. They're used to core dumps instead of pleasant tracebacks.