I would also want some kind of a typing support, ala Pydantic built in. If for nothing else, I would like to know wtf is this function taking in as args.
Can we also run this in a browser!? One can dream.
That experimental library could even be backed by other packages, so you could iterate on the interface while allowing other packages to continue to improve the core. But the assumption is for any clearly solved problem, these “batteries” provide one recommended way to solve the problem, and as of now it’s either the only or at least not the worst way to do it.
Claiming that a language user should be prepared for certain parts of the language to disappear is a perfectly reasonable idea. But in practice it does not work. Because either it can or cannot be used, and if it can't be used it is a waste of time, if it can be used it must be supported.
Once people use a library, there will be pressure to support it forever and the mindshare switch is a real cost. A language bleeds users every time it drops a feature. The Python namespace is still polluted by documentation and tutorials talking about how to do things in v2 too.
But Python has a very different release schedule. Rust's nightly releases nightly and stable every six weeks, while Python only releases once a year. I don't think it could adopt the same model.
Well, it can. That's what you get when there's no official package and you depend on third party packages that change all the time (e.g. common in the Node ecosystem, in GTK+ land, etc.), or are abandoned, etc.
Compared to that, a scheduled, anticipated process for candidate packages to include in the language (or remove eventually) is much easier.
There are other bundles that are very popular for a reason. Conda. That's all you need to know. People want stability of dependencies, not wild wild west on pulling libs from random github repos.
It's not a package manager and it does not provide any environment isolation of its own. Conda provides both of those things, and quite a bit more.
They are totally different tools. Conda is more like Homebrew than Poetry.
What Poetry and Conda have in common is a not-really-bad dependency resolver.
I'd instead aim for a language that supported interface/trait/typeclasses with a huge standard library of those that allowed writing uniform benchmarks and unit tests to every implementation that shipped simple implementations for some of those and made it easy to use different implementations and experiment with them.
This seems like solving just dependency injection instead of trying to solve every library ever, which seems a much more realistic problem to solve correctly, or at least in a way better way.
Every common X means thousands of complex things. There are over 9000 RFCs (insert Vegita meme). Even more popular APIs, libs, algorithms, whatevers.
Even basic support would be near impossible. A constant race between what constitutes basic and releasing it. (Plus upkeep/maintenance, as things continue to evolve at a rather fast pace.) And if the language enjoys at least a minimal level of successful then a lot of non-stdlib packages are likely to become standard by convention.
It's no wonder that new languages nowadays start with minimal stdlibs.
(I just noticed that there's an SMTP server in Python3! It's ... great, I guess. But there's no DNS resolver library. So either the SMTP client (and now server) packages do not handle anything related to DNSSEC / DANE / TLSA / MTA-STS / DKIM / DMARC and others, or they bundle it. Sure, maybe it's enough to outsource these to the upstream SMTP server and the SMTPd package is just for "testing" ... but, this just shows how arbitrary "commonness" is.)
...although that might all be the fault of aws-cli. Which by the way doesn't install on a vanilla Ubuntu 20.04 ami via apt which is just... really really bad.
Aws cli continues the inexplicably horrible aws interface that makes me shake my head at people lauding their might, along with their console.
The console rewrite... anyway, pip seems to be a headache, certainly not as good as gems.
I had a quick look in pip and install order is predicated on requirements order https://github.com/pypa/pip/blob/c188d1f08f1a4a2c0a03e397f15...
I was sad to hear about the change to ReScript though. ReasonML targeting the browser and native seemed nice to me, although I do agree the documentation situation and DX wasn't ideal.
For what it's worth, there are a lot of good interesting languages out there that aren't Python and have pretty good library ecosystems. Kotlin, Elixir, and Elm come to mind. But they don't exactly fit the Python niche.
What you're describing sounds to me like a modernized Common Lisp with commercial backing. Rework CLOS a bit, clean up some of the other crufty old weirdness, and give me a big selection of high-quality well-supported libraries like Numpy, FastAPI, Trio, etc.
The advantage of doing it in some Common Lisp derivative is that things like React JSX are pretty much "free" and wouldn't much seem out of place, whereas in Javascript they need a whole separate build/compilation step and are often portrayed as black magic fuckery.
edit 1: Arguably Julia could be used for a task like this, but its library ecosystem and language runtime are heavily skewed towards numerical computing and data analysis.
edit 2: Raku also sounds like a possible candidate here, but it obviously lacks widespread adoption and last I heard it fell significantly short of Perl 5 performance. I'm not sure what kind of library ecosystem it has nowadays and I doubt we're going to see big commercially-backed library development efforts for it, soon or ever. Perl 5 has a huge ecosystem of course, but it's such a nasty warty language with nasty warty tooling.
use DBI:from<Perl5>;http://gigasquidsoftware.com/blog/2020/01/10/hugging-face-gp...
http://gigasquidsoftware.com/blog/2020/01/18/parens-for-pypl...
http://gigasquidsoftware.com/blog/2020/01/24/clojure-interop...
And you can try it out in nextjournal online notebooks like here: https://nextjournal.com/kommen/gigasquids-libpython-clj-exam...
Right. It clearly doesn't have a strong enough offering at the moment to attract anyone beyond a few early adopters.
> last I heard it fell significantly short of Perl 5 performance
Likewise. I'm pretty sure Perl still roundly trounces it for a lot of operations, especially in regex processing. I think it will need to be significantly faster than Perl before it will have a chance at gaining significantly more adoption.
> I'm not sure what kind of library ecosystem it has nowadays
The raku.land directory has less than a thousand packages and many seem to be jokes, unloved, poorly tested and documented, version 0.x, or even 0.0.x. [0]
The standard library is a different ballgame. It's generally well designed and very large, cutting out the usual blizzard of folk reinventing the wheel for basics. So that's good.
> I doubt we're going to see big commercially-backed library development efforts for it, soon or ever.
I agree.
> Perl 5 has a huge ecosystem of course, but it's such a nasty warty language with nasty warty tooling.
This is where I think Raku's strength lies.
A lot of the effort that went into Raku was to build a platform that could just directly use tooling and libraries of other PLs while insulating developers from their downsides.
That way you get to use Raku tooling, syntax and semantics at the surface level with other PLs' tooling and modules and performance. Kinda like using C code in a non-C PL, but generalized to using code from any other PL in Raku.
The exemplar was supposed to be Perl, but it was also supposed to extend to many other PLs. Starting 7 years ago this became the Inline family.[1]
Inline::Perl is the most mature. Imo it's remarkable. But it was always supposed to just be the first one to get the polish to demonstrate that the approach works and works great. About a year ago the author behind it said it was nearly time to do the same for Python modules. And now I see a GSOC proposal to do that.[2]
The Inlines hide the warts (though you do have to read the modules' documentation to know what their API's are etc).
I think the impact of Inline Python will be huge because it takes away the complaint about reading Perl documentation and code. Instead you read Python API docs but get the benefits of using Raku.
(And, in the wings, there's Inline::Ruby, Inline::Lua, and so on.)
[1] https://raku.land/?q=inline
[2] https://github.com/perl-foundation-outreach/gsoc-2021-ideas/...
While there were some quirks, It worked rather well.
This is offensive. Whether the people who work hard to make and share (for free) half baked libraries are addicted to drugs is really not part of the main thrust of your argument. You could leave it out, save words, and not have distracting comments from people like me while still making your point.
Leaving them out would communicate the core idea, but not the emotional tone they wanted it to have.
(And it's obviously not about literal junkies, it's meant as "random people who don't know what they're doing").
No one in their right mind thinks about people building free libraries on GitHub as nothing but positive thing. Come on. I am offended that you’re offended by this.
Usually, I would apologize for saying something offensive, but I guess someone will get offended on the internet. If I said “Wild Wild West” then may be some Texan would be offended by it.
Intention matters. Smile more and be tolerant, no offense :-)
If you feel love, share love. xx
I know the mantra is that the standard library is where things go to die, but I believe that to be cultural. I still have code running somewhere probably that uses the cgi library, which was perfectly well-suited for a Windows serve where the page in question got an average of seven hits a day, never to scale much beyond that (you'll have to trust me on this, for amusement I reviewed ten years of logs for just that page to find nothing out of the ordinary, and there are reasons it would not need to "scale" in the future).
Each library and each string-formatting method and so on is a choice, and those choices impose a lot of speedbumps and cognitive friction.
I definitely think they’re onto something. Dependencies are a hard problem to solve.
Modern build tools like gradle work great at resolving deps, until they don’t and at that point we’re in for a world of shock at just how complex dependency resolution can be in large projects.
The facilities provided by a browser are almost (but not quite) a complete superset of those provided by an OS. file io, peripheral io, etc. Can all be done via the browser. Additional facilities are provided too (security/sandboxing).
Now a common model has arrived (dom + js) allowing multiple browsers to just run your app.
I’m not sure browsers are faster (there was a thing called pepper api in chrome and nacpi or something in firefox - i’m not familiar with the space) that allowed native code to run.
I’m not sure browsers are generally faster than native OS binaries, but they are an easy to deploy to environment that doesn’t need syscall emulation like freebsd can do for running linux binaries.
Why not let the OS do more and more of the complicated technical stuff, simplifying the deployment of web apps because now we don't have to know a thousand different bloated libraries, just a slowly updating set of OS APIs.
import cv2 This, and library documentation. It's probably the single practica issue I have with D and Nim. They seem to have fairly robust standard libs but when I look for something specific it always turns out this feature is missing, outdated, or badly documented.
- Just learn the language with all of its quirks
- If you are new, ignore the quirks until you are ready
Creating a new language sounds ideal, but there are a whole slew of caveats. Python tends to be recommended as a beginner language since it is reasonably easy to learn and offers considerable room for growth By the time the Next Python reached that stage, we would have accumulated a new two decades of techniques and features that would leave Next Python in a similar position to Python today. That assumes that people would even agree upon which language would serve as Next Python as a standard recommendation. One of the advantages of having so many people agreeing upon Python as a starting point is it eliminates the first hurdle novices most novices face: figuring out where to start.
As for the batteries being included, it is also a strength of Python. Choosing libraries can be difficult. That's true for the novice and it's true for anything but trivial projects. Lean standard libraries encourage fragmentation. We should have learned that from the shortcomings of C, yet many languages have followed in the same footsteps with similar results. We should have learned that large standard libraries can be useful, from the success of languages like Java and Python. Package managers don't change the degree of fragmentation, they only make it easier to deal with.
I seriously cannot think of anything I could do to exceed Python.
Does it do everything? No. But name a tool with significantly greater overall reach. Some compete, but seriously. . .
There’s no reason a new scripting language couldn’t excel in all three of those areas. But AFAIK none currently come close.
Also what is wrong in having a switch statement? (I`d like one with range cases 1<x<10..)
Accesing dicts with a struct syntax.
'Inline' C functions.
JIT, especially for loop acceleration.
if par:
do_stuff()
if par = None:
do_stuff()
def myFunc(par=None):
if par:
# do whatever is needed when the parameter exists
pass
#finish processing
if not par:
pass
_notset = object()
def foo(x=_notset):
if x is _notset:
print("foo was called as foo()") if par is None: ...
And for JIT, there's numba!
Agreed on the switch statement...
It's a personal project so I like to experiment, but it's also a CLI program that accepts command line arguments, runs, and then exits, so a 3-5 second delay _each_time_ it runs is pretty painful.
Luckily for me there's a 'single directory' option, which puts everything (uncompressed) into a folder. Snappy start because there's no decompression step, and while I like the idea of a single file .exe it turns out I don't really need that (I'm not copying the program from computer to computer).
So - thumbs up for PyInstaller!
Try including pandas with a few other popular libraries.
Suddenly you have 500MB blobs. Not very practical for passing around multiple projects.
I suppose that is not worse than Electron apps...
In the python world you have to do all the work by hand. I've literally spend time copying and pasting code out of libraries and into my code just so that my build wouldn't balloon by 100MB because I wanted to call a 100 line function.
This is an extremely unscientific comparison, because I don't feel like creating custom binaries specifically to test with. But I happen to have a copy of youtube-dl on my hard drive, and it's 1.8 MB. I'm not sure whether youtube-dl creates their binaries with PyInstaller, but youtube-dl is written in Python, and the binary is a single file that can be run without a Python installation.
I also have a copy of docker-compose, which I know for a fact is created with Pyinstaller. That one clocks in at a significantly worse 10.8 MB (so perhaps Pyinstaller is the culprit and youtube-dl is doing something unique), but that's still relatively small for a considerably complex program.
Lastly, I have a binary called "toggle-switchmate3", which I created myself some years ago. I have a set of Switchmate light switches set up in my apartment, and the best way I could find to control them from a Mac was via this Node package: https://www.npmjs.com/package/node-switchmate3. NPM's dependency mess freaks me out, so I set everything up in a virtual machine, and then created a binary with "pkg", the Node equivalent of pyinstaller.
"Toggle-switchmate3" is 36.1 MB. And it's not a standalone binary—it requires a separate "binding.node" file to be in the same directory.
Perhaps not in the general case, but in many cases it absolutely is. The problem isn't python itself but libraries. While JavaScript tends towards dozens of small libraries that do only one thing, python tends towards one library that does everything. Which is really handy in most cases, but very painful when you want to package something that just uses one of those functions.
In a concrete case I had a small script that ran a particular edge detection algorithm on an image and returned the edges in geojson format. The whole script was less than 300 lines. But the built dist weighed in at several hundred MB as it pulled in the entirety of numpy, scipy, scikit-image, fiona, shapely and rasterio, despite needing only maybe a couple of percent of the functionality of each library.
I did this before and found it really easy to integrate. The provided C API surface is really easy to integrate with. It was literally just a case of detailing my types, calling the Py runtime and then querying the results/side effects.
Having never done something like that before, i was full of trepidation - i was amazed at how easy it was.
Python is the second-best language for everything.
As a happy user of clojurescript, or seeing the popularity and adoption rate of typescript, I do not count them out.
Just off the top of my head:
- Pattern matching
- Multi-line lambdas
- Proper variable capture in lambdas and inner functions (as was fixed with the 'let' keyword vs 'var' in recent versions of JavaScript)
- Support for cyclic imports (a bad pattern in general but necessary in some cases)
- A well-defined C API for extensions that doesn't get them too entangled in the internals of CPython. This would make it possible for other implementations to reach the level of library support that CPython enjoys.
Multi-line lambdas can be sort of obtained in Python by defining a progn function:
for x in ...:
The fact that you can do such a thing in JavaScript is exactly why JavaScript is such a mess of a language with its globally-declared and hoisted variables.
That sort of practice has never made sense, and is not a language design that Python should follow.
If you are new, chances are do not yet know what is a quirk and what is idiomatic.
It can be challenging and frustrating trying to follow guides or tutorials and they are all doing things differently - which is the "right" way? You have no idea as a beginner.
I think that package managers or not, the "batteries included" approach is great, because it leads to most of the code for useful things already available, and also helps third party packages be smaller (since they can depend on things available in the standard lib).
Imagine 3 different packages, for example, each bringing its own different json parser depedency -- as opposed to all leveraging the included json package.
That's how you get no community standards but tons of packages for the same basic things in slightly different ways, each with 20%-30% adoption.
That's also how you get 1GB node_modules folders.
That's also how you have the "leftpad" situation.
- A simplified/sounder natively integrated version of Typescript's type system - Javascript's easy notation for manipulating objects - None of Javascript's other baggage/cruft - Something akin to go routines
Basically, something with the performance of Go/Java (so there would be no need to rewrite your code once it starts serving millions of people) but the elegance of Typescript.
Not sure if this is similar to your vision of a "next Python" but it feels somewhat similar.
Basically I think right now:
C -> Zig
C++ -> Rust
Java -?-> Go
Python/Javascript --> ???
With native typing we could get a language as fast as Java/Go but with the cleanliness of Typescript.
If dealing with uses after free and lack of bounds checked access in release code is still a fun factor.
> Java -?-> Go
Not at all, unless one misses Java 1.4 with loots of if/else boilerplate.
- I think you're right. C is more l'île a garbage collected C.
It is the same fallacy as C code is safe if everything was checked, while CVEs keep happening.
Having said that, isn’t Deno close to what you’re looking for?
I can write statically typed code that easily shapes & reshapes objects & code that fits functional or object oriented programming styles.
It's a statically typed language that feels dynamic.
Now, if I were to get a version of TS without all of JS's crutches that would be amazing.
Deno is pretty close, but it lacks on performance & is bounded in potential by JS (in some aspects).
Things like `Object.keys` irritate me because they don’t compose well. What would go wrong if TS started supporting `Object.prototype.keys`? Could even be implemented as a rewrite using `Object.keys`.
It’s the ideal replacement for general purpose scripting and browser work IMO. I can’t recommend it enough.
Not sure if that's because I'm a beginner or if it's just Spark itself, but Scala errors are impossible to decrypt.
Time to bump Scala to version 3 so that you don't have the 22 case class field limit anymore. :)
See here: https://dotty.epfl.ch/docs/reference/dropped-features/limit2...
That is what I mean though - but I would replace "Java" with python here. Just stay away from all the complexity and write python code. It's pretty simple and some people argue it's the better way to use Scala.
Just like how you don't have to use type annotations, generators, decorators, context managers in python.
Same for libraries.
At some point you will stumble upon a library that forces you to understand them or you even write one yourself, but that is not something that stops you in the beginning.
Go got this right. If you want to read code, contribute to a large code base, folks will be using the features of the language, including the weird ones. Go has kept things very simple (relatively) in terms of core language. Some things were beyond basic (error handling? no generics?) But boy did it make it easier for contribute and understand code.
def Hi() = "hi" Hi() Hi
Yes, those two variants both work?
Sure, but in that case, is python really beginner friendly? I don't think so. I had the impression we were talking about starting out with the language and building the well-known todo-list to learn the basics.
Also, golang is a rather young language and it will go the way that all languages go: it will get more and more complex because the more experienced developers want to improve their productivity with better language features. Remember the "no generics" thing? Well, now the generics will be added - I predicted this to happen. And just wait, other features will follow...
They've been adding some really more edge / line noise type features. Consider the walrus operator? You can do pretzel magic with this which make figuring out scope and what happened to what difficult.
I love the old way.
with open(…) as f: for line in ...
And I wish they'd just made more things iterable maybe or fixed some of the regex match stuff?
The apps may be heavyweight, but the runtime was designed to run on set-top boxes 25 years ago.
It wasn't arcane at the time that using exceptions for decision logic, or letting loops run by assignment, rather than by creating a new scope, were not the most salient ideas.
The following Python code contains a bug:
list_of_adders = []
for x in iterator:
list_of_adders.append(lambda y: y+x)
In fact, if within the same scope, which is quite large, since Python does not like block scope, x ever be re-assigned, which is quite likely, as Python uses the same syntax for initialization and assignment, then all the closures collected in the list shall thenceon refer to the new value that x is assigned to.
These are not design choices that many other programming languages at the time made; they were bad with the knowledge of the time, and continue to be bad now. There is no justification to have loops be implemented by assignment, and not create a new scope.
In turn, implicit variable declarations (using the same syntax for initialisation and assignment) are a reasonable choice for a language that aimed to be “executable pseudocode” and that supports mixing initialisation and assignment in a single statement (e.g. `a, b, self.c = foo()`).
Having the same syntax for initialization and assignment is quite quæstionable.
It's amazing that people can program in imperative languages at all, yet it feels easy. I wonder how much trouble this causes for somebody learning how to program in a modern high level language.
The one big selling point a future language could have would be inherent parallelization that uses all the 32+ cores of the developers machine, but that are as beginner-friendly as python. Such language does not exist. A dynamic, easy to use, and built from the ground up to always utilize all cores all the time without demanding that the programmer are handling side effects.
Maybe golang comes closest to that (and concurrency is messy in there), but I'm not sure if it fulfills the "beginner-friendly" criteria from the perspective of a python developer.
However, in my experience, keeping beginners away from concurrency is difficult. A lot of Go tutorials make a hard burn for it, since it's the big feature if you're already a programmer. And I've gotten (internet) yelled at for trying to suggest that concurrency is something beginners should leave until much later.
The other problem is a lot of what beginners may want to pivot into after they are done writing their "is the number higher or lower?" first terminal app isn't great for them. It's not a great game/graphical language. GUIs mostly suck. Web is awfully hard to get into nowadays, even if you try to help them narrow their focus.
Strong disagree. There is a language where concurrency is trivial and beginner-friendly. It is called POSIX shell with standard GNU tools. To run several independent commands in parallel, you print them and pipe to GNU parallel. If your concurrency has an arbitrary tree of dependencies, you print it in the form
target : dependencies ; command
Languages that make this simple stuff complicated, like Python, do so by choice, not by need.
E.g. start two long-running commands and then close the one of them depending on some later output of the other one or vice versa.
If that's not already complicated enough, we can easily add things like, execute a command A and then another other commands (B, C, D) and, only once all these are finished, run a cleanup command D. But run D always, no matter wether B, C, D fail (think of closing a database connection). And now treat this whole thing as yet another command E, that itself can be used in the same place as e.g. B or C or D before (= composition).
Shell is great for many common tasks, but I would never call it beginner-friendly, even less "trivial to use for concurrency".
1. It's not generally taught in CS classes, and people just search up enough syntax to be able to acomplish their task.
2. A lot of it's variable expansion/substitution are remiscient of Perl.
3. Small mistakes can have huge impact (everyone knows how often rm -rf of unintended directories takes place). Just for the fun of it, I suggest everybody reads at least once the Unix Haters Handbook https://web.mit.edu/~simsong/www/ugh.pdf
If I understood your task correctly, it can be done just nicely in the shell (after all, this is what I think the shell excels at). You'll see the unpleasant side of it when dealing with function arguments and slicing values and referecing specific ones. I don't guarantee it does what you want to the letter, but just my quick interpetration of your description.
function demo() {
first=$1
last="${!#}"
$first &
wait
for f in "${@:2:$#-2}"; do
$f &
done
wait
$last
}
function first() {
sleep 5
}
function pingy() {
ping -c 8 google.com
}
function last() {
echo -----------------------------
echo done
}
function inception() {
demo first pingy pingy
}
demo first pingy pingy inception lastYet somehow beginners in my lab cannot get their hands off the shell and we have to politely guide them to other languages... But still, I insist that parallelism in the shell is very easy. How do you do that in Python, for example?
# convert images from jpg to png, in parallel
for i in *.jpg; do
echo convert $i ${i/jpg/png}
done | parallel
> Regarding your "complicated" use cases, I must confess that I don't understand them nor their relevance.
They are two recent examples of mine. But even if you don't see the relevance in them: if shell truly makes concurrency trivial, then the shell code should not look much more difficult then my English descriptions.
I'd argue that Clojure, while perhaps not the easiest language for beginners in all aspects, is both minimalistic and really fantastic for doing clean and safe concurrency.
Making programs execute faster could be. And there using many cores is one implementation strategy among many complementary ones. But the current landscape of programming languages shows that languages focusing on execution speed and parallelism have smaller user bases.
Also, re this data interpretation of Python's killer app, this usage of Python is something fairly recent and happened after Python had already broken into mainstream usage in the industry. A lot of small and big applications have been built using it before the data and ML things got in vogue (like Youtube, Dropbox, Spotify etc at the bigger end).
However, their scheduler really needs speed ups, and they do run into weird data handling bottlenecks in my experience.
I'd argue it replaced Perl.
Perl - December 1987
Python - December 1989
Not that the TIOBE index is perfect, but you can see what happened since 2001. Perl used to be a lot more popular for early dynamic websites and systems glue, but by 2011, Python had gotten a lot more popular in those roles.
I for one, think it's more likely that Python will evolve. The mathematicians and physicists, biologists, astronomers etc. that have finally gotten rid of C++/Fortran and learnt Python aren't going to change to anything with forced static typing any time soon...
- Training your entire team to use Julia instead of learning about other relevant things
- Re-writing your Python-infrastructure (or dealing with Julia to Python-interoperability, which means new employees now have to learn or know both Python and Julia)
- Replacing Jupyter and learning new, similar tools
- All employees making their favorite IDEs function well with Julia
- Figuring out how to make Julia talk to software that already has an existing Python API (Wireshark, AutoCAD, GNU Radio, ... just about everything you can think of)
Again, I’m not an academic so take what I say with a grain of salt - but I can see Julia paying dividends very very quickly in that sphere (once you’re over the admittedly steep learning curve).
- Julia is relatively easy to learn for Python people (especially the numerical people who have experience with stuff like Cython)
- The interop (both ways) is pretty great with Python
I’m sure it’ll only take a couple of years for everyone to migrate
I feel like Python just went through that big shift. Doubt we need a other one of those.
Also, I'd just look at Julia for some of what you're describing. It's basically going for a more focused approach with the learnings of Python in place.
We could call it Python 6.
Notwithstanding the various ways of doing the same thing (which sometimes goes against the zen of Python), as of Python 3.6 there's been a constant trend towards f-strings above all else (barring maintenance and legacy code), and generally beginners have no need for anything beyond f-strings. If they'd like to go into the old string formatting techniques, they're welcome to, but they're not that complex.
I don't understand how type annotations constitute a 'compromised design' - they've worked quite elegantly with Python's dynamic typing, they greatly assist linters and IDEs when you turn them off, and they can be disregarded when you don't need them, which is a far cry from the enforced typing of other languages.
And I certainly do not agree that there is a need for a "next Python". Python does a lot of things very well - it's design is clear, the design patterns are methodical, the language is well-governed, the central packaging system is reliable (and not like the insane NPM and dependencies of JavaScript), there is a distinct idiom/style consistency amongst Pythonistas, a and a large gathering of minds behind the language. Further, Python reads very well, and can be even pseudocode without being pseudocode, which makes it very much suited for beginners who can stray as far as they want to into the language when they feel ready for it.
Python is a great language for beginners, so I have no idea what you're talking about.
But they tend to get ironed out over time. Python 3.9 adds parametrized generic type hints based directly on container types, alleviating the need for a parallel type-hint type system. i.e. `dict[str, list[int]]` over `typing.Dict[str,...]`
What does it matter to you if there are features in the standard library you don't use? The full python embedded distribution is only 8MB including runtime.
Many seem to be happy replacing Python with Go, to get better performance, parallelism and packaging support. However, for my uses I'd much rather replace it with another high-level scripting language, even if it's still slow and single-threaded.
Can we make that the standard and get rid of the ugly str.format(UGLINESS) syntax.
Yes please, and thank you
But otherwise, yes - make f-strings the “one obvious way to do it” and use `format` only when necessary. And get rid of the old %-formatting.
Also consider making f-strings the default: https://pyfound.blogspot.com/2020/04/all-strings-become-f-st...
`format` is still useful, particularly when working with pre-templatized strings. It's also a (relatively) new feature; Python 2 didn't have it at all.
OTOH, I wouldn't cry if Python 3.X finally removed %-formatting. `format` does everything that `%` does, with a much nicer API (especially in 3.7+).
f-strings work well in simple cases. But once the things you want to output are somewhat larger expressions, format() works much better.
Example: instead of something like
print(f'{id:<5} | {", ".join(members}:<50} | {", ".join(str(score) for score in scores):<30}')
print('{:<5} | {:<50} | {:<30}'.format(
id,
", ".join(members),
", ".join(str(score) for score in scores),
))
all_members = ", ".join(members)
all_scores = ", ".join(map(str, scores))
print(f'{id:<5} {all_members:<50} {all_scores:<30}')No, please.
F-strings are useful for some things, but there's a good reason. to define templates other than deep in code for ease of editing them distinct from functionality (often, completely externally to code) and using str.format supports that.
If anything, I'd prefer r-strinfs as the default with both escape handling and formatting non-default options, but the status quo is acceptable and better than r-strings as the base.
Everytime someone uses %args inappropriately a baby seal dies.
I wish Python went with static typing from the offset, and I wish it had better parallelism, but with Python you can get a library for just about anything with a simple pip install, and that's worth a great deal.
Need a WebSocket library? No problem. Need a cross-platform TUI library? No problem. Python's maturity means you can do a lot of things with little hassle. Some of the less mainstream programming languages are nowhere close to Python in this regard, even after many years.
That can compile to binary, javascript and other languages?
That would be https://nim-lang.org/
https://pypi.org/project/flake8-simplicity/
https://github.com/wryun/flake8-simplicity/blob/master/flake...
Golang is easy to get started with tooling and packaging is good. but then the code in the wild is littered with pointers for when you wouldn't need them.
Sounds great. What made Python so beginner-friendly and readable? Most of the "let's improve Python" gang I see can't begin to answer that - by their metrics, the language must be a failure.
Beginners have the advantage of not thinking "this is the best way to do it because that's how C/C++/Java do it".
With all these memory safe languages getting popular NSA needs more npms, not less.
Kotlin solved the syntax and language warts on top of a good runtime.
For python the syntax is (mostly) good but the runtime and package management needs a rehaul.
Bolted-on classes and types annotations, and missing real lambdas isn't awesome, and lack of proper variable scoping is error-prone.
I agree that the runtime is a mess, but more in naming inconsistencies and how its organized than functionality.
Android is the only place where Kotlin actually matters.
A language with a consistent design can have layers, and beginners can just do with the external bits without getting too deep initially, but with enough space to grow.
IMHO Python is a good language on that regard.
"To boldly create programming languages no man has created before."
Python has added lots of features to stay current with the latest trends in programming languages, but this has come at the cost of complexity and redundancy (e.g. look at all the ways to format strings or do filesystem operations). And many of the new features such as type annotations have a compromised design due to their being added to Python late in the game. Python's "batteries included" approach of a large standard library was a great asset in the days before package managers but these days I think it would be better to start with a much leaner stdlib and add things in more stringently.