(Both literally and figuratively!)
When "significant whitespace" is at the top of someone's complaints about Python, I'm immediately done hearing about their superficial criticism of the language.
if(condition)
do_thing1();
do_thing2(); //not in the if!
do_thing3(); <<body>>=
if 1 == 1:
print('1 == 1, shocking!')
<<function>>=
def foo():
<<body>>
def foo():
if 1 == 1
print('1 == 1, shocking!')
Maybe you're thinking of mixing Python with HTML? Python based HTML templating can be ugly, and the significant indentation of Python is a very poor mix for replacing Javascript in whitespace-agnostic HTML.
Triple quoted docstrings just require that the initial marker (""" or ''') is indented properly (since they are not considered blank lines). All contained text, and the closing marker, can be at any indentation level. This is the cleanest way to include a page of free form documentation, mid anywhere.
Which is a shame, cus otherwise Python is good imo.. I feel like its creator just had a weird whitespace fetish or something.
If you're properly indenting code, then it always works as intended. Proper indentation doesn't come from a desire to make the code work, it comes from a desire to make it readable. It just happens that readable means correct in Python's case.
It literally takes me zero thought to get indentation right. If you can't tell when to start or end indentation level, then I'd question if you know when you need to use an open/close brace in other languages.
I mean, yeah, sometimes copy/pasting code doesn't work precisely as intended, but all you have to do is select the code, hit Tab or Shift-Tab, and any sane editor will add/subtract an indentation level to the code.
If your language requires an IDE, then you have become Java.
That's quite the assumption.
Once I'd become accustomed to languages where automatic formatting is feasible, having to do any of this sort of thing by hand started to feel like a real imposition. I didn't object to this aspect of Python when I first learned it, because it didn't feel much different from writing my C code, but now, after years of clang-format (and Visual Studio's auto format, and gofmt on the occasions I've been forced to use Google Go...) I just can't be bothered. How dare it make me press return. How dare it make me press tab. I have better things to do with my life than what I can only describe as this. fucking. shit.
Good job trying something new out! There is always room for experimentation, if any reason to try to learn something new.
Does it support also braces? :)
IIUC the source is writen as a long heresting and then executed.
Does it have the same speed than normal Python?
Does it suppont numpy, numba and other similar packages that use jit?
Can a function inside the modified code call a function outside? (It may be helpful for porting conde one function at a time.)
Is it possible to do something similar with a decorator instead of a herestring?
>Is it possible to do something similar with a decorator instead of a herestring?
No, this is a fundamental change to Python syntax. To apply a decorator to existing Python code, the decorated code has to compile first, creating a Python object (generally either a function object or "type" i.e. class object) which is passed to the decorator (which is really just a higher-order function with special syntactic support).
But of course, you could write the code to preprocess in a separate file with a different extension, and then have actual Python code which reads and preprocesses it and then evals the result. (The internals could also be written differently, in terms of AST manipulations using the "compiler services" part of the standard library. But this way is probably easier.)
On Linux, you could also have a top-level script which does those steps for a specified input filename, and then specify that script in the shebang line for the Dopy code file.
> the source is written as a long herestring and then executed that's correct but only for single file modules. you can actually have a python like structure comprising entirely of dopy files and it will be compiled in place or in temp dir and executed as a normal python package with distributed source
> Does it have the same speed than normal Python It's just a transpiler so the code is actually executed by the python interpreter itself. So same speed as python with an extra build step
> Does it support numpy, numba, other packages that use jit? Not now
> Can a function inside the modified... Certainly
> Is it possible to do something similar with a decorator instead of a herestring? Could you explain?
But back then I was just using vim with a nicely configured .vimrc. Linters weren't really a thing, or at least not neatly integrated into my editing experience.
Nowadays I write Rust in vscode and I love braces. Rustfmt just formats my code every time anyway, so I don't have to care about indentation and braces are placed where they should be. I spend zero time caring about code formatting, outside of configuring rustfmt.toml once per project or the occasional #[rustfmt::skip] for codeblocks which I really want to format in a specific way outside of the linter's configured rules. I also have the benefit of the compiler screaming at me if I forget a brace, pointing to the exact error including telling me when indentation is suggesting a brace is missing! :O
Moreover, I'm much more proficient in vim, and the single hotkey % is reason enough to want to favor braces. Coupled with how often I paste code into Claude, V$%,y has become muscle memory (visually select this whole line, go to the end of the line, then expand the selection to the line matching the closing delimiter under the cursor, then yank everything into the system clipboard with <leader>y)...
On occasion, I go back to Python for some side project and the whole experience feels... weird. If braces before LSPs and linters was the stone age, then Python feels like the iron age and I'm living in the future with a compiler that is incredibly talkative and helpful. I'm never going back.
I consider this to be both totally sensible and completely impractical :)
def function(x) do
end
> I also have the benefit of the compiler screaming at me if I forget a brace, pointing to the exact error including telling me when indentation is suggesting a brace is missing!
What the compiler is telling you here is that the braces are superfluous, because the indentation is already describing the structure correctly. So why bother?
My take is that in the (amazing!) new world with near universal usage of standardized linters, this whole debate is stale, it just doesn't matter either way. Everything is indented properly, whether or not it is necessary for correctness. So whether there is a bit of additional bracing or not, who cares?
[0]: https://khinsen.wordpress.com/2015/09/03/beyond-jupyter-what... [1]: http://www.literateprogramming.com/
Your argument became: By adding delimiters, even Python can play well with other languages. /s
Also, Python has a great auto-formatter, Black.
Since you added "real" in there, no argument really matters. But regardless, it's funny you say that, as Python current style guide (https://peps.python.org/pep-0008/) outlines 4 spaces as the one and only correct way of writing Python code.
Sure, PEP8 an other standards prescribe spaces, and I of course always use industry standards myself too. I'm just saying that there is no technical merit for that demand. The water pipe in the monkey cage has long been shut down. The only reason to demand spaces for indent now is circular - that other standard is demanding them, therefore we need to do the same, and that other standard uses the same circular logic himself.
I’ll give you the benefit of the doubt, this sounds very curious.
def my_func():
another_func(lambda: ...)
def my_func():
def inner(): ...
another_func(inner)
@foo.on_click
def foo_clicked(): ...
def do_on_click(): # What's being clicked?
foo()
bar()
backup_system_panel.reset_button.bind(on_click=do_on_click())
Sometimes in other contexts it does make sense to do, but with other languages you can choose to pre-declare and name it or not. In python often you see code with all the error handling lambdas up top before you even know what is going on, when exceptions aren't a good fit.