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

Python's “disappointing” superpowers

lukeplant.me.uk

Post reply on HN
Print view View original

251–260 of 264 posts

Re: Python's “disappointing” superpowers

#251

Post by [deleted] »

ok123456 wrote: post #14
paganel wrote: post #4

> I’m worried that a de-facto move away from dynamic stuff in the Python ecosystem, possibly motivated by those who use Python only because they have to, and just want to make it more like the C# or Java they are comfortable with, could leave us with the very worst of all worlds. It is certainly happening, and I'm not sure Python the language is all the better for it. I say that as a guy who explicitly mentioned this…

eval() makes it harder to reason able your code and opens you up to injection attacks. Steering the boat toward C# or Java is better than crashing into TCL.

[deleted]

Re: Python's “disappointing” superpowers

#252

Post by acedTrex »

bayesian_horse wrote: post #228
acedTrex wrote: post #15

Earlier quoted context omitted.

How is SQLAlchemy or django better at any of that? in my experience EF is far far superior

Migrations have been painful in EF. No easy way to separate models/migrations for the same db context like with Django apps. Metadata for the models is hard to come by (probably there is a way?). Support for advanced Postgres datatypes slowly becomes ready for primetime, but currently isn't, and it's certainly about ten years behind Django in that regard. In Django, a model alreay contains all the meta data and you n…

> Support for advanced Postgres datatypes slowly becomes ready for primetime, but currently isn't, and it's certainly about ten years behind Django in that regard.

What type support is lacking in the ef pg provider?

> Metadata for the models is hard to come by (probably there is a way?).

I'm not sure what metadata means here exactly, you can configure models with either the fluent api or the attribute api

Re: Python's “disappointing” superpowers

#253

Post by mountainriver »

ReflectedImage wrote: post #154
mountainriver wrote: post #146

Earlier quoted context omitted.

In the amount of time you’ve repeatedly said this all over this thread you could have provided a citation

Here: https://games.greggman.com/game/dynamic-typing-static-typing... I think it's more effective to show that there is no evidence to contradict me first.

lol wow you're really something, this is literally one guy, there is TONS of research on this which contradicts his findings. This guy does a pretty good summary https://danluu.com/empirical-pl/ definitely heavier on the research wouldn't you say?

He also misses the biggest add of typing your code which is that other people can understand it better. This is often lost on junior programmers...

Re: Python's “disappointing” superpowers

#254

Post by reissbaker »

taeric wrote: post #158
spoils19 wrote: post #149

I used to be a huge dynamic languages fan, with python being my favorite language over the majority of my career. Then I worked on a large python project of ~100k LOC with a team of ten. That's when I realized that writing code faster isn't the problem. Reading it is, making changes to code someone else wrote is, and refactoring across dozens of modules is a problem. Static languages help a lot with all three. I stil…

This is almost always framed in a way that shows large systems need the extra rigidity of some static systems. And that dynamic systems are only about rapid prototyping. I think that is a bit of a false framing. To wit, any system of 100k LOC will be hard to get into. Even harder to make changes in. There is no getting around that. None. Even worse if you have many entities flying about these 100k LOC. Each change to…

Anecdotal but — I've worked on many-million-LOC codebases in Ruby with large teams (pre-Sorbet and other type checkers, at Airbnb), and many-million-LOC codebases in typechecker-checked Python with large teams (Instagram). The typechecker-checked Python was way easier to reason about and refactor.

Re: Python's “disappointing” superpowers

#255

Post by nextaccountic »

samstave wrote: post #51
nextaccountic wrote: post #23

Earlier quoted context omitted.

> I routinely use cython to compile python for heavy workloads. an alternative is rust + pyo3 https://pyo3.rs here's a web framework written with it, https://robyn.tech the other poster child for pyo3 is polars, https://www.pola.rs it's simply, amazing.

which of these links should I start with with zero xp?

If you don't know Rust, but know Python, you can install Python libraries written in Rust with pip. Like, pip install polars or pip install robyn. In this case you follow the two bottom links. But then you don't write your own libraries and stuff so.. I guess that's not what you want.

If creating your own Python libraries in Rust is what you want, you would check out the first link I sent only, the one for pyo3.

But, if you want to learn Rust, you probably wouldn't start out with pyo3. You first install Rust with https://rustup.rs/ and then check out the official book, and the book rust by example, that you can find here https://www.rust-lang.org/learn - and maybe write some code on the Rust playground https://play.rust-lang.org/ - then, you use pyo3 to build Python libraries in Rust, and then use maturin https://www.maturin.rs/ to build and publish them to Pypi.

But if you still prefer to begin with Rust by writing Python libraries (it's a valid strategy if you are very comfortable with working with multiple stacks), the Maturin link has a tutorial that setups a program that is half written in python, half written in Rust, https://www.maturin.rs/tutorial.html (well the pyo3 link I sent also has one too. You should refer to the documentation of both, because you will use the two together)

After learning Rust and building some stuff with pyo3, the next step is looking for libraries that you could leverage to make Python programs ultra fast. Here https://github.com/rayon-rs/rayon is an obvious choice, see some examples from the Rust cookbook https://rust-lang-nursery.github.io/rust-cookbook/concurrenc... - when you create a parallel iterator, it will distribute the processing to many threads (by default, one per core). The rust cookbook, by the way, is a nice reference to see some of the most used crates (Rust libraries) in the Rust ecosystem.

If you are doing async stuff in Python, you probably need to look up https://github.com/awestlake87/pyo3-asyncio and https://tokio.rs/ - that's two libraries that Robyn uses (see Robyn dependencies here https://github.com/sansyrox/robyn/blob/main/Cargo.toml)

Anyway there are some posts about pyo3 on the web, like this blog post https://boring-guy.sh/posts/river-rust/ (note: it uses an outdated version of pyo3, and doesn't seem to use maturin which is a newer tool). This post was written by the developers of https://github.com/online-ml/river - another Python library written in Rust

Re: Python's “disappointing” superpowers

#256

Post by ReflectedImage »

mountainriver wrote: post #253
ReflectedImage wrote: post #154

Earlier quoted context omitted.

Here: https://games.greggman.com/game/dynamic-typing-static-typing... I think it's more effective to show that there is no evidence to contradict me first.

lol wow you're really something, this is literally one guy, there is TONS of research on this which contradicts his findings. This guy does a pretty good summary https://danluu.com/empirical-pl/ definitely heavier on the research wouldn't you say? He also misses the biggest add of typing your code which is that other people can understand it better. This is often lost on junior programmers...

Well according to most of that research I'm correct.

See: "Work In Progress: an Empirical Study of Static Typing in Ruby; Daly, M; Sazawal, V; Foster, J."

See: "Haskell vs. Ada vs. C++ vs. Awk vs. ... An Experiment in Software Prototyping Productivity; Hudak, P; Jones, M."

Lisp - A dynamically typed language had the lowest development time by a factor of 2.5x. Seems to be the same figure I'm giving, fancy that!

"He also misses the biggest add of typing your code which is that other people can understand it better."

Nope.

See: "How Do API Documentation and Static Typing Affect API Usability? Endrikat, S.; Hanenberg, S.; Robbes, Romain; Stefik, A."

You need documentation and whilst Java students may study with dynamic typing since they haven't been taught it, it's pretty clear that on it's own static typing provides almost no useful documentation.

"This is often lost on junior programmers..." I'm far more experience than you, which is why I'm calling out the BS.

I think you will find that the research suggests that static typing and dynamic typing have a similar bug rate per line of code.

See: "A Large Scale Study of Programming Languages and Code Quality in Github; Ray, B; Posnett, D; Filkov, V; Devanbu, P"

Once you combine that knowledge with the knowledge that dynamically typed programs have less lines per feature.

Relational Lisp 274 compared to Ada 767 or C++ 1105.

Dynamic typing wins out because the programs are smaller, making them faster to write and contain less bugs per software feature.

The link you posted confirms it.

Do you understand that you are wrong?

Re: Python's “disappointing” superpowers

#257

Post by albertopv »

ReflectedImage wrote: post #240
albertopv wrote: post #210

Earlier quoted context omitted.

Dynamic languages large code based are, in my 14yo experience, much much harder. Today no one a serious project with javascritpt, AFAIK everybody use typescript. Why?

JavaScript is a badly designed language. It was created on the fly over several decades by browser makers. People prefer to code in absolutely anything else. WASM will probably kill TypeScript shortly.

Actual JS is based on original one, but have been much improved. Still the lack of static typing is a liability fixed by typescript.

Re: Python's “disappointing” superpowers

#258

Post by collinmanderson »

HdS84 wrote: post #243
dkarl wrote: post #233

Earlier quoted context omitted.

> I had a bug where I changed the return type of a function to be a tuple > If a given programming language community winds up bleeding members who are moving on due to the lack of better static type checking systems, then the people left will invariably be much more likely to be against static type systems. This reminds me of one of the things I hate most about the Python library ecosystem: libraries attempt to camo…

What's missing here is an Ienumerable from c#. That's basically anything that can be iterated like a list. So a function could take this enumerable and convert it to a list but should probably reject everything else. And yes generally agree that Paramus should be not be too accepting. It gets confusing fast.

> What's missing here is an Ienumerable from c#. That's basically anything that can be iterated like a list. So a function could take this enumerable and convert it to a list but should probably reject everything else.

Python has an Iterable type class for this.

https://docs.python.org/3/library/typing.html#nominal-vs-str...

https://docs.python.org/3/library/collections.abc.html#colle...

Re: Python's “disappointing” superpowers

#259

Post by bayesian_horse »

acedTrex wrote: post #252
bayesian_horse wrote: post #228

Earlier quoted context omitted.

Migrations have been painful in EF. No easy way to separate models/migrations for the same db context like with Django apps. Metadata for the models is hard to come by (probably there is a way?). Support for advanced Postgres datatypes slowly becomes ready for primetime, but currently isn't, and it's certainly about ten years behind Django in that regard. In Django, a model alreay contains all the meta data and you n…

> Support for advanced Postgres datatypes slowly becomes ready for primetime, but currently isn't, and it's certainly about ten years behind Django in that regard. What type support is lacking in the ef pg provider? > Metadata for the models is hard to come by (probably there is a way?). I'm not sure what metadata means here exactly, you can configure models with either the fluent api or the attribute api

Json(b) columns, (multidimensional) Arrays.

By metadata I indeed mean info on what a field means: Human readable names, descriptions, hints on validation or user input fields. You can argue that's not the ORM's job, but having some of that already in the ORM allows Django to have CRUD apis and views with very little code beyond the models.

I think you could make something like DRF or Django admin on top of EF by abusing assembly introspection. But so far nobody dared to do that.

Re: Python's “disappointing” superpowers

#260

Post by hakre »

ReflectedImage wrote: post #240
albertopv wrote: post #210

Earlier quoted context omitted.

Dynamic languages large code based are, in my 14yo experience, much much harder. Today no one a serious project with javascritpt, AFAIK everybody use typescript. Why?

JavaScript is a badly designed language. It was created on the fly over several decades by browser makers. People prefer to code in absolutely anything else. WASM will probably kill TypeScript shortly.

Actually it was written (so it was done) in roughly two weeks and then released. The rest is part of modern history in terms of distribution of software and backward compatibility/portability.

The two other languages you mention, TypeScript and WASM, are more part of the same platform mutually benefiting from the progress than competing each other.

Post reply on HN