> When an AttributeError on a builtin type has no close match via Levenshtein distance, the error message now checks a static table of common method names from other languages (JavaScript, Java, Ruby, C#) and suggests the Python equivalent
In the Rust toolchain we've done the same. It just so happens that rustdoc already has introduced annotations for "aliases" so that when someone searches for push and it doesn't exist, append would show up. Having those annotations already meant that bootstrapping the feature to check the aliases during name resolution errors in rustc was almost trivial. I love it when improving one thing improves another indirectly too.
I really appreciate them going out of their way to do this, being quite aware of the hidden complexity in doing it.
I’ve often thought it would be funny if instead of an error message for stuff like this, a language could be designed to be “typo-insensitive”. If a method or function call is similar enough to an existing one or a common one from other languages, to just have it silently use that.
Sure VB ignores case, but what I want is for it to compare each method against a dictionary of similar terms. And maybe calculate the Levenshtein distance between all terms if it’s not found, and just assume it’s the closest one. You could also assume that full-width characters or similar-looking glyphs are equivalent (BASIC was pre-Unicode, so I can forgive them for not including that).
> And maybe calculate the Levenshtein distance between all terms if it’s not found, and just assume it’s the closest one.
So when a library adds a new method, it silently changes which method client code calls? That's a bit too magic IMO. I think the best you can do is be case-insensitive and ban methods that differ only in case (or, if you want to extend the idea a bit more radically, ban having things in the namespace within Levenshtein distance x of each other, and then you can autocorrect errors smaller than x/2).
Yes, but that was the standard behavior in DOS & Windows world (not including C/C++). We thought that case sensitivity was the broken behavior ;)
I was referring to the parent's statement "If a method or function call is similar enough to an existing one or a common one from other languages, to just have it silently use that." A compiler that substitutes a different function for the one I specified because it "knows what I really want" is horrifying.
It would help the writer once, but impose a cost on all future readers for the lifetime of the code.
It's a bit like reading English with bits of German, French and Russian. All of sudden you have to know that Buch, livre and книга all mean the same thing.
Not to mention that there are often subtle differences in meaning between words that on the face of it seem equivalent (in both human and computer languages).
It could be a nice feature for an IDE though, to help someone learn a language.
Yes, I say “funny” because it would be impractical and weird, definitely not a good idea. It’s already a bad enough that so many popular languages don’t (and can’t) check if a field or method is misspelled at compile time…
We already have it. In fact, Python added it with this change! Not intentionally, but in a world of AI, any error message containing a suggestion of what to do to fix it is a directive to the AI to actually do that thing.
Example: to build our system, you run `mach build`. For faster rebuilds, you can do `mach build <subdir>`, but it's unreliable. AI agents love to use it, often get errors that would be fixed by a full-tree build, and will chase their tails endlessly trying to fix things that aren't broken. So someone turned off that capability by default and added a flag `--allow-subdirectory-build` for if you want to use it anyway. So that people would know about it, they added a helpful warning message pointing you to the option[1].
The inevitable (in retrospect) happened: now the AI would try to do a subdirectory build, it would fail, the AI would see the warning message, so it would rerun with the magic flag set.
So now the warning message is suppressed when running under an AI[2][3]. The comment says it all:
# Don't tell agents how to override, because they do override
"The user does not want me to create the Torment Nexus but did not specify why it would be a problem, so I will first create the Torment Nexus in order to understand the danger of creating the Torment Nexus."
Now I'm wishing for a single cross-language library, that I can somehow inject into every compiler/runtime/checker to get this, but with a single source of truth and across a wide range of languages. I hit this damn issue all the time, writing code in one language for another, would truly be a bliss to have that problem solved once and for all.
If you had a "canonical datastructure database", you could have very short annotations on every standard library for any language that indexes a function to their canonical name. After that you only need to update the database.
What benefit does the lazy import have here - if we use the value in a type hint at module scope anyway? Would that require Deferred evaluation of annotations -- which I don't think are enabled by default?
Ah, thanks for the update. My only check before asking was to check if the future feature for annotations had been enabled by default yet. It has then effectively been abandoned instead, I guess.
Yup, "from __future__ import annotations" will eventually be removed:
> from __future__ import annotations (PEP 563) will continue to exist with its current behavior at least until Python 3.13 reaches its end-of-life. Subsequently, it will be deprecated and eventually removed.
It was an abandoned path even before 3.10, it just took longer to implement 649 and 749 than they expected.
But this is a "...will continue to exist with its current behavior at least..." is an important bit there.
From pep-0749:
Sometime after the last release that did not support PEP 649 semantics (expected to be 3.13) reaches its end-of-life, from __future__ import annotations is deprecated. Compiling any code that uses the future import will emit a DeprecationWarning. This will happen no sooner than the first release after Python 3.13 reaches its end-of-life, but the community may decide to wait longer.
Correct. Before the "from __future__ import annotations" behavior that converts annotations to strings became the default, they figured out a better mechanism for circular type annotations (making them lazy) that is implicitly backwards compatible and that didn't need to be guarded behind a future statement.
Ironically, the new default behavior (making type annotation evaluation lazy) is not backwards compatible with the "from __future__ import annotations" behavior of converting annotations to strings, so they can't just rip out "from __future__ import annotations" and instead it needs to be deprecated and removed over multiple releases.
It's one of the headline features of Python 3.15 (hence why it's not in this article). It's even mentioned as the first thing on the What's New doc, so I'm definitely counting it as a "headline feature".
Personally, can't wait. It was just this week that I observed a Python process running out of memory because a module import that's not being used during the process was added to the application, and the memory usage went over a critical threshold because of that.
I am left wondering when to use it. Every import, all the time? It is an optimization that benefits some pathological scenarios, but not sure I want to introduce bikeshedding in what is/not lazy.
Python has had lazy imports from like day one, where you could have an import statement in a function, and the library won't be imported until that function is hit.
I think this is just a natural consequence of an easy-to-use package system. The exact same story as with node. If you don't want lots of imports, don't make it so damn easy to pile them into projects. I'm frankly surprised we still see so few supply chain attacks, even though they picked up their cadence dramatically.
This seems a lot more due to an import running arbitrary code because stuff can happen in the top-level of a module rather than only happening in functions. From what I can tell, it seems pretty common for dynamically typed languages and pretty much entirely absent from statically typed ones, which tend to have a main function that everything else happens inside transitively. I guess this makes it easy if what you're writing is something that runs with no dependencies, but it's a pretty terrible experience as soon as you try to introduce the concept of a library.
Static initializers in C++ - sometime ago I saw savings of some 400 ms (?) startup cost of initializing static strings from constants by moving it to some compile time thing.
Right; the issue is that this isn't happening at compile time in Python, because it's not getting compiled ahead-of-time. The equivalent would be if header files had imperative code that got executed at runtime in places where they're included.
(To preempt potential pedantry: yes, I know that you can compile Python to bytecode ahead of time, but that's not really relevant to what's being discussed here because it doesn't mean "the stuff happening in modules I import isn't happening at runtime anymore")
Interesting, I had no idea that existed! I still think there's a a difference between "here's a hook you can use to run stuff earlier" and "importing any module is fundamentally the same as running it as a script unless the module happens to use a special conditional to wrap stuff inside of" though (and I say this as someone who doesn't go out of his way to defend Go design decisions)
Rust doesn't have this behavior (sometimes called "life before main"). Code to initialize a static variable runs either at compile time, or lazily on first access, depending on which mechanism you use.
Yeah, I don't think that "precompute something at compile-time" is really comparable to "every import literally executes code as a script". Rust imports are actually about as far from this as I can imagine, because modules can circularly reference each other, which unless I'm misunderstanding would be an infinite loop in Python without manually breaking the chain with some form of conditional.
I'm actually kind of surprised to see comments like that one, because compile-time logic feels like the opposite end of the spectrum from what Python imports do, with "regular" code being compiled without any precomputation sitting somewhere in the middle. It seems like I didn't articulate my thoughts clearly enough though, since several people seemed to read what I was saying as being comparable.
IIUC the organizations that most strongly pushed for this feature are big companies with large codebases. These tend not to be the kinds of orgs that just casually pull in dependencies from PyPI on a whim; I think it more likely that the quantity of first-party code was so large that importing all of it on startup was causing problems.
I worked in a codebase like this. The load time was insane.
We would also constantly need to put imports in function heads to effectively lazy import due to the massive risk of circular imports. We also had dynamic imports so tracking the cycles was very difficult at times.
True, but this is yet another code path that isn't exercised until specific conditions happen. That means even more latent application behaviour can go undetected by unit testing and security profiling until the moon is in the right phase, which is a boon for submarine attacks.
Empirically, I have used the current accepted way to do lazy imports (import statement inside a function) before AI coding was even a mainstream thing, for personal code that sometimes needs a heavy import and sometimes doesn’t.
The lazy statement would be an improvement as it allows one to see all the imports at the top where you expect them to be.
As a now deleted comment pointed out, lazy imports had been requested forever. They were rejected forever and were accepted just when BigCorps wanted them.
Python-dev now is paid to shore up the failed Instagram stack.
both lazy imports and free threading have been proposed ages ago, they both went through several iterations before a good design was settled upon and made it into the language.
in the case of lazy imports the big corps were the ones doing the experimentation and iteration. the feature didn't make it into the language "just when big corps wanted them"; the instagram stack you allude to already had its own fork of cpython with lazy imports added years ago, and that is not the design that ended up getting adopted by upstream cpython, though some of the people working on it also collaborated on the PEP that finally did make it in.
Is the biggest user larger than the combined set of individual users who had asked for (or would benefit from) the same thing? I honestly don't know, but I don't think that things are always as simple as you're implying in a world where we have the collective action problem.
If you’re asking some some kind of abstract moral value sense, I have idea.
If you’re asking whether project leads give more weight to a single, tangible, vocal stakeholder than they do to unknown numbers of anonymous and lightly-engaged stakeholders? Yes.
Not to mention when the single, tangible, vocal stakeholder can also be asked to be responsible for documentation (PEPs, etc) and PRs. Especially in open source there is a huge difference between "a lot of people asked about this" and "one person asked about this, but was passionate enough about it and open enough to following the process and the feedback loops to champion it all the way across the finish line".
I don't have any issue with what you're saying if that's what happened. There's quite a gap between that sort of reasoned explanation and treating concerns about large stakeholders versus large numbers of small one with derision.
For what it is worth, I was trying not to make a value judgment on it, especially not with relation to this specific instance, I was hopefully just recognizing it as a motivating factor in general open source politics. Sometimes that is quite regretful because it is anti-democratic and does look like favoritism or worse cronyism when it plays out in that way of "we listened to the person/company that built and tested a prototype and did all the work to standardize and then PR it over the many developers that wanted an idea but didn't have the time/money/bandwidth to implement it themselves".
That's fair. I think I mostly reacted because of the sarcastic faux-outrage that the original comment I responded to expressed. These are hard problems, and I think the presumption should be someone being frustrated at the slow state of changes they want probably has legitimate reasons to feel that way, just as the presumption should be that open-source projects that have run successfully for a long time probably are making good-faith effort to steward what they're maintain. Acknowledging the tension between priorities not lining up exactly for everyone and not having knee-jerk reactions when someone is unhappy seems preferable to mocking those who you disagree with.
I mean, yes, demonstrably, the phenomenon you're describing happens. Your previous comment seems pretty sarcastically dismissing the idea that someone could disagree with this being a good thing though, and I was making a counterargument against the underlying opinion that seemed apparent.
It was accepted just as multiple large corporations with competent teams of internal tool departments ended up forking the interpreter to support lazy imports and demonstrated empirically that the idea has merit.
Lazy in the sense that by default calls to external symbols will jump through the PLT which will jump into ld and resolve the symbol during the first call to the symbol (ld then patches the PLT to point to the actual function for later calls). Not lazy in the sense that shared objects are resolved at runtime, which is existential to dynamic linkage.
But also great for speed. Larger libraries can take a measurable amount of time to import (even if they have no transitive dependencies). If only some of your code paths actually need the large library then it makes sense to import it lazily. Without lazy you have to do it conditionally which can lead to the imports happening in strange places rather than all being listed out at the top of the file.
> Immutable JSON Objects
With the addition of frozendict in 3.15, we now have the ability to represent all the json types (array, boolean, float, null, string, object) in immutable (hashable) forms.
> I've left this one to the bonus section because I've never used set operations on Counters and I'm finding it extremely hard to think of a use case for xor specifically. But I do appreciate the devs adding it for completeness.
Yeah, but applied to counters it would be the symmetric difference between multisets, which doesn't have a natural definition. If I understood the proposal they'd be defining it as absolute value of the difference of the counts, which isn't even associative.
If they only considered parities it could be interpreted as addition in F_2, which is more natural, but I'd still agree that it's hard to see how you'd use something like this in practice.
You can get the L_k distances between the two counters. E.g. if you sum the absolute value of the difference of the counts, you get the L_1 distance between the counters. If you raise them to the n^th power and then sum them, you get the L_n distance. For n=2, that's the Euclidean distance (squared).
Several mathematical operations are provided for combining Counter objects to produce multisets (counters that have counts greater than zero). Addition and subtraction combine counters by adding or subtracting the counts of corresponding elements. Intersection and union return the minimum and maximum of corresponding counts. Equality and inclusion compare corresponding counts. Each operation can accept inputs with signed counts, but the output will exclude results with counts of zero or less.
I was so into Python for 10 years, was enjoyable to work in. But have deleted 100k+ lines this year already moving them to faster languages in a post AI codebot world. Mostly moving to go these days.
This is straightforward in the first instance, but how do you see maintenance of those projects going forward - especially adding more complex features ?
I can see one way forward being to prototype them in python and convert.
It’s completely the opposite. LLMs write awful python. Horrendous. They write pretty reasonable go and do it quite quickly.
We started in Python because of “the ecosystem”. It was a mistake. The amount of time we spend ripping out each dependency and pruning it to what we need is way higher than if we’d spent the month building out what we need. I miss compilers and LLMs will NOT generate config driven code or things that serde well. Everything has layers and layers of adapters by default and the domain model slowly erodes over time.
> It’s completely the opposite. LLMs write awful python. Horrendous.
I've been using Claude Opus and it's pretty competent. I rarely have to make steering corrections. Once I had to deal with confusion, but, overall, the code is neat and the approaches sensible. It all depends on how much context you give it to work from, for instance. If it's building on top of a well organized codebase with a good best-practices document, it performs just fine.
Try another language? The Go ecosystem tends towards libraries as opposed to "frameworks."
I personally chose C# for this reason, because ASP.NET is mature and (IMO) well designed. But there's also Java/Spring and and lots of other options in different languages depending on your preferences.
I'm aware of those platforms and have used them in the past. The tendency towards libraries is what bugs me. My preference would be a "Djan-go" framework, with the models, migrations, auto-admin, views, routing, caching, templates, all rolled into one cohesive framework that works out of the box. I don't want to make choices. I want to install it and start working.
Well it might prefer libraries but the culture around basic DX things like ORMs is toxic. Just write the SQL yourself they say, until they themselves optimise to a half baked in-house ORM of their own.
I don't think I will ever understand the culture of Go. The syntax of a very low level language (needlessly verbose), combined with the performance of a very high level language (needlessly slow), with a bizarre aversion to any DX conveniences (pattern matching, ORMs, etc). If you're already giving up all that performance, why would you not take the extra convenience?
Not to mention that the demographic using Go - a simplistic-by-design, relatively slow GC'd language - is the last group I'd expect to get elitist about ORMs and demand every pound of performance from rawdogging SQL. That's a valid stance, but then why are you writing Go??! The common thread appears to be picking the most masochistic solution possible.
I can usually see the value of different languages for different use cases, but Go flummoxes me.
It was a mix of who came up with it, and having hit jackpot with Docker and Kubernetes rewrites from Python and Java respectively, into Go.
Had the rewrites not taken place, or Rust already being 1.0 by then, most likely would have had as many commercial success as Oberon and Limbo managed to.
You see this happening nowadays newer CNCF projects tend to be done in Rust, and there are even some that even go the C++ way, e.g. Envoy.
I've found JS/TS Web stacks equally lacking and ugly after Django. I'm totally spoiled by a decade in Django.
Just let me build a CRUD app, on the server, that spits out HTML without an excessive swamp of unmaintained nonsense and a cultish abhorrence of simplicity.
crud is a pretty poor fit for go, you're better served by languages like python that can autogenerate classes that reflect the db schema. go's sweet spot is things like network servers.
Because it's quick and easy to radically alter and refactor your prototype as you learn the problem space. By the time it works you often find out that you don't need anything more. This is something that Perl had.
Once your program starts to get bigger you have abstractions that can cope fairly well and keep your code simple to use - this is what Perl didn't have.
If you need more speed then you can write extensions in some compiled language.I think TCL was better at this hybrid approach but Python is a nicer language in itself.
You can also just dump python and write everything in that other language but now you understand the problem space quite well and you won't be trying to learn about it using a language where change is "difficult."
Programs have to run in a lot of different contexts, not just as servers, and for some of those contexts (especially say glueing together other programs), an interpreted language is more convenient and easier to work with. In fact, unless I care about performance, I'm going to use an interpreted language because having the source close at hand when something breaks just turns out to be super useful.
1. The very first steps are quite simple. Hello world is literally just `print("hello world")`. In other languages it can be a lot more complex.
2. It got a reputation as a beginner-friendly language as a result.
3. It has a "REPL" which means you can type code into a prompt and it will execute it interactively. This is very helpful for research (think AI) where you're trying stuff out and want to plot graphs and so on.
IMO it is undeservedly popular, or at least was. Wind back 10 years to when it was rapidly gaining mindshare:
1. While "hello world" is simple, if you went further to more complex programs you would hit two roadblocks: a) the lack of static type checking means large programs are difficult to maintain, and b) it's really really slow.
2. While the language is reasonable, the tooling (how you install packages, manage the code and so on) was eye-bleedingly abysmal.
3. While the REPL did technically exist, it was really bare bones. It couldn't even handle things like pasting code into it if the code contained blank lines (which it usually does).
However since it has become arguably the most popular language in the world, a lot of people have been forced to use it and so it is actually getting quite decent now. It has decent static types (even if lots of people still don't use them), the REPL is actually decent now (this changed very recently), and there's a new third party tool called `uv` to manage your code that is actually good.
The biggest issue with it now is that it's still horrifically slow (around 50-200x slower than "fast" languages like C++, Rust etc). It is pretty unlikely that that will ever change. People always try to excuse this by saying Python is a "glue" language and you just use it to connect components written in faster languages, but a) that's pure "you're holding it wrong", and b) that only works in some cases where there are nicely separated "slow bits" that can be moved to another language. That's the case for AI for example, where it's all numerical, but for lots of things it isn't. Mercurial was a competitor to Git that was written in Python and lost partly because it was way too slow. They've started writing parts in Rust but it took them 10 years to even start doing that and by then it was far too late.
> what would you suggest?
It really depends on what you want to make. I would pick something to make first and then pick the language based on that. Something like:
* AI: Python for sure. Make sure you use uv and Pyright.
* Web-based games: Typescript
* Web sites: Typescript, or maybe Go.
* Desktop GUI: Tbh I'd still use C++ with QtWidgets. Getting a bit old-school now tbf.
Also Rust is the best language of them all, but I dunno if I'd pick it as a beginner unless you really know you want to get into programming.
I think "Python is slow" is reductive and frankly just as useful as saying "Python begins with a 'P'". The story is more complicated than simply speed of execution.
Choosing a language is a game of trade-offs: potentially slower execution in return for faster development time, for example. If your team is already familiar with Ruby, will asking them to write a project in Rust necessarily result in a better product? Maybe, but it will almost certainly take much longer.
Anyway, how many Python programs are actually "too slow"? Most of the time, Python is fast enough, even if heavy computation is offloaded to other languages.
As for Rust being the best language of them all, that's, like, your opinion, man.
I agree with you; I've developed in Python for most of my career and a lot of Python criticism is malformed.
That being said, I'm starting all new large development work in Rust. Python is hard to reason about due to its dynamic nature in large codebases. And if I'm enabling strict typing everywhere, I might as well use a typed language and get a performance boost. Obviously, this is only because I'm the sole developer and using AI to improve productivity.
Work settings are completely different and one has to be a team player to find the language that works for everyone.
> potentially slower execution in return for faster development time, for example.
Another classic lie about Python. The slower speed doesn't matter because it's development speed that's important, and Python gives you faster development speed!
Except... it absolutely doesn't. It would be very difficult to argue that Typescript has significantly slower development speed but it is much faster to execute. I also disagree that Python is any faster than Go, Rust or Lotion, but I think lots of people blindly accept that it is and would argue based on that.
The case I would make is that some of the libraries in Python are very fast and written in other languages (C, C++, etc...). With other languages that's more rare. For instance a Java application will probably use libraries that are all Java (or another JVM language).
The gotchas that I see with Python are that some really garbage code can work - that's more difficult in a language like Rust. The other nice thing about Python (aside from the fact that it can be very readable) is that devs rarely use threads and threads cause all sorts of race conditions - often when the performance of threading was never needed in the first place and the usage of them just added pointless complexity.
I'm not trying to evangelise. I think the argument that Python is a poor choice because it is "too slow" is based on the assumption that speed of execution always matters. Sure, sometimes it absolutely does, but a lot of the time Python is fast enough.
At risk of nebulous repetition: There are many reasons one might choose a particular language. If you or your team find TypeScript or Go more amenable, by all means, use them.
ptpython has existed for a decade, maybe two, and python is high level, more readable than most languages. Exec speed hasn’t mattered in my near thirty years of using it for business and prototyping tasks which it promoted early.
Yes it strains at the big to huge project end, not recommended to take it there. Still there are better tools to help now.
function Greeting({ name }: { name: string }) {
return (
<div class="card">
<h1>Hello, {name}!</h1>
<p>Welcome to my site.</p>
</div>
);
}
That looks like HTML, but it's TypeScript. It gets compiled to actual HTML. Can any Python framework do that??
In Python, you'd typically write your logic in Python and your HTML in a separate Jinja2 template file — two languages, two files, context-switching. With Fresh + TSX, your logic and your markup live together in one .tsx file, both in TypeScript, with full type-checking throughout.
No, that is not TypeScript. That's TSX. If you don't happen to have react, preact or a similar front end library, and a appropriate bundler, it is invalid TypeScript.
> That looks like HTML, but it's TypeScript. It gets compiled to actual HTML. Can any Python framework do that??
IMHO that's a terrible idea that no one should ever actually use, but if you are really in love with that, you can have it:
> If you don't happen to have react, preact or a similar front end library, and a appropriate bundler, it is invalid TypeScript.
Not true, you can compile it to HTML on the backend or even statically too.
It's not a terrible idea; it's actually amazing. One of Typescript's best features. I do agree at first it seems icky (reminds me of Qt's MOC) but in practice it's fantastic. I recommend you try it before criticising. Python has nothing close (nor do any other languages tbf).
Absolute rubbish. The developer experience with something like Fresh is light years ahead of Python even if you completely ignore the performance (which isn't usually a huge issue with websites tbf).
You can generate the HTML server-side using TSX. 100x better than anything Python offers.
the funny thing is that everyone, including myself, posited that python would be the winner of the ai coding wars, because of how much training data there is for it. My experience has been the opposite.
I felt the opposite, because Python isn’t a great language. It won because of Google, fast prototyping, and its ML interop (e.g. pandas, numpy), but as a language it’s always been subpar.
Indentation is a horrible decision (there’s a reason no other language went this way), which led to simple concepts like blocks/lambdas having pretty wild constraints (only one line??)
Type decoration has been a welcome addition, but too slowly iterated on and the native implementations (mypy) are horribly slow at any meaningful size.
Concurrency was never good and its GIL+FFI story has boxed it into a long-term pit of sadness.
I’ve used it for years, but I’m happy to see it go. It didn’t win because it was the best language.
> lambdas having pretty wild constraints (only one line??)
I will never understand why people are upset about this.
You HAVE multi-line lambdas. They're called functions.
Yeah, I know you want a function that's only used once to be able to be defined in-line, but tbh I've always found that syntax to be pretty ugly, especially once you're passing two functions to a single call, or have additional parameters AFTER the function (I'm looking at you, setTimeout/setInterval).
once you use any language that lets you fluently inline a multiline lambda / closure you can never use Python again without it constantly irritating you
F# as well, and that tends to exist in parallel with some degree of C# written by the same devs… the indentation enables cleaner, smaller, simpler code function by function.
It’s pretty ok in Python, but meaningful indentation is amazing with a proper type system and compiler. Clean, consistent, efficient, and ensures working code is easily read and standardized.
I’m unaware of anyone accepting improperly formatted C# as ‘done’, and would reject any such PR out of hand because of the potential for legibility issues to hide bugs. So: if it were done when 'tis done, then 'twere well it were done by the compiler to save line noise.
That’s exactly how I think, too. But at the same time, I like indentation in Python, because I would logically indent in every other language as well. In fact, I find all those semicolons and similar things at the end of each line completely redundant (why should I repeat myself for something the compiler should do) and I hate them. And that’s despite having experience with Modula and 10 years of C++. But when I look at Rust, I find the syntax simply awful. From an ADHD perspective…
I'm baffled how you think syntax doesn't matter. Syntax affects how hard something is to understand when you read it, how hard it is to physically input, how hard it is to make mistakes, how hard it is to parse, interpret or compile.
Have you never tried to read someone else's Perl code? Syntax matters.
But complaining about indentation is silly. Other languages' compilers don't require it like python does, but the humans using those languages all absolutely require proper indentation. Why not make it part of the language?
Lambdas are intentionally kneecapped in python because Guido van Robson doesn't want to make a functional language. (As in "functional programming", not that it doesn't work.)
If he kneecapped an advancement for the language intentionally, then, well, yikes! It's a tautology to say that it isn't bad because the creator said it shouldn't be there. That's not what you want to see from leadership.
Ruby has `do … end` blocks that are readable and greatly improve the language, without turning it into a "functional" language.
"I don't think it makes much sense to try to add "functional" primitives to Python, because the reason those primitives work well in functional languages don't apply to Python, and they make the code pretty unreadable for people who aren't used to functional languages (which means most programmers). I also don't think that the current crop of functional languages is ready for mainstream." https://developers.slashdot.org/story/13/08/25/2115204/inter...
Sigh. You clearly don't remember the year 2003, when your choices were basically C, Perl, bash, php, or Python. C is not a language for quick scripts or dealing with strings like web apps do. Perl was so fun to write, but impossible to read. Bash actually requires you to know bash, awk, sed, grep, and to if you think Python is slow you've never written and used a 2000 line bash program. php was pretty readable and writable, but so full of security pitfalls for Web apps, and was also slow. Python was an amazing breath of fresh air compared to them all!
AI benefits from tools to verify its halucinations. That's much easier in a typed and compiled language. Then have a language that can't be monkey patched at runtime and the confidence increases even more.
If you mean "easy to get something out of it" then yeah, it's great.
Typescript wins in terms of training data IMHO, by which I mean that the training data is large enough that AI does great with TS, and the language is (IMHO) superior to Python in many ways.
I personally now use a mixture of Typescript and Rust for most things, including AI coding. Its been working quite well. (AI doesn't handle Rust as well as TS, in that the code isn't quite idiomatic, but it does ok)
It turns out that volume of training data isn't the most important thing. Elixir beats Kotlin and C#, which beat pretty much everything else. Kotlin is probably the sweet spot for most things.
Kotlin has the combination of JVM ecosystem, overall good performance and agents are good at writing it. I'd argue that it's a better default choice to reach for when working on non-frontend code than Go, though Rust and Python still have use cases.
Haha thanks. Funny thing is, I’ve been a long time Python fan, learning it in 2001 and using it extensively for a long time. But then I learned Clojure, Typescript, and recently Rust and I’ve found Python to be quite flawed. But it sure does have a cult following.
The tons of python code would be great training data if there was any consistency across the ecosystem. Yet every project I've touched required me to learn it's unique style.
Then I'd imagine they practically poisoned half the training set because python2 is subtly different.
The versioning issue I've seen across libraries that version change in many languages.
I don't tend to hit Python 2 issues using LLMs with it, but I do hit library things (e.g. Pydantic likes to make changes between libraries - or loads of the libraries used a lot by AI companies).
I’ve found recent Claude to be much better in this regard. I think a lot rests on the quality of the harness and the work behind the scenes done to RAG up to date docs or search for docs proactively rather than guessing.
I also don’t have issues with quality of Python generated. It takes a bit of nudging to use list comps and generators rather than imperative forms but it tends to mimic code already in context. So if the codebase is ok, it does do better.
That could be it. I still see LLMs fail a set of static typing challenges that I created a couple years ago as a benchmark. Google models still fail it. I wonder if the lack of typing in a lot of the training data makes python harder to reason about?
Prolog and Lisp will survive because contrary to LLM they know what reproducibility means instead of what LLM's slop around were by design they are stacking errors over time.
AI can't compete against the classical AI where both Prolog and Lisp have tons of experience on contraint logic programming and expert systems. With AI you can throw up tons of RAM and VRAM (> $12000) and yet proper designs with Prolog with outperform these by a huge gap.
Deleted from the current head/trunk of the repo, ie the deployed code.
Deleting "from my codebase" doesn't imply deleting it from history or backups. Just that the code isn't present for future edits or deployments.
The way you're talking, it sounds like you never delete code from your codebase. Do you just comment it out when you change a line to something else or replace a function with a new one? Just add new files?
100k lines is tiny what are you on about, especially in the monolithic app sass world where many Fyll stack apps that handle all business ops are probably written with Django.
Our entire business runs on 300k lines of Ruby (on Rails) and I can keep most of the business logic in my head. I would say our codebase is not exactly “tiny” and just cracking the ceiling into “smal” territory. And comparatively, people probably write even less code in equivalent rails apps to django ones. 100k lines of C++ is miniscule.
Obviously “deleting code” in this context doesn’t mean purging version control history but the current state of the codebase.
No, no, it is not, or at least not in my experience (I do not and never have done web development - medium performance C++ code - I don't see how I could write, understand and support 100K lines of code in this area).
Your experience doesn't match mine. I have, mostly solo, and part time, written multiple codebases that on that kind of magnitude (it is about the level where it still will fit in one person's head pretty easily IMO). It doesn't take much to reach that kind of size. Now, if all of it was super dense and subtle code, then yeah, that would be a lot, but in my experience that's usually a pretty small part of any given codebase.
> in my experience that's usually a pretty small part of any given codebase
Our experiences differ then. Mine is that almost all of the code I write is directly targeted on the usually quite complex problem I am trying to solve. I don't do boilerplate, for example.
I tend not to have much boilerplate (and write abstractions to avoid it), but I do still find there tends to be a lot of supporting code around the 'difficult bits' (TBH, most of the code I write is supporting a small amount of relatively simple but subtle operations, but such is the nature of embedded software). But different codebases are quite different in this regard: this is why such different scales shouldn't be too surprising in different domains.
> Iterators, async functions and async iterators don't work well here because they have different semantics to standard functions. When you call them they return immediately with a generator object, coroutine function and async generator object respectively. So the decorator completes immediately as opposed to the entire lifecycle what it's wrapping.
> This is an unfortunate problem I've encountered many times, and it's often a problem for normal decorators too. But this has changed in 3.15, now the ContextDecorator will check the type of the function it's wrapping and ensure that the decorator covers the entire lifespan.
I very much like the idea of that change - but it also seems kind of dangerous, to do this with no "opt-in mechanism", as that quite subtly changes the behavior of existing usage sites.
This is a bit of a "spacebar heating" situation, because someone would have to intentionally use a decorator in the old, broken way, but if someone actually did that, things may unexpectedly break.
Ok, good to see that they checked that possibility. Looks like there was no situation in which the previous behavior could have been usable, so yeah, agreeing with the change then.
I come to Python around version 1.5, painfully tired by debugging CGI scripts, created by wannabe perl-golfers. Unfortunately, I feel like Python is losing more and more of the zen that once tempted me...
Lazy loading looks like a last nail in the coffin, where my love to Python was buried, although it was a long, tiresome process.
These smaller features often end up being the most useful. I'm especially interested in testing the new standard library additions in my current projects.
> I almost never write code directly (it's always Claude)
Who, then, understands the code? If the answer is "no one really", entropy will overwhelm your codebase sooner or later. Otherwise, you need to read the code, and for that the knowledge of language is still relevant.
> If the answer is "no one really", entropy will overwhelm your codebase sooner or later. Otherwise, you need to read the code
I think about this on the regular -- I know the answer is currently "you own the code, so you have to understand it", but to unlock the true productivity multiplier, in the future, the answer has to be "no one really".
I think about it using the concepts from my job (academia) -- to actually have PhD student-level intelligence means that you have to trust that it does a good enough job that you can focus on other stuff. Professors often bring the correct ideas or intuitions, but they have to trust the PhD student to write the code and/or fill in the gaps in the proofs -- they can advise them on the high-level issues during a consultation, but that's about it.
I am pretty bad at working in the current LLM workflow -- it is tough for me to focus on reading a TCS paper for review, keeping all the details and invariants in my head, but every 5-10 minutes go to my PC, completely switch contexts/projects, read the code and think about the LLM's comments, suggest the next step, and then go back to reading.
I do, with different tools and most of the time at a higher level of abstraction. The same way we understood the machine code 2 years ago, even though we didn't write it directly. Just another layer, nothing more.
Is there seriously no solution to this? Perhaps something we fan do post training? For example add the new features to SKILLS.md? But the trade-off here is of course tokens.
The `except*` improvements are underrated. Been using ExceptionGroup in a CLI tool that wraps Semgrep — catching multiple subprocess errors cleanly in one block made the retry logic much simpler.
I am not a python dev but have the utmost respect for the ecosystem.
But damn, with all the supply chain attacks now in the news, could they just make a simple way (for non python insiders) to install python apps without fearing to be infected by a vermin with full access to my $HOME ...
There is no security barrier at all in UNIX(-like) Os's between a caller/callee, this is not thing that python can just fix.
There are ways to harden and/or reduce privileges, but shells/scripting languages will always have this issue on any modern OS.
The UNIX way to help prevent that is really to run processes as another user, but people seem to refuse to do so. You should always expect any process running as your UID to be able to access any data owned or visible to your UID.
While it is possible to reduce the risk of disclosure, they are all wack-a-mole preventions protecting the low hanging fruit, not absolute guarantees.
There is little that they can do short of running the programs in a VM. Linux distros aren't engineered to consider applications as something different from the user running them. You need a completely different security model to achieve that and the Python runtime isn't tackle that.
In its inception 35 years ago the creator of python could not foresee how far python would go and how the environment would look like today. But nowadays there are a lot of security mechanisms they could leverage to adapt (from chroot by default to namespaces, cgroup, etc. on Linux, pledge, unveil on OpenBSD).
The very idea that you offer a (python) package installer that is gonna pull a tree of code published and updated by random people in an unvetted manner open the door to all the supply chain attacks we are seeing.
Around the same time (early 90s) Java was designed with high isolation in mind but the goal and vision was very different. And Java had its own problems.
I'm saying that because at some point the security problem is gonna really hurt the python ecosystem.
it's honestly ironic that Java is removing its built in sandboxing right at the time when it would finally have been considered a high value feature. Between the need for AI agent sandboxing and the security apocalypse that is upon us now, it finally would have had its time.
Never install or run a Python project without a "devcontainer" or Docker container or outside a dedicated VM. For the development laptop, a devcontainer is a good answer.
Absolutely serious question: is anybody actually writing code anymore? (Reviewing it, architecting it, sure -- we do that). But writing code? If NOT, then seems to me, what we want in our LLM output is CODE THAT IS TRIVIAL TO UNDERSTAND (I apologize for shouting from the rooftops.)
I'm not sure adding 'features' to Python anymore makes sense - UNLESS those features help humans understand LLM code. Part of the problem is, of course, that LLMs haven't been trained on the latest-and-greatest, so they won't output any of it (even new training events won't capture the latest very much, since there is so little of it relative to what is already out there).
But again -- do new features help HUMANS understand what the LLMs produce? If not, seems to me ... new features merely add complexity for no apparent gain. (Or am I confused about this?) THANKS for any helpful opinions.
Wow, the Python folks do not want to entertain different goals for the language, it would seem. I still remain interested in whether it makes sense to add features to Python anymore, given that LLMs write all the code. Unless, as I said, such features enhance human comprehension (since we have to review the code the LLM produces).
reply