6 ms·
Python is certainly way better for a layman trying to do small things than C++
by drpgq 8y ago
Python is certainly way better for a layman trying to do small things than C++
- whatever1 8y agoTrue, but for me that python was my 4th CL (after fortran, c, c++), there were lots of gotchas, specially with implicit type conversions, mutable classes, and passing by value / reference which all seemed quite arbitrary in my first steps. Maybe for a complete beginner these are no-issues.
- llukas 8y agoCan you explain implicit type conversions problems in python?
- whatever1 8y agoIt is not a problem, it was just non expected behavior for someone trained in strong typed languages. For example, you want to calculate the performance of your ML algorithm by counting the correct predictions / total. My expectation was that the result of a division of integers, would be a float, specially if the modulo is not 0.
- ufo 8y agoThe division operator was one of the things that changed in Python3. In Python2 the (/) with integer arguments is integer division, rounded down. Python3 introduced (//) for integer division and now (/) always does floating-point division.
- cma 8y agoThat's how it is in python 3.
- JoBrad 8y agoI think this was actually addressed and back-ported to 2.2+, with PEP 238. https://www.python.org/dev/peps/pep-0238/ https://www.python.org/dev/peps/pep-0238/
- contravariant 8y agoThat's not an implicit type conversion, that's just a different convention for what '/' should do on integers.
- ambrice 8y agoIn what strongly typed language does the division of two integers result in a float?
- dwheeler 8y agoMany languages are not strongly typed (where "strongly typed" means "variables must be predeclared with their types (though they may be inferred)"). If your only experience is with strongly-typed languages, then MANY things about Python will be different, because Python is one of many languages that is not strongly typed. For example, in Scheme (a Lisp), a division (/) presented with exact input values and a non-zero denominator will produce an exact value (an integer or rational). E.g., (/ 1 2) produces the exact fraction 1 divided by 2, and not 0. In addition, both Scheme and Python have different ideas of what an "integer" is, e.g., both are happy to compute the exact value of 2 to the 9999 power. There's no requirement that "integer" correspond to the underlying machine integer.
- kjeetgill 8y agoDouble check me on this, but I'm pretty sure your definition of strong types is wrong; that's static typing. Python is strongly typed but not staticly. Weak typing is more like 1 == "1" is true. Aka implicit parsing or casting.
- ufo 8y agoWeak vs strong typing doesn't have a standard mathematical definition but you are correct that it is usually has to do with implicit type conversions.
- kazinator 8y agoDecades ago, the Pascal camp hijacked the term for the requirement of explicit conversions in a static language. Pascal would be strongly typed because for instance, characters and integers will not inter-operate without chr and ord, and also floating and integer conversions must be explicit. This is in contrast with something weakly typed like C. The weakness in C can be a problem. For instance, a floating to integer conversion that is out of range of the target type invokes undefined behavior. Also, when in range, it can produce a value not equal to the original integer, due to lack of precision. So an innocuous statement like f = i; that passes static type checks without any required diagnostics can go wrong. If a cast were required to make the diagnostic go away, then that at least creates a visible record in the program text that a dangerous conversion is taking place. Another use of "strongly typed" in the realm of Pascal is that it refers to name equivalence for type alias definitions. The C typedef mechanism is weakly typed because "typedef int user_id_t" doens't create a new type; user_id_t is the same thing as int, such that a pointer to user_id_t is compatible with pointer to int and so on.
- samatman 8y agoThat result should be a ratio, surely
- cma 8y agobools can be silently converted to int. 1 + true is ok, but 1 + "true" throws. Sometimes you do want to do math on bools, but it would avoid a class of errors if they would make you wrap them in 'int(the_boolean_variable)'.
- politician 8y ago> Sometimes you do want to do math on bools.. Can you provide a concrete example for when this would be useful? I assume you're not talking about binary arithmetic.
- duckerude 8y agosum(x > 3 for x in iterable) True == 1, False == 0, so this counts how many items in iterable are greater than 3. But I think that's the only non-dirty way I've used it, and if that wasn't possible a trivial count() function could do the job. If I remember correctly, bool subclasses int mostly for compatibility with pre-existing conventions. People were already defining their own "True = 1" and "False = 0" constants before they became part of the language.
- cma 8y agoIf it wasn't possible you could still do: sum(x > 3 for int(x) in iterable) And avoid a class of errors in other places.
- qznc 8y agoImplicit string and unicode conversions were confusing in Python 2. True + True evaluates to 2, although that is technically not a type conversion.
- meowface 8y agoTrue + True is still 2 in Python 3.