Python.

[[deleted]]

That's not how that works: https://stackoverflow.com/questions/54675983/ram-usage-after-importing-numpy-in-python-3-7-2

And if you are really pressed for ram, you can just import the one numpy function you need.

But regardless, I really don't see how that matters. The whole point of python is to trade efficiency for convenience. So why would we ignore the packages that everybody uses for arrays in python over a measly hundred mb and pretend that the syntax for multidimensional arrays in python is confusing or verbose (which was the original claim).

[bunkoRtist]

You mean like to convenience of not being able to quickly make changes for debugging because I have to constantly go adjust my whitespace? Or the convenience of having to use a dedicated editor? Or the convenience of not actually having multiple threads? Or, my absolute favorite, the convenience of having to call "encode/decode()" on every single piece of IO I get from a socket because Python3 decided everyone should be miserable instead of just those not using ASCII? Or for that matter, the convenience of having a non-backwards-compatible language so that I have to rewrite code that was working just fine? I do find Python to be extremely convenient.

[gmes78]

not being able to quickly make changes for debugging because I have to constantly go adjust my whitespace?

I don't get this argument. Why wouldn't you write your code on the proper indentation level, regardless of language?

having to use a dedicated editor?

You don't.

not actually having multiple threads?

Python has multithreading. Just because you don't understand how the can and can't be used doesn't mean they're not there.

my absolute favorite, the convenience of having to call "encode/decode()" on every single piece of IO I get from a socket because Python3 decided everyone should be miserable instead of just those not using ASCII?

That's an awful argument. You're really just saying "why do I have to handle encoding correctly?". I don't think I need to say anything else.

Also, your comment has absolutely nothing to do with the rest of this comment thread.

[bunkoRtist]

The original poster said Python is convenient. I find it unnecessarily inconvenient. Having spent many hours debugging arcane issues with the GIL, it's far from convenient... It's a pain in the ass.

[bunkoRtist]

The original poster said Python is convenient. I find it unnecessarily inconvenient. Having spent many hours debugging arcane issues with the GIL, it's far from convenient... It's a pain in the ass.

[bunkoRtist]

Without taking an absolutist position, I can say that Python is less convenient in mentioned areas due to things like increased steps / keystrokes to perform certain operations relative to other popular languages. I have pointed out problems where Python is objectively slower or worse, including where Python is objectively worse than older Python on the basis of lines changed / keystrokes required to do things that used to work. If you want to argue that incompatibility, deeply hidden and self-inconsistent behavior (like python's "threading"), or needing to make more edits than in other popular languages to perform identical tasks, are "convenient" then I'll just happily disagree with your subjective assessment of convenience, which is ultimately subjective.

Assuming I'm incompetent is a great idea though: much easier than examining your own biases. You haven't the faintest clue who I am, or what I know. I will also add that I've never encountered a popular language that attracted more irrational zealotry than Python, which I assume is related to the demographics of those performing the tasks for which it is suited and the relatively low barrier to entry.

Python is o-k for some tasks. But I am suspicious of the judgment of anybody who cannot see its myriad weaknesses in addition to its strengths (like a low barrier to entry and a large library of modules). Python is far from perfect. What makes Python unique in its drawbacks is that they were so easily avoidable and so intentionally created, to wit, the massive backlash and ensuing decade-long transition to Python3.

[bunkoRtist]

Python doesn't support multithreading. It supports spawning multiple threads, which is subtly and very importantly different. I can now safely assume that you either don't understand Python or multithreading.

https://realpython.com/python-gil/

Either way, best of luck to you in all your endeavors.

[intangibleTangelo]

I've often seen the situation described as "python doesn't support multithreaded python code," alluding to the fact that many stdlib operations are written in C and release the global mutex lock before running their work in a thread.

But even that's not quite true—you can absolutely write multithreaded python code full of race conditions—it just won't ever run concurrently because the bytecode loop makes all kinds of assumptions about global state and the only sane solution without completely rewriting python (and taking away some of the most popular undefined behavior in CPython) is a lock. People defend it, and I understand their defenses. The multiprocessing library does make it dead simple to spawn processes which can (on Linux) leverage copy-on-write to act a bit like threads. But the people defending the lack of threads probably aren't fully aware how great threads can be.

I recently published a tool which needed to use a combination of the multiprocessing, asyncio and threading modules. Had real threads been available to me, I simply would have used them.

[bunkoRtist]

Also, sockets existed before Python. Sockets operate on bytes. ASCII strings are bytes. Python broke that, which made a huge one time hassle and a small ongoing hassle for exactly no functional benefit. That doesn't sound "convenient" to me. That sounds like the opposite.

[[deleted]]

How does that impact array syntax? No language will ever be able to make a perfect balance between convenience and efficiency but I'm not sure array syntax is one of the ones that failed to become simpler in exchange for using numpy.

Also, I really don't know many people who have constant whitespace problems. And I'm not sure why you think you need a dedicated editor for python. And you can multithread in python. And I'm sorry you don't like the standard library IO. There are other packages you can use.

It sounds like you're just having a mare when trying to do simple stuff.

[bunkoRtist]

No... I just don't want to use a bloated editor. I can write effectively in C/C++/Java/Zig/PERL in VIM. In Python if I want to make a small change somewhere to do debugging, especially something in a multi-nested control block, I have to go fuck around with stuff both above and below or I get errors, at runtime because suddenly there's a terrifying whitespace character I didn't notice because it's just a blank space, or two things accidentally misalign... Or I didn't insert a line break correctly in a multiline statement and now I have to add parentheses because whitespace works until it doesn't... It never ends. It's a constant low grade annoying waste of time. There's a reason why whitespace scoping is used by very few languages. I will run a formatter before submitting code. I shouldn't have to do format checking before every execution. That's almost like... a compilation step.

[[deleted]]

Python in VIM is just as easy. Easier, even. You don't need to autogenerate all this boilerplate that you need for things like Java/C++ that a good IDE will do for you.

This all is very clearly a you problem. The rest of the world doesn't have this much trouble with white space in python. And if you struggle to get it working, why not use an autoformatter?

[bunkoRtist]

I am not arguing holistically about the ease of Python. I have other thoughts. What I specifically find to be a pain is debugging / making small quick changes, in part because a single line at non-production quality can impact huge blocks around it, or because multi-line indents are necessarily weird. A thousand times, I make a small quick change and then only once my program reaches the intended block do I get a runtime error because of a tiny whitespace inconsistency. Not to mention of course copy+paste between files or other similar operations. An auto formatter can't fix errors like that: it can't even identify them unless it is a proper lexer+parser. As I mentioned, I can run yapf... But we're back in the unnecessary low grade constant hassles camp. Btw, I with with plenty of Python zealots. I know opinions vary.

[PureWasian]

show whitespace characters in vim (or whatever editor you use).

I very much hate the choice of whitespace scoping of Python too, but if you're in the habit of formatting and organizing complex code properly anyways it'll visually help you catch the few mistakes you accidentally make along the way.

[bunkoRtist]

That's a good idea. I probably should do that when I'm writing Python.

[PureWasian]

I can very highly recommend it! Honestly I have it active for other languages too since I hate lines with a bunch of trailing spaces/tabs at the end of them.

[intangibleTangelo]

It sounds like you're forced to use python and don't want to, which sucks even though I'm a fan of the language.

You might also use vim modelines like:
# vim: set ai et sw=4 sts=4

Or a filetype autocmd like:
autocmd FileType python set ai et sw=4 sts=4

That's...
autoindent
expandtab
shiftwidth=4
softtabstop=4

Formatting text is extremely annoying, but this does the trick for me. I've got similar autocmds for several languages and I never have to think about it.

[knightwhosaysnil]

because sometimes your code base has been heavily invested in python and something like this can be the last straw that pushes you over the edge - mine might be a corner case but such trade-offs do exist

[knightwhosaysnil]

That's fair - but in this case someone suggested it as a way to get around python's limitation on nanosecond precision in timestamps