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

161–168 of 168 posts

Re: A bite of Python

#161

Post by kruczek »

dcuthbertson wrote: post #114
p4wnc6 wrote: post #101

Earlier quoted context omitted.

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.

It really depends on the type of software. Sometimes if something unexpected happens and you just catch and report an error, then you may end up in a state which will result in further errors a few hours later. It is much easier to track the root cause, if the program crashes immediately, than having to analyze several hours of logs. And then crashing (i.e. quitting with a core dump) is as graceful as it can be, since it provides all the necessary information to analyze the problem right when it happened.

Re: A bite of Python

#162

Post by kstrauser »

aprdm wrote: post #157
kstrauser wrote: post #103

Earlier quoted context omitted.

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

haha, your explanation is exactly the mutable vs immutable thing. dicts are mutable, so, it doesn't create a new object to make an assignment numbers are immutable, so, it does.

Except that's 100% wrong here. There's not even a facility for marking an object as immutable in Python, so that wouldn't support user-defined classes at all.

Python is always pass-by-object-reference, and assignment is always a pointer operation. It's not special-cased like you're describing.

Re: A bite of Python

#163

Post by nilliams »

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…

Well you've picked the perfect example where Python's list comprehensions shine, 1 map, 1 filter, 1 'each'.

I think your Java example only looks gross because it's using ugly APIs, and isn't indented well, but otherwise, apart from contrived examples, pipelining is superior.

I find Python's lack of pipeline capability, whilst every other modern language supports it, very frustrating. JavaScript, Scala, Swift, Rust, Ruby, Elixir, C#, F#, Java, Kotlin Meanwhile, Python has borked, 1-line, lambdas that compose awkwardly with map/filter (if you do a map over the result of a filter, they'll be written in reverse order), and refuses to implement useful methods on lists, that would allow pipelining. It's like it can't decide to pick the OO solution to the problem (and add the methods to lists) or to go the FP route (and fix its lambdas), so has done neither.

So we're stuck hoping our problem at hand fits neatly into a list comprehension, which still won't be composable when we come back to it and realise we want to add another operation.

I like Python very much, but this is one of it's weakest areas in my opinion, so I'm surprised you bring it up as a strength.

Re: A bite of Python

#164

Post by humanrebar »

effie wrote: post #153
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…

I think it depends on the job the program is being used for. If the program is used in a setting where occasional crash has no severe consequences, say search engine backend, it may be useful for the company to actually run in production a program that is allowed to crash whenever severe error condition occurs. In scenarios where lives or lots of money hinge on program being alive and functioning, such as plane autop…

I agree with 'it depends' except for the case of safety critical systems, which I actually have experience in. A proper safety critical system should also be able to withstand a crash in an arbitrary process. The thing to remember is that there is no default path of execution if there is undefined behavior in C or C++ code. The process may do the worst thing it can, at least with the OS-level permissions it has.

Re: A bite of Python

#165

Post by humanrebar »

philipov wrote: post #104
p4wnc6 wrote: post #101

Earlier quoted context omitted.

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…

I think you misunderstand the use case. If your container is tracking work done and it thinks 20 requests were handled and only 10 were received, you have an invariant failure. Without more context, this could easily be trashed memory, in which case, you might already be in the middle of undefined behavior. In that case, getting the hell out of the process is the most responsible course of action. Efforts to even log what happened could be counterproductive. You might log inaccurate info or write garbage to the DB.

Also, if you don't catch an exception in C++, most systems will give you a full core, which includes a stack trace for all running threads. Catching an exception and 'exiting cleanly' actually loses that information.

Re: A bite of Python

#166

Post by humanrebar »

ianai wrote: post #135
dcuthbertson wrote: post #114

Earlier quoted context omitted.

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.

As someone who works in support, customers (at least the ones I support) REALLY need a clear and obvious crash to understand something's wrong. That really forces them to "do something differently" and/or look for help. You're correct in that it's not a good user experience. Neither is chaos.

> Neither is chaos.

Exactly. "Undefined behavior" includes showing private data to the wrong user and booking ten times more orders than the user originally indicated. I'll take crashing over that.

Re: A bite of Python

#168

Post by e12e »

kstrauser wrote: post #162
aprdm wrote: post #157

Earlier quoted context omitted.

haha, your explanation is exactly the mutable vs immutable thing. dicts are mutable, so, it doesn't create a new object to make an assignment numbers are immutable, so, it does.

Except that's 100% wrong here. There's not even a facility for marking an object as immutable in Python, so that wouldn't support user-defined classes at all. Python is always pass-by-object-reference, and assignment is always a pointer operation. It's not special-cased like you're describing.

Indeed, this may or may not be clearer with the help of id() - observe:

  >>> v=2
  >>> id(v)
  4148001784
  >>> id(2)
  4148001784
  >>> def m(a):
  ...   a=3
  ...
  >>> m(v)
  >>> id(3)
  4148001800
  >>> id(v)
  4148001784
  >>> v
  2


  >>> l=[]
  >>> id(l)
  4140973392
  >>> def m2(lst):
  ...   lst.append(1)
  ...
  >>> m2(l)
  >>> l
  [1]
  >>> id(l)
  4140973392
Post reply on HN