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

221–230 of 264 posts

Re: Python's “disappointing” superpowers

#221

Post by ReflectedImage »

vore wrote: post #143
ReflectedImage wrote: post #123

Earlier quoted context omitted.

[flagged]

This argument is in such bad faith it's hilarious. Here's my much better argument: Instead of using dynamic typing, eating babies reduces the incidence of bugs in code by 1000x. If you don't believe me and would like me to cite a source, you first provide a citation saying something different to what I'm saying and I'll provide my citations. Come on, you can do it! (Hint: You can't) If it really was a strong claim, y…

And yet I eventually provided evidence for what I'm saying and the other party provided nothing at all.

It's not bad faith because you don't like the arguments conclusions.

Re: Python's “disappointing” superpowers

#222

Post by HelloNurse »

phailhaus wrote: post #164
codexb wrote: post #159

Earlier quoted context omitted.

> Python functions have args and kwargs, which make typing significantly more complex Not really. It's only complex when they're used with poor design decisions. There are plenty of languages that allow you to do things that aren't a good idea. Python is no exception. Type hinting just makes those shortcomings more readily apparent. > Callable doesn't even support kwargs PEP 544 and Protocols have existed for 5 years…

I'm talking more about really simple patterns that Python's type system just can't support. Take kwargs. They've existed forever. A really common and not-stupid pattern is to write a subclass such that you only specify some arguments you care about, and then take *kwargs to pass on to the super constructor. Can't type this. You have to exhaustively enumerate those kwargs and pass them in manually, or else you lose ty…

What you call a problem is simply how constructors work: users pass in the arguments that are expected for a certain way to initialize the object, and you either document these expected arguments with type hints or "lose type hinting".

Expecting to inherit type hints from an unrelated place, like the constructor of a superclass, is quite unjustified. The superclass is an implementation detail.

Re: Python's “disappointing” superpowers

#223

Post by bayesian_horse »

dunefox wrote: post #218
bayesian_horse wrote: post #217

Earlier quoted context omitted.

One of the selling problems is that it can be hard to bring coworkers up to speed on it. Management don't like that kind of thing. What management like very much is that using F# attracts better talent, but they no can believe.

It's actually very easy. If developers can't learn a slightly different language then they're getting paid too much.

F# is a highly different language (at least from Python and Typescript) with additional concepts and I don't think you appreciate the problem for most companies to hire developers at all, let alone the kind of people who can hit a new language without a speed bump.

Re: Python's “disappointing” superpowers

#224

Post by deshpand »

sa46 wrote: post #200
deshpand wrote: post #195

Earlier quoted context omitted.

A ~100k LOC project in a statically typed system with type hierarchies, interfaces, contracts and boiler plate will boil down to ~10k LOC in a dynamically typed language like Python. A 10k LOC project will be more readable than a 100k LOC project. Source: I have spent years coding in C++/Java, then Python. I have migrated Java projects into Python

10x seems extreme. ESR went from 14k lines in Python to 21k in Go. http://www.catb.org/~esr/reposurgeon/GoNotes.html

I didn't mean to exaggerate. I think part of the improvement was the luxury of refactoring which should generally reduce the bloat. And, as someone else said, part of the issue is C++/Java, not static typing. When I move from Java to Python, I also get the luxury of organizing code into fewer/meaningful source files. I find this more readable, than having to switch to different files constantly.

I have not had a chance to learn or use a language like Go. But production use of Python, including building large code bases is real. We do resort to numba, cython or using Python API to compiled code.

I'm now involved in converting large codebases from SAS to Python. I don't think I will have the luxury of choosing another language like Go, for a number of reasons.

Re: Python's “disappointing” superpowers

#225

Post by troutpanda »

progval wrote: post #106
tmtvl wrote: post #69

Earlier quoted context omitted.

Oh no, Lisp is so much more powerful. For example you can update the definition of a class in a running system and update all existing instances of that class. When an error occurs you can inspect local variables in any of the stack frames and execute commands in them. And that is only the tip of the iceberg, Lisp is, as far as I know, without equal in terms of power.

> you can update the definition of a class in a running system and update all existing instances of that class Like this? >>> class MyClass: ... attr = 0 ... >>> my_object = MyClass() >>> MyClass.attr = 42 >>> my_object.attr 42 >>> MyClass.method = lambda self: self.attr >>> my_object.method() 42 > When an error occurs you can inspect local variables in any of the stack frames and execute commands in them What is the…

To Lispers, Python's hyperpowers (reflection and dynamic typing) are just regular Lisp business. Lisp's strength lies exactly in how convenient doing metaprogramming is in Lisp.

There are probably some subtleties and differences in how powerful both systems are (can't say more, I don't know how powerful python's metaprogramming is), but just know that Lisp has practically no limit in how you can extend the language.

Re: Python's “disappointing” superpowers

#226

Post by bayesian_horse »

phailhaus wrote: post #62
bayesian_horse wrote: post #9

When I did most of my work in Python, typehints weren't a thing. I still feel like static typechecking is less useful in Python since its datamodel is overally less of a hot mess compared to Javascript for example. And Python modules/frameworks can be a lot more "typed" than you'd expect. Django models, forms etc offer more runtime validation than typesystems can easily achieve. Yes, at runtime. But between not havin…

> its datamodel is overally less of a hot mess compared to Javascript for example. I don't understand this, what do you mean? TypeScript is such a success partly because everything is an object in Javascript. There's no need to distinguish between classes and "dicts", as you have to with Python. Another example: Python functions have args and kwargs, which make typing significantly more complex (as the article points…

With hot mess I mean things like undefined vs null, various surprising comparisons, truthiness, lack of a primitive integer type...

Re: Python's “disappointing” superpowers

#227

Post by bayesian_horse »

phailhaus wrote: post #130
ReflectedImage wrote: post #122

Earlier quoted context omitted.

[flagged]

Citation heavily, heavily needed. Dynamic typing means that none of your code can be statically checked, which means that correctness relies on the exhaustiveness on your tests. It should be obvious that this would allow you to introduce more bugs, not fewer. Every program involves passing around data. When you need to change that data in a dynamic untyped language, you have no option but to manually test your whole…

There is almost no evidence type safety helps at all. Anecdotally, I don't find I have bugs in Python that could be caught by typesystems easily.

Re: Python's “disappointing” superpowers

#228

Post by bayesian_horse »

acedTrex wrote: post #15
bayesian_horse wrote: post #7

Earlier quoted context omitted.

Over the years C# (and probably Java, but I'm not so well versed in that) gained quite a few features to improve "Meta-Programming", one could argue in an attempt to compete with dynamic languages. In C# that is mainly possible through introspection, generics and maybe dependency injection. Entity Framework Core can mostly figure out an SQL Table and its queries by looking at a simple class. It's not as good as the D…

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 need almost no code to generate CRUD views and APIs from it. Can't do that in Dotnet. I think I could make something like that but why bother and take the pain?

When dotnet people say "my experience" then they mostly mean no experience beyond dotnet (in my experience). I hope you are basing your comparison on more than a glance or a weekend project trying out Django...

Re: Python's “disappointing” superpowers

#229

Post by taeric »

rendaw wrote: post #204
taeric wrote: post #172

Earlier quoted context omitted.

What did I make an equivalence between? Large codebases are hard, period. That is all I am saying. Having worked on 100k LOC systems in static and in dynamic, I will not claim either has a benefit. That is just hard. Static analysis is, of course, good. If that is static typing or otherwise. So is running the code making sure it does what you want when running. What is not a huge help, is a byzantine type hierarchy t…

The equivalence you're making is that dynamically-typed large code bases are just as difficult to get into as statically-typed large code bases.

This implies that "difficulty" is a totally ordered set. Which... I find highly unlikely. Things can be very difficult in amazingly unique ways.

Re: Python's “disappointing” superpowers

#230

Post by lordgroff »

zerodensity wrote: post #82
lordgroff wrote: post #6

I maintain Python code bases for a living, and feel that the language has simply been pushed too far. Static typing in Python doesn't give you the advantage of actually static typing and even IDE support is -- well it's not terrible, just not great. The thing is, once we go through all this static typing exercise in Python, we get no performance advantages, and the whole thing seems bolted on, with worse semantics th…

I also maintain a large python codebase at work, typing makes things simpler. For example using pydantic 90% of serialization code just goes away. Mypy eliminates a large number of bugs. Also when working with multiple people in the same codebase typing makes intent so much clearer. The type system itself is not perfect but it's a clear improvement of not having it at all.

It's a net benefit. I just think that we've stretched Python into all kinds of directions which should be served by actually statically typed languages.
Post reply on HN