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

Can you explain implicit type conversions problems in python?

bools 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)'.

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

Here are some examples from the Python standard library:

  multiprocessing/pool.py:
      self._number_left = length//chunksize + bool(length % chunksize)
  test/test_math.py:
      tmant = tmant // (2*h) + bool(tmant & h and tmant & 3*h-1)

From NumPy and SciPy:

  numpy-1.11.0/tools/swig/test/testArray.py:385:
       sys.exit(bool(result.errors + result.failures))
  scipy/scipy/signal/signaltools.py:2003:
       n_out = n_out // down + bool(n_out % down)
  scipy/scipy/signal/signaltools.py:3001:
       n_out = x.shape[axis] // q + bool(x.shape[axis] % q)

Here's one from my own code, where I allow a query to be specified through --query , or as a hex-encoded query through --hex-query or as an input file through --queries, but I only allow one of them:

  if bool(args.query) + bool(args.hex_query) + bool(args.queries) > 1:

>Here's one from my own code, where I allow a query to be specified through --query , or as a hex-encoded query through --hex-query or as an input file through --queries, but I only allow one of them

This would be better written as a mutually exclusive argument group. Assuming you're using argparse: https://stackoverflow.com/a/13310109

"Better" only if you want the default error message. As the second rated answer for the question comments: "If you like to have more control about error message and the like, you can of course check the results later"

For example, this code:

    import argparse
    parser = argparse.ArgumentParser()
    g = parser.add_mutually_exclusive_group()
    g.add_argument("--queries",help="queries help")
    g.add_argument("--hex-query",help="hex-query help")
    g.add_argument("--query",help="query help")
    args = parser.parse_args()
    print(args)

When passed the command-line arguments "--hex-query AB --query CD --queries ASDF" it gives:

  error: argument --query: not allowed with argument --hex-query

My code gives:

  error: Can only specify at most one of --query, --hex-query, or --queries

Looks like the libraries use the technique to handle those conditional off-by-one situations that other languages might resolve with a ternary expression. Thanks!

FWIW, I only searched for lines containing 'bool(' and '+'. That means I missed some of the other uses, like:

  unittest2/compatibility.py:25:
    if bool(unc_path) ^ bool(unc_start):
  scipy/signal/fir_filter_design.py:266:
    pass_nyquist = bool(cutoff.size & 1) ^ pass_zero
  pypysrc/py/_path/common.py:65:
    if bool(value) ^ bool(meth()) ^ invert:

There's also a place where the bool is turned into an int, but that extra conversion isn't actually needed - the following would work without the int() call:

  scipy/stats/morestats.py:2083:
    correction = 0.5 * int(bool(correction)) * np.sign(T - mn)

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

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

That code is invalid, because you're using "int(x)" as an assignment target. What would you expect it to do?

sorry:

    sum(int(x) > 3 for x in iterable)

That works better if you expect things in iterable that aren't ints, but it's still summing bools. int(x) > 3 returns a bool, so in the end it's still doing something similar to

  sum([True, False, False, True, True, False])

But if bools didn't implicitly behaves like ints, but could still be converted to ints, you could do this:

  sum(int(x > 3) for x in iterable)

issubclass(bool, int) == True in Python 2. They're not converted to ints silently they are ints.

The point is they shouldn't be. Knuth argues against implicitly treating bool as int in Concrete Mathematics.

Agreed, however you have to take context into account. Python 2 didn't always have a bool type (granted, already a mistake), before it was introduced int was used instead. Making bool a subclass of int made it possible to use it even in combination with earlier code, which made adopting it trivial.

If bool wouldn't be a subclass of int, some projects probably would still be using int instead of bool.

Implicit string and unicode conversions were confusing in Python 2.

True + True evaluates to 2, although that is technically not a type conversion.

True + True is still 2 in Python 3.

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

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

That's not an implicit type conversion, that's just a different convention for what '/' should do on integers.

I think this was actually addressed and back-ported to 2.2+, with PEP 238.

https://www.python.org/dev/peps/pep-0238/

In what strongly typed language does the division of two integers result in a float?

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

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

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

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

The language of the real world?

Nobody doing maths with pencil or paper will think 3/2 equals 1.

More to the point, the symbol 1 represents a float as much as it does an integer.

That result should be a ratio, surely

That's how it is in python 3.