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

61–70 of 264 posts

Re: Python's “disappointing” superpowers

#61

Post by rich_sasha »

simplicio wrote: post #44
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…

My theory is that Python and C++ are slowly evolving towards eachother, and in 20 years will merge into the same (very confusing) language.

C++ consuming whatever popular paradigm is around and growing into a jumbled mess? Surely you're joking...

Re: Python's “disappointing” superpowers

#62

Post by phailhaus »

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 out, Callable doesn't even support kwargs). Javascript doesn't, so typing functions is trivial.

Part of the point of static typechecking is documentation that can be verified by tooling. If you have no types in your codebase, and you decide to change something from a dict to a class, good luck! You're going to have to manually trace all the data flows through your entire application to figure out what's affected.

Re: Python's “disappointing” superpowers

#63

Post by thatfunkymunki »

abdullahkhalids wrote: post #38
mjr00 wrote: post #29

Earlier quoted context omitted.

That's because your type is Optional[TypeOfVar] though; if you try using that variable in a place that expects just TypeOfVar before it's set, you should get an error.

Let me restate. To prevent ugliness in typing, either * Python should have a way of declaring variables without setting them to None, so we can type hint them to their actual types. Pre-declaration is very important for a prototyping language, and needs to be done in a way that the variable is visible to dir(). * Come up with a cleaner syntax than the wordy Optional[]. Thankfully, they have recently moved on from the…

but Optional[foo] is literally a union of foo | None already!

Re: Python's “disappointing” superpowers

#64

Post by scrollaway »

9dev wrote: post #46
wheelerof4te wrote: post #22

Either embrace dynamic typing and provide good error guards...or try to use type hints and still make good error guards. We had an entire history of Python 2 without type hints. Why use them now?

How come everyone realised the benefits of typing by now, except the Python community?

Because python got a half baked, overall poor quality type hinting system so devs that haven’t been exposed to the benefits of eg. Typescript don’t understand why this is better.

Many of us in the python community know the benefits, and we’re simply changing our stack so python is as contained as possible, and dropping lower quality libraries for higher quality typed ones.

Re: Python's “disappointing” superpowers

#65

Post by pdonis »

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…

> everything is an object in Javascript

Everything is an object in Python too.

> There's no need to distinguish between classes and "dicts", as you have to with Python.

"dict" in Python (or at least Python 3, but Python 2 is EOL now so Python 3 is the only active Python there is) is a class. You can even subclass it, which if you want a customized dict for some reason in your particular application is often the best way to do it. Or you can subclass MutableMapping, which dict itself is a subclass of, and which is what is supposed to be used for isinstance checks now that Python has established abstract base classes for all of its standard "built-in type" interfaces.

Re: Python's “disappointing” superpowers

#66

Post by pdonis »

9dev wrote: post #46
wheelerof4te wrote: post #22

Either embrace dynamic typing and provide good error guards...or try to use type hints and still make good error guards. We had an entire history of Python 2 without type hints. Why use them now?

How come everyone realised the benefits of typing by now, except the Python community?

The benefits of typing for certain kinds of applications.

Many people in the Python community simply aren't writing those kinds of applications. They're writing applications where typing is not a benefit, it's a hindrance, so they don't use it, and Python makes that easy.

Re: Python's “disappointing” superpowers

#67

Post by pdimitar »

jgeada wrote: post #34
KurtMueller wrote: post #30

Python the language doesn't give you super powers and I would say that its clunkier and less elegant than Ruby and obviously not as powerful as languages like F#. Python's ecosystem and contributors are its biggest benefits and they help you succeed in spite of the language itself.

The ecosystem exists because Python does make it possible. That was one of the main thrusts of the article!

> The ecosystem exists because Python does make it possible.

Only to a certain point, after which the network effects override everything else.

Re: Python's “disappointing” superpowers

#68

Post by pdonis »

abdullahkhalids wrote: post #25
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…

> the whole thing seems bolted on, with worse semantics than most modern typed languages One of the biggest sources of ugliness is the "None". The standard way of declaring variables ahead of time is setting them to None. But then, the type hints just become these ugly unreadable Optional[ActualTypeofVar] everywhere.

> The standard way of declaring variables ahead of time is setting them to None.

I'm not sure this method is actually "standard". For many use cases there is an obvious "null" value of the desired type (for example, just set an int variable to 0), so there's no need to use None.

For use cases where you can't just initialize the variable to the "null" value of its type (because that value has some other meaning for your program), then the true type of the variable isn't just the type you're thinking (e.g., not just an int), because you need to be able to distinguish the variable having the "null" value from it not being set at all (the None case). And for that kind of use case, Python's type hints are correctly forcing you to declare that variable's type the way that reflects the actual situation.

Re: Python's “disappointing” superpowers

#69

Post by tmtvl »

fallingfrog wrote: post #5

Don't fool yourself- if your programming language has an eval() function, you are writing in Lisp and you are a Lisp programmer now. Embrace it! All joking aside, I do think Python is pretty handy.

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.

Re: Python's “disappointing” superpowers

#70

Post by david2ndaccount »

ImprobableTruth wrote: post #50
joshuamorton wrote: post #36

Earlier quoted context omitted.

A lot of the orm style things are not really feasible in static-er languages without clunky approaches like codegen.

What part specifically? Java is (in)famous for its orms after all. Unless you want to count that as clunky codegen? I'd argue that all metaprogramming boils down to that though.

Java is actually a very dynamic runtime with a very static language front end.
Post reply on HN