Python 3.11 Performance Benchmarks Are Looking Fantastic (phoronix.com) 205
"Besides new language features and other improvements, Python 3.11 performance is looking fantastic with very nice performance uplift over prior Python 3.x releases," writes Phoronix's Michael Larabel. From the report: Python 3.11 has been baking support for task groups in asyncio, fine-grained error locations in tracebacks, the self-type to return an instance of their class, TypeVarTuple for variadic generics, and various other features. Besides changes affecting the Python language itself, Python 3.11 has been landing performance work from the "Faster Cython Project" to speed-up the reference implementation. Python 3.11 is 10~60% faster than Python 3.10 according to the official figures and a 1.22x speed-up with their standard benchmark suite.
The Python Docs cover some of the significant performance improvements made for this upcoming release. The formal Python 3.11.0 release isn't expected until October while multiple betas will come through July and then at least two release candidates in the following months before early October.
The Python Docs cover some of the significant performance improvements made for this upcoming release. The formal Python 3.11.0 release isn't expected until October while multiple betas will come through July and then at least two release candidates in the following months before early October.
performance increases are nice, but ... (Score:5, Insightful)
The performance increases are nice, but, as a comparison, I have a program used in my laboratory that I actively maintain. It's part of a hard real-time system. It's written in VB6. Yes, VB6. And yes, I continue to develop it under Win 10. The IDE isn't perfect, but it works. I decided recently that it was time to move forward by a couple of decades and re-implemented the core of the application in Python 3.10.
The result?
Python is about 50% slower than compiled VB6, even after throwing every efficiency trick and JIT package I've found at it, and has far more timing irregularities (from the CG, I presume). It's bad enough that it cannot be used for the application.
Python with all the modern tricks is less efficient than VB6 with it's crapola compiler that doesn't even do common subexpression elimination. I'm going to repeat that to make it sink in: VB6's compiler is so bad that it doesn't do even the most basic source-to-source optimizations like CSE. But it produces faster code than Python. If you use straight Python without the de rigeur efficiency packages like Numpy, it would be far, far less efficient than VB6.
Curious, I had a look at the intermediate C emitted when compiling Python with one of the JIT systems. Oh. My. God. It's like these people never studied. Sure a performance boost of 10-60% from 3.10 to 3.11 is nice, but to be competitive, Python needs an order of magnitude improvement to just keep up with one of the least efficient languages ever.
Re: (Score:3)
Python is about 50% slower than compiled VB6, even after throwing every efficiency trick and JIT package I've found at it
Does that include running it in PyPy? Considering that PyPy is at 3.9 language level, I'm assuming not.
Re: (Score:3)
I am surprised that anyone still develops in that dated language last released in 1998. I am glad to be rid of it.
> Python is about 50% slower than compiled VB6
VB5 onwards had native code compilers. VB6 wasn't slow at all. It was closer to managed C++. Benchmark p-code compiled app with Python since they are both interpreted. That would be apples to apples comparison. It might still be faster than Python since it was more statically typed.
The problem was that VB was a terrible scripting language. Very in
Re: (Score:3)
I have played a bit with real-time programming in Python, and in my experience there is no sane way to do it in Windows (I expect you were running it in that OS since you start from VB6). If anyone has any tips & tricks to add here, please feel free. I have a feeling that the problem was in the Windows scheduler. Possibly there are Windows specific API's to have more fine-grained control over execution, but by default if you e.g. sleep for 1 ms you return 15+ms later.
Under Linux, the performance was m
Re: (Score:2)
To my knowledge, hard realtime has never been practical on stock Windows, though I believe they may make special editions that are suitable.
Some definitions of soft realtime have been possible for a while, although I'd never have done it in VB6 even in the 90s, because of nondeterministic garbage collection.
Please correct me if I'm wrong. I've only ever been a consumer of realtime software (mostly audio creation), never a creator. And if I were, I would strongly prefer to use Linux or QNX, where I can get
Re: (Score:2, Insightful)
The performance increases are nice, but, as a comparison, I have a program used in my laboratory that I actively maintain. It's part of a hard real-time system. It's written in VB6. Yes, VB6. And yes, I continue to develop it under Win 10. The IDE isn't perfect, but it works. I decided recently that it was time to move forward by a couple of decades and re-implemented the core of the application in Python 3.10.
The result?
Python is about 50% slower than compiled VB6, even after throwing every efficiency trick and JIT package I've found at it, and has far more timing irregularities (from the CG, I presume). It's bad enough that it cannot be used for the application.
Python with all the modern tricks is less efficient than VB6 with it's crapola compiler that doesn't even do common subexpression elimination. I'm going to repeat that to make it sink in: VB6's compiler is so bad that it doesn't do even the most basic source-to-source optimizations like CSE. But it produces faster code than Python. If you use straight Python without the de rigeur efficiency packages like Numpy, it would be far, far less efficient than VB6.
Curious, I had a look at the intermediate C emitted when compiling Python with one of the JIT systems. Oh. My. God. It's like these people never studied. Sure a performance boost of 10-60% from 3.10 to 3.11 is nice, but to be competitive, Python needs an order of magnitude improvement to just keep up with one of the least efficient languages ever.
Wow. Screw, meet hammer.
I mean really? You wrote a part of a "hard real time system" in Python? And you're wondering what went wrong? And complaining Python might not be the best tool for that job?
Well, no kidding. Protip: Javascript might not be what you should be looking at either.
Re: (Score:2)
You're comparing a compiled language designed for 25 year old computers, with a (usually) interpreted language, that is vastly more powerful and flexible, and supports many different programming paradigms, but, for that very reason, requires things like the global interpreter lock, garbage collection (exists in VB6 but primitive), and so forth. And which therefore also can't support some of the optimizations that existed even 25 years ago. It sucks that Python is slow as a result, even by scripting langua
Re: performance increases are nice, but ... (Score:5, Funny)
Does it really need an order of magnitude? You say it takes twice as long, not 10x as long.
Well, he's running it on a binary computer after all, not on a decimal one.
Re: (Score:2)
twice as long "even after throwing every efficiency trick and JIT package I've found at it"
Regular Python would need an order of magnitude speedup. I agree by the way, Python is slow as hell.
Re: (Score:3)
In my experience, Python code is two orders of magnitude slower than similar code implemented in C++ or Go (about 50 times slower than Go, more than that for C++).
After optimizing a simulation loop in C++, it gave a substantial speedup to change the main Python->C++ entry point from "run for one unit of time" to "run until higher level feedback is required" because the Python overhead for even a short loop was relatively lengthy. Even then, there was substantial malloc()/free()/kernel-VM overhead for al
Why the focus on performance? (Score:5, Funny)
Re:Why the focus on performance? (Score:5, Insightful)
Python is far more widely used than just as a "scripting language".
You can certainly argue that Java andGo are better suited to large applications, but that doesn't stop people writing large applications in Python, and it is vastly superior to PHP or Node.js.
Re: (Score:2)
Re: (Score:2)
Most "big applications" these day are web apps, and there really isn't a lot of alternatives to Django/Python outside of horrid productivity murdering J2EE/whatever the C# equiv is behemoths. Ruby on Rails never really scaled to that kind of complexity, PHP.... just no, and NodeJS is genuinely illsuited to anything beyond a fairly rudimentary degree of "enterprise" complexity.
And people have been doing just fine with Django for well over 15 years now. I recently was part of a team that did a big sweep throu
Re: (Score:2)
Most "big applications" these day are web apps, and there really isn't a lot of alternatives to Django/Python outside of horrid productivity murdering J2EE/whatever the C# equiv is behemoths. Ruby on Rails never really scaled to that kind of complexity, PHP.... just no, and NodeJS is genuinely illsuited to anything beyond a fairly rudimentary degree of "enterprise" complexity.
And people have been doing just fine with Django for well over 15 years now. I recently was part of a team that did a big sweep through a bunch of crusty old Java/Oracle apps at a govt department I was working at replacing them with Django apps,. and management was absolutely floored that we where taking 15 year old apps that they had spent millions on, and with a team of 5 guys replacing them completely in a space of 2 thee months. One of them had a 70 page form (I know I know, governments lol) that required a complicated workflow of authorizations through multiple departments , physics simulations (It was for controlled burnoffs) and other stuff. Two months it took to replace it. And it took me a week to handover my corner of the code base to the guy replacing me after I golden parachuted out of that place. He picked it up straight away.
Python is just fine for big apps in a professional setting
Python is good at Rapid Application Development.
That doe snot make it good at everything. That does not make it CPU efficient. Pick your poison, fast to develop, more resource cost and an upgrade treadmill where the python WILL break after a python upgrade or slow to develop with less chance of the toolchain upgrades causing an error.
Not every tool is good for every situation. You can put lipstick on a pig, but it's still just lipstick. I mean there could have been a framework written in C that had a
Re: (Score:2)
>Python is far more widely used than just as a "scripting language".
But that's what he's saying, that using it as more than a scripting language is an issue, because no matter how much people want it to be more than a scripting language, that's exactly what it is.
As a scripting language, it's OK. It has powerful syntax, lots of cool third-party libraries, but runs slow as fuck and is crippled by using whitespace as flow control.
Re: (Score:2)
You can certainly argue that Java andGo are better suited to large applications,
Have you used Python? I could argue that any language is better suited to large applications.
but that doesn't stop people writing large applications in Python,
Those people are unbalanced. Python is the worst choice for any application, let alone large ones! Aside from the bone-headed design and endless breaking changes, it's also the slowest and least efficient language I've ever seen.
and it is vastly superior to PHP or Node.js.
I find it telling that you picked two broadly-hated niche languages to compare against a general purpose language. Still, in their respective domains, Python lags far, far, behind.
Re: (Score:2)
You can certainly argue that Java andGo are better suited to large applications,
I dunno about that, there's some real stinkers out there.
Re: (Score:2)
You can certainly argue that Java andGo are better suited to large applications
I'd argue that recent C++ is better than either of those for large applications.
(And by "recent" I mean C++11. C++20? Even better...)
Re: (Score:2)
C++20? Even better
Cool; so once we'll have compliant C++20 compilers in 2026, we'll all enjoy it. ;)
Re: (Score:2)
I tend to assume that everyone left on /. is a jaded cynic, so it's nice to run into an optimist occasionally.
Re: (Score:3)
C++20? Even better
Cool; so once we'll have compliant C++20 compilers in 2026, we'll all enjoy it. ;)
The chart is fairly complete since about 2019:
https://en.cppreference.com/w/... [cppreference.com]
Some compilers already have VC++23 support:
https://en.cppreference.com/w/... [cppreference.com]
Re: (Score:2)
Modules: partial...partial...none...none
Come on, catching up with Modula-2 from 1970s (!!!) in toolchain design quality is literally the most important change that will have happened to C++. You can't possibly say that support for C++20 is "fairly complete" without modules any more than a living person is "fairly complete" without any intestines.
Re: (Score:2)
Nobody ever wrote big programs in Modula-2.
(or any other language in the 1970s - there wasn't really the disk space)
One look at the size of the precompiled header folder in a big visual C++ project will tell you where the problem is. It's about 4Gb on the program I'm working on right now. I usually put it on a separate drive to avoid constant backing up of 4Gb of regenerateable data.
Re: (Score:2)
You can, but I generally don't. There are things about Python that don't scale well to larger systems, such as dependency management, lack of static typing, breakage between Python versions, the global interpreter lock, and so forth. I know that there are workarounds for most of these, and they work well for smaller scripts and systems, but become more and more painful as a system grows in size, scope, usage, and importance.
Once any of these things starts being a serious issue, I tend to want to transitio
What is a "Scripting" language anyway? (Score:3)
It used to be thought that in order to be efficient a programming language had to be difficult to use like C. And that the alternative was easy to use Scripting languages that were slow.
But long ago the best Lisp compilers could match C for speed. And since then C#.Net and Java made the idea popular. Static typing, modern generational garbage collection, good JIT compilers. (Java is still a bit slower for bad reasons, but conceptually there is no reason. C# is better.) (And people tend to write more c
Re: (Score:2)
Re: (Score:2)
> C# is a turd in terms of performance (I use it very frequently) if you compare it to C++.
Why would you compare it to C++? C# is comparable to Java.
> Making Python more like C++ using weird "static typing", and via getting more performance using ugly syntax/libraries/vectorisation, is not the answer.
It is. It has worked quite successfully. Python became extremely popular BECAUSE of its syntax/libraries/vectorization.
Re: (Score:2)
Re: (Score:3)
I am not making an argument ad populum.
What constitutes superior to you is different from what is superior to someone else.
Python met the needs of the data science community very well. The needs weren't performance, safety etc. It's easy to teach, read, write and debug. It's community is friendly and values simplicity. Simplicity is important when the complexity focus is elsewhere.
It's technical deficiencies aren't at the heart of the matter.
Re: (Score:2)
I am not making an argument ad populum. ...Simplicity is important when the complexity focus is elsewhere.
It's technical deficiencies aren't at the heart of the matter.
Best comment here, and I think this is where professional IT people sometimes miss the point.
Scientists grok, and even prefer, how loops get hidden inside numpy syntax. If someone made them learn C++ and use it instead, you would find them overriding operators left and right [little joke there].
For scientific code, most of the work is hidden inside vectorized calculations, so that the slowness of loops at Python level tends not to matter. It's telling that most scientific code not in Python is in Matlab or
Re: (Score:2)
Have you used any scripting language that you liked?
Python fares well compared to Perl, R and Ruby.
Re: (Score:2)
Re: (Score:2)
Python's error messages are easy to interpret for data scientists.
Python is easy to debug as long as one does not get too clever with it, which most data scientists don't.
I agree that Python isn't optimal for large programs, unless discipline is used. Statically typed languages scale better, performance aside, for maintainability. Python works best when most of the lifting is done by convenient libraries. There are better alternatives today when that isn't the case.
Scala, Nim, Julia are all more expressive
Re:What is a "Scripting" language anyway? (Score:5, Interesting)
Why wouldn't you compare C# to C?
I did a benchmark long ago rewriting a numerical optimization fragment in C# from C++. The C++ code was production.
The C# was about 30% faster than C++.
Turns out the C++ programmer forgot to inline a subroutine, which C# did automatically. You could argue that was bad programming, but in practice good tools work better. When fixed, the C# code still ran about 5% faster after an initial JIT startup time, for reasons unknown. And .Net has become much better since then.
Re: (Score:2)
I can bring Java anecdotes of the same nature.
That still does not make C# or Java the same class as C++ or Rust.
Re: (Score:2)
Re: (Score:2)
That is not how C++ works. It uses the old 1950s idea of linking modules compiled individually. The only thing the compiler sees is the source fed to it.
So if code in one module calls a function in another module, it cannot inline it. The only way in lining between modules can happen is if the programmer manually puts it into a header file.
Where as C#.net and Java do whole of program optimization, of just the bits that are CPU intensive.
Re: (Score:3)
Re: (Score:2)
But in C# you can write, test, debug, and deploy code a LOT faster than you can in C++.
Sometimes that matters more, and sometimes it doesn't.
But in 30 years of app (not systems) development, I've RARELY encountered a problem for which the combination of a memory-managed language, plus possibly very small bits of C, was not an acceptable solution.
Re: (Score:2)
I've never written anything in Python and found it too slow.
If I'm using Python, it's in part because I know that I'm not doing anything CPU-bound, nor heavily multithreaded, but more likely am I/O bound most of the time (disk, network, mouse, keyboard, etc.), and in that case, Python being on the slow side causes no discernable performance impact in this situation.
If I think I need performance in CPU- or memory-bound situations, beyond what I know Python can provide, then I simply use something else.
No one
Re: (Score:2)
> No one single tool is right for everything.
If the alternative is C/++ then that is true.
However, with things like Java and C#.Net you can have the best of both worlds. Safe, garbage collected code running native compiled.
C/++ has a place on things like micro controllers. And Java has some idiot issues which make it not quite as fast as some C++. But both are obsolete for mainstream programming.
Re: (Score:2)
Python is better for ML / NLP applications
Only because it happens to have some handy libraries* for that and non-programmers can somehow muddle though using it. There's nothing about Python in itself that makes it good for that.
(*) Libraries which aren't written in Python.
Re: (Score:2)
Python is better for ML / NLP applications
Python is an objectively awful language for ML. The only reason anyone uses it is TensorFlow, which is crippled by its needless dependence on Python. What a waste.
Re:Why the focus on performance? (Score:4, Insightful)
What's being butchered? If it's faster, how does that hurt you?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
You have no idea how ridiculous it sounds if you advice that a scientist use a "GPU kernel" instead of tensorflow or cupy.
In maybe 0.01% of the cases, they may farm that job to coders like you, but for everyday scientific analysis, a GPU kernel is arcane and completely unnecessary.
Re: (Score:2)
Re: (Score:2)
They are indeed wrappers... transparent wrappers. There is no code difference between tensorflow running on the CPU vs. GPU. Where and how it runs is an implementation detail. A scientist or mathematician thinks in terms of matrices, not machine instructions. It is the job of a software engineer to abstract that away so that they can focus on what's important to them.
No one does heavy math in pure Python. Everyone uses numpy etc. Numpy is more expressive than regular Python, which barely just got matrix mul
Re: (Score:2)
Depends, if it's the implementation details causing speed up, then absolutely, it doesn't drive any change to the programmer. Nothing to lose there.
There are of course language features to use that muddy the 'easy' waters a bit to let developers accept more restrictions for the sake of better performance, but the 'simple' world (no types, mix-typed lists, classes based on dictionaries, etc) is still supported. You could make the argument that by the time you start heavily using the features that try to pr
Re: (Score:2)
Attempting to answer your question seriously, but it's because of bad metrics of "performance". The time to develop the solutions should be the real focus, but because they want to reuse those solutions many time, the execution time then gets dragged into it.
traceback vs error msg (Score:3)
That's great!
I'm looking forward to the day when python devs understand that back traces are a debugging tool, not an acceptable error message in a released program...not even for an early or beta release.
A traceback is just far too many lines of useless noise to an end user, it doesn't tell them what went wrong or why or even hint at what they might do to fix or avoid the problem in future. A user wants to see something like "Division by Zero error on line nnn of filename.py", not 50+ lines of noise hiding that error msg.
Python's default should be sys.tracebacklimit = 0 and explicitly over-ridden by the programmer only while they're actively debugging their code, or via a --debug or --verbose option. That would, hopefully, encourage python devs to write useful error messages, like programmers do for other languages.
Re: (Score:2)
No, the stack trace should be the default. Only in a serious application might you put that to a log file instead. There is no such thing as a fully debugged program.
Re: (Score:2)
No, the stack trace should be the default. Only in a serious application might you put that to a log file instead. There is no such thing as a fully debugged program.
Yes, there is such a thing, it's called "what the users run". They won't be debugging it, so it is "fully debugged", as in, won't be subjected to any further debugging (note: that's very different from bug-free). If they report bugs you can debug them on the development build which does output stacktraces.
Re: (Score:2)
When you get that support call "I gone and done somefin and it don't go" having that stack trace is invaluable.
I actually do a lot of VBA work for which I spent some effort adding an end user stack trace facility. Very useful in practice.
Re: (Score:2)
That's why it should be logged to a file rather than to the screen. You want your hypothetical semiliterate user to send you a file rather than read off the stack trace from a console or text box somewhere.
And arguably, if an exception backtrace is enough detail to figure out where your bug is, you shipped crap code. Ideally, the logic flaw is more subtle and history-dependent than that, so you should need the kind of specific context that a log file would provide.
Re: (Score:2)
Actually, users ship screen shots.
And most bugs are with libraries being used rather than simple bugs in code. A stack trace is invaluable.
Re: (Score:2)
Actually, users ship screen shots.
And most bugs are with libraries being used rather than simple bugs in code. A stack trace is invaluable.
You mean the screenshots where the whole error is truncated because it didn't fit in the box and you can't tell what it is because you didn't bother to add proper logging to your application? An application is not finished until the logging is done. Just use log4j, it's easy to set up and mature. and having easy to read error codes allows users to fix configuration errors based on a knowledge base. This reduces cost to support and makes YOU money.
Re: (Score:2)
nope. Because it is easier for users than finding the log files. And because I make the box as big as needed and do not clutter it up.
Re: (Score:2)
And you can do that as a developer, but you have to actually set that up. Languages can't make any assumptions about writing to disk until the developer designates where to put it.
So if a programmer was lazy and there's a stack trace, might as well dump it to the screen, it doesn't have a better idea what to do by default and 9/10 times the error by itself is useless.
For comparison, the answer in C in *nix systems was to dump core to wherever, but that's almost unheard of by default now, and generally ulim
Re: (Score:2)
It's not my code. It's code by python devs in general. #notallpythondevs #butmostofthem.
And what you suggest is pretty much exactly what I want other python devs to do, show useful messages rather than traceback spew. I am glad that it exists. but it should be hidden behind a --debug or similar option.
I have no problem with python making that information available. It can be invaluable while debugging.
My problem is that most python developers are too lazy to write decent error messages, short and to the p
the bad news is.. (Score:2)
they are changing from print("Hello world!") to print[{"Hellow World"}] .. python developers will switch within days, I am sure of it.
Re: (Score:2)
I hope you're kidding. Why they can't figure out something as simple as 'print' I'll never understand...
Still 3x slower than PyPy (Score:3)
CPython is still 3x or 4x slower than PyPy.
Re: (Score:2)
For the subset of python ecosystem that PyPy supports, which is why we continue to care about CPython, which supports the entire ecosystem.
A long-awaited change (Score:5, Funny)
Finally Python 3.11 For Workgroups!
I can't wait for Python 95!
Workgroups (Score:2)
Finally, a Python good enough for workgroups.
Languages are hard (Score:2)
When evaluating languages, syntax, package ecosystem and community are just a subset of the criteria.
One should check it's typing system, runtime requirements, memory handling, library maturity, optimization capabilities, standardization committee members, licensing restrictions, etc
Generally, the adoption of a language based on "speed of feedback" on a successful implementation is the Sugarbomb Candy Cereal of programming. All bright colors, marketing pitch and self-taught hard drivin' fans of the co
Re: (Score:2)
It's only the most popular programming language in the world by a wide margin [github.io] but yeah, whatever.
Re: (Score:2)
Well, IMO the fact that two of the top three languages in your link are Python and Javascript isn't a commendation for either of them. It's rather a bitter indictment of the dismal state of modern software industry...
Re:Yay! (Score:4, Insightful)
Re: (Score:2)
Well, IMO the fact that two of the top three languages in your link are Python and Javascript isn't a commendation for either of them. It's rather a bitter indictment of the dismal state of modern software industry...
The difference is that there are other choices besides Python for general-purpose programming. If you're doing any non-trivial web development, you're pretty much forced to use JavaScript because that's been the only language that web browsers support.
Re: (Score:2)
That's a pretty debatable methodology, isn't it? An unpopular but confusing language will win over a more popular one that people learn easily.
Re: (Score:2)
Yep. Most people eat junk/garbage food but that doesn't mean it's a good idea.
PEP8 line length limit is worse (Score:2)
For a space-delimited language this must surely rate as one of the most bone-headed decisions in computer language conventions for decades.
Re: (Score:3, Insightful)
It also makes sense in 2020 where an easy to follow scheme that doesnt leave you counting curly brackets helps visually organize complicated code.
This horse got flogged to death 30 years ago. Give it up. Nobody cares anymore.
Re: (Score:2)
If only there were editors that showed you curly bracket structure visually...
Maybe Elon Musk could invent that technology for us.
Re: did they fix the indentation nonsense yet? (Score:2)
conversely, dealing with whitespace indentation is also a lot easier if you have a modern editor that supports itâ¦
automatic syntax recognition is just great in general! not much to do with python specifically though.
Re: (Score:2)
I used Python for the first time today, in fact. Whose idea was it to make range(a,b) work like a hypothetical range[a,b)?
Re:did they fix the indentation nonsense yet? (Score:4, Insightful)
Everyone who wants len(range(a,b)) to yield a sane answer. You know, like in C++, and /many/ other programming languages.
Re: (Score:2)
Whose idea was it to make range(a,b) work like a hypothetical range[a,b)?
Some random dude's: https://www.cs.utexas.edu/user... [utexas.edu]
Re: (Score:2)
THAT'S what I wanted to post. Thanks. Bookmarked.
Re: did they fix the indentation nonsense yet? (Score:2)
what a nice essay, it hits all the points in exactly the right order so as to minimize the length. i wonder who wrote it.
Re: (Score:2, Interesting)
Agree that using whitespace for indention is beyond idiotic. In code it is common to have "dual" flow:
* Main code + Debug Code
A lot of operations also have "duals", such as push/pop, etc. In Python this would be an error which is utterly retarded.
Re: (Score:3, Insightful)
A lot of operations also have "duals", such as push/pop, etc. In Python this would be an error which is utterly retarded.
This. Being able to use indentation contextually can make source code a lot more readable. Whitespace shouldn't have any syntactic meaning.
Re: (Score:3, Interesting)
> Whitespace shouldn't have any syntactic meaning.
^^ THIS 1000%.
To give an analogy: Could you imagine the strange looks you would get if you told a Mathematician that these two equations were different? They would think you were utterly stupid:
Yet Python does exactly this insanity.
It is almost if someone got burnt by an extra semi-colon in C's "if" so they had a knee-jerk reaction to "fix" the problem but they never asked anyone who had been programming for decades if their half-baked ide
Re: (Score:2)
> Whitespace shouldn't have any syntactic meaning.
^^ THIS 1000%.
To give an analogy: Could you imagine the strange looks you would get if you told a Mathematician that these two equations were different? They would think you were utterly stupid:
Yeah! How dare someone tell me that x += 1 is valid, but x + = 1 isn't!
Re: (Score:2)
I would implement this using a contextmanager and then use with. It would allow the indentation, you could nest them, and it would make sure the context is closed.
Pythonic way (Score:4, Insightful)
A lot of operations also have "duals", such as push/pop, etc. In Python this would be an error which is utterly retarded.
Though the way Python expects thing to be designed for duals is rather different.
i.e.: the second part is most often preferably handled by the destructor of the object created by the first part.
and you manage precisely the lifetime of the object using with.
filesteams are exaclty handled this way (close() is implicitly called when the file object is destroyed).
But otherwise, yes I agree with you:
Python deprives the possibility to use indentation to convery some additional information.
On the other hand this fits with the general zen of python to reduce confusion and make things more obvious and thuse there should be only 1 single structure (thus code follows indentation) and not 2 parallel ones (C/C++/etc. bracket for code, and indentation to convey some higher level meaning to the reader).
Re: (Score:2)
Call it a matter of taste. Personally, I love indentation for grouping. It means code does exactly what it looks like it does. C lets you indent your code however you want, but in practice most code falls into two categories: code where indentation strictly follows execution, and code that's confusing to read. Using your example, I don't see any reason to prefer
over
Any
Re: (Score:2)
The best part is that you still have to put colons at the end of lines to tell Python that the next line is supposed to be indented.
And let's not get start on the fact that it pretty much forces you to use spaces instead of tabs* so keeping proper alignment is a constant chore.
(*) because if you don't then dragons will emerge later.
Re:did they fix the indentation nonsense yet? (Score:5, Insightful)
It's more than just silly, it's been well-accepted by the field to be a dumb idea, and deciding to use it as I-wanna-do-it-this-way-cause-I-think-its-cool is the mark of childish naivete and contrarianism.
It's well accepted amongs Python bashers for sure, but it's actually the kind of indentation that an auto formatter performs on most other languages.
I'm very happy that Python enforces this, because I've suffered enough code in other languages where the formatting did not always follow the logic and because of that, missing BEGIN/END block structures created hard to spot bugs.
If I'd start a new language in 2022 I maybe would not give white space a syntax meaning, but enforce strict formatting rules to force the white space to follow the program logic at all time.
That tabs vs. spaces however is bad and it would have been better to avoid that confusion.
Re:did they fix the indentation nonsense yet? (Score:5, Insightful)
Here's an idea: just go and create a language that does everything right. Then release it, and you'll be worshiped until long after you die. Oh wait, no you won't, you will be flabbergasted by the sheer amount of rotten tomatoes thrown at you for doing things wrong. No matter what you do, other people have different needs and preferences, and they will tear your work to pieces.
Yes, Python has a legacy. It's slow. But it's really fast to write a python program that can do something you'll need much more time to write in another language. It's an extremely powerful language. For me the most annoying part is packaging/distribution. That's a real mess at the moment.
Ob Camel joke (Score:3)
But it's really fast to write a python program that can do something you'll need much more time to write in another language.
Not in Perl.
Though reading it back after writing it is going to be indeed slower than in Python.
(aka write-only language).
Also Perl is the fastest language where you can get syntactically correct code extremely fast just by having your cat walk across the keyboard.
Re:did they fix the indentation nonsense yet? (Score:5, Informative)
The reason it is popular in science is because it allows you to very very rapid prototyping and does not have a "toolchain". Because of this, it has a lot of packages available , which makes it an even better language for rapid prototyping. It also can use C-based libraries, which makes it very useful. In recent years, its integration with Jupyter notebooks and VS Code makes an excellent set of IDEs available for it.
It is essenitally
1. Matlab,and Mathematica without the cost,
2. C without pain but with the possibility to get near as good performace by using someone elses C-based package (Numpy for eg.).
It's basically really really useful for someone who cares greatly about implementing a certain computation for analysis / processing etc. but does not care so much about if it is the most optimal and efficient way of doing so.
Re: (Score:2)
On the plus side it prepares you for the hell that is YAML.
Re: (Score:3)
They don't compare Python to Lua because it would make Python look really bad. Lua is small and fast already, but LuaJIT is ridiculously fast. It easily outperforms other scripting languages. Their respective designs have a lot to do with performance, of course, which is why Python will simply never be as fast as something like Lua.
I don't know why Lua isn't more popular. It has a few warts, like any language, but having nasty warts doesn't seem to be holding back Python...
Re: (Score:2)
Yes, there were breaking changes between Python 2 and Python 3. "Has breaking changes" is the definition of a major version, though.