# Would people like an introduction of a Julia debug mode? Possibly on by default in the REPL/Pluto/Jupyter
**URL:** https://discourse.julialang.org/t/would-people-like-an-introduction-of-a-julia-debug-mode-possibly-on-by-default-in-the-repl-pluto-jupyter/102535
**Category:** General Usage
**Created:** [August 6, 2023, 3:42pm UTC](https://discourse.julialang.org/t/would-people-like-an-introduction-of-a-julia-debug-mode-possibly-on-by-default-in-the-repl-pluto-jupyter/102535 "2023-08-06T15:42:34Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [August 6, 2023, 3:42pm UTC](https://discourse.julialang.org/t/would-people-like-an-introduction-of-a-julia-debug-mode-possibly-on-by-default-in-the-repl-pluto-jupyter/102535/1 "2023-08-06T15:42:34Z")
Julia has very few misfeatures. There are though a few footguns.
I’m thinking Julia needs a debug mode (if not removing the footguns in 2.0). I’m thinking this debug mode should be on by default on master, both in the REPL and for scripts, e.g. for PgkEval. Every package author would benefit, and should do CI on master.
If the code works in debug mode (does not throw an exception), it would work in regular mode, the one (still) used for scripts; in all released Julia versions.
The big question, to me, is should the debug mode be on in the REPL (also Pluto etc.). It seems like such a gain to know if you’re doing stuff wrong that it should be on even in release versions, but not for scripts, since we want old code to work in all cases.
So what are some examples of footguns that people might want to see detected? I can start by showing two examples:
A.
> [@The speed of light is an integer. Why should we care?](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108):
>
> Since 1983, the speed of light is defined to be exactly equal to 299,792,458 meters per second. So, it seems natural to define it as an integer while doing some culculations with Julia, for example, to calculate a Planck’s length. This is how it can be done in Julia REPL: c = 299\_792\_458; # the speed of light G = 6.67430e-11; # Gravitational constant h = 6.62607015e-34; # Planck's contant h\_bar = h / (2\*pi); # reduced Planck's constant planks\_length = sqrt(G\*h\_bar/c^3) As a result, we imm…
> [@The speed of light is an integer. Why should we care?](https://discourse.julialang.org/t/the-speed-of-light-is-an-integer-why-should-we-care/40108/1):
>
> ```julia
> plancks_length = sqrt(G*h_bar/c^3)
>
> ```
>
> As a result, we immediately get `3.5793584153084007e-32` which at first sight is what the Planck’s length should be.
>
> However, Wikipedia says that the Planck’s length is equal to `1.616255e-35`.
>
> You probably already realized that the reason for this is the integer overflow that happens when raising `c` to the power of `3`. Moreover, it is easy to fix this redefining `c` to be a float
You shouldn’t have to define c to a float (it is defined as an integer number), and it would be better to get an overflow error thrown (at least when developing; or even that ^ gives a Float64; or Rational).
The same code in Python (or slightly modified for its syntax gives the right answer).
There is already a PR fixing this (but will not be accepted until 2.0 because it’s a “breaking” change, though arguably helping, and at least perfectly ok for a debug mode):
>
>
> I haven't updated the tests yet, mostly because we need to get a consensus on wh…at to do.
> The thinking behind this is that by far the most common case of people running into overflows is trying to do things like \`10^x\`, when they meant \`10.0^x\`. Since this functionality is very well isolated, we can add checking without generally killing performance. There's a couple of details to work out though:
> \- What to do about small powers ^2, ^3, etc. @StefanKarpinski expressed a preference for those to keep behaving like \`x\*x\`, \`x\*x\*x\`.
> \- What to do about literals. Do we keep referential transparency (e.g. do the literal ^2, ^3 no check for overflow, but the non-literal one does).
> \- Are we ok with this? Initial performance numbers look like about a 10-20% performance penalty for this change.
>
> cc @JeffBezanson @StefanKarpinski @stevengj @timholy
[This PR would though only notify you of the problem not fix it, though good enough for a debug mode, returning a Float64 by default would give you the right answer, arguably better. Let’s defer that discussion.]
B.
As with Python (and Lisp), Julia’s zip truncates, which is a known problem in Python (discovered in 2020 when the new non-default option was added to 3.10):
> **[Built-in Functions](https://docs.python.org/3/library/functions.html?highlight=zip#zip)**
>
> The Python interpreter has a number of functions and types built into it that are always available. They are listed here in alphabetical order.,,,, Built-in Functions,,, A, abs(), aiter(), all(), a...
> By default, zip() stops when the shortest iterable is exhausted.
> […]
> Without the strict=True argument, any bug that results in iterables of different lengths will be silenced, possibly manifesting as a hard-to-find bug in another part of the program.
I think we should add such an strict argument, and if the debug mode it should be on by default (arguably also on by default in Julia 2.0).
“New in Python” (in case people think Python will not drop anything until 4.0):
> Porting to Python 3.12
> Legacy Unicode APIs based on Py\_UNICODE\* representation has been removed. Please migrate to APIs based on UTF-8 or wchar\_t\*.
> Octal escapes with value larger than 0o377 (ex: “\477”), deprecated in Python 3.11, now produce a SyntaxWarning, instead of DeprecationWarning. In a future Python version they will be eventually a SyntaxError.
and:
> sum() now uses Neumaier summation to improve accuracy when summing floats or mixed ints and floats.
---
### Author:  [@aplavin](https://discourse.julialang.org/u/aplavin)
#### Post date: [August 8, 2023, 12:05am UTC](https://discourse.julialang.org/t/would-people-like-an-introduction-of-a-julia-debug-mode-possibly-on-by-default-in-the-repl-pluto-jupyter/102535/2 "2023-08-08T00:05:15Z")
> [@Palli](#):
>
> The same code in Python (or slightly modified for its syntax gives the right answer).
Numpy does the same as Julia here: both `np.int64(123456789)**3` and `np.power(123456789, 3)` return `-2204193661661244627`, exactly as Julias `123456789^3`. If anything, the difference between builtin slow calculations (with bigintegers) and fast numpy ones are potentially confusing in Python. In Julia, it’s always fast with the same results.