Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3.15: features that didn't make the headlines

blog.changs.co.uk

Post reply on HN
Print view View original

161–170 of 236 posts

Re: Python 3.15: features that didn't make the headlines

#161

Post by vic20forever »

estebank wrote: post #113
tuveson wrote: post #109

Earlier quoted context omitted.

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.

VisualBasic did that. I think it is a mistake. But that doesn't mean that the compiler can't detect that and tell you how to fix it instead.

Say whaaat? VB (v.3 through v.6, at least) wouldn't compile if you misspelled the name of a function or subroutine.

Re: Python 3.15: features that didn't make the headlines

#162

Post by ElectricalUnion »

eager_learner wrote: post #155
markdown wrote: post #129

Earlier quoted context omitted.

> * Web sites: Typescript, or maybe Go. lol, no. Just no. Python is far superior for website backends unless perhaps you're running one of the top 20 websites in the world.

function Greeting({ name }: { name: string }) { return ( Hello, {name}! Welcome to my site. ); } 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…

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:

https://github.com/pyxy-org/pyxy

Re: Python 3.15: features that didn't make the headlines

#163

Post by troad »

sirsinsalot wrote: post #148
seabrookmx wrote: post #132

Earlier quoted context omitted.

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.

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.

Re: Python 3.15: features that didn't make the headlines

#164

Post by estebank »

vic20forever wrote: post #161
estebank wrote: post #113

Earlier quoted context omitted.

VisualBasic did that. I think it is a mistake. But that doesn't mean that the compiler can't detect that and tell you how to fix it instead.

Say whaaat? VB (v.3 through v.6, at least) wouldn't compile if you misspelled the name of a function or subroutine.

VB had case insensitive name resolution.

Re: Python 3.15: features that didn't make the headlines

#165

Post by [deleted] »

BOOSTERHIDROGEN wrote: post #27
brianwawok wrote: post #2

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.

Interested in why you'd use Python in the first place? Advice for someone who knows nothing about programming - what would you suggest?

[deleted]

Re: Python 3.15: features that didn't make the headlines

#166

Post by vic20forever »

estebank wrote: post #164
vic20forever wrote: post #161

Earlier quoted context omitted.

Say whaaat? VB (v.3 through v.6, at least) wouldn't compile if you misspelled the name of a function or subroutine.

VB had case insensitive name resolution.

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.

Re: Python 3.15: features that didn't make the headlines

#167

Post by zmmmmm »

Sohcahtoa82 wrote: post #98
tyre wrote: post #24

Earlier quoted context omitted.

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, bu…

> 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…

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

Re: Python 3.15: features that didn't make the headlines

#168

Post by zmmmmm »

sunshine-o wrote: post #48

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 ...

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.

Re: Python 3.15: features that didn't make the headlines

#169

Post by andersonpico »

sirsinsalot wrote: post #149
pennomi wrote: post #71

Earlier quoted context omitted.

Same here. Django is my last holdout for Python. Everything new is go.

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.

what do django do that's contrived in js or say aspnet or rails?

Re: Python 3.15: features that didn't make the headlines

#170

Post by lmm »

tuveson wrote: post #121
estebank wrote: post #113

Earlier quoted context omitted.

VisualBasic did that. I think it is a mistake. But that doesn't mean that the compiler can't detect that and tell you how to fix it instead.

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).

Post reply on HN