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?
And most of that python2 code is completely rotted.
Python's “disappointing” superpowers
31–40 of 264 posts
Re: Python's “disappointing” superpowers
#32Metaprogramming does not require dynamic types, but this post seems to equate them. As far as I can see all this could be done in e.g. Java (and probably is).
IME this kind of "magic" very quickly loses its appeal when you have to debug it. The author's idea of libraries wrapping this stuff up so users don't have to care about it just doesn't pan out at all in my experience.
Re: Python's “disappointing” superpowers
#33Before I read this article I was not aware of exclusive advantages to dynamic typing. At least now I know what is achievable despite its presence.
Which of these do you think require dynamic typing?
Re: Python's “disappointing” superpowers
#34Python 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!
Re: Python's “disappointing” superpowers
#35Earlier quoted context omitted.
> 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.
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.
Right, in langs with c-style scoping, this is an issue, but in python
if foo:
x = a
else:
x = b
Re: Python's “disappointing” superpowers
#36Before I read this article I was not aware of exclusive advantages to dynamic typing. At least now I know what is achievable despite its presence.
Which of these do you think require dynamic typing?
A lot of the orm style things are not really feasible in static-er languages without clunky approaches like codegen.
Re: Python's “disappointing” superpowers
#37Let's stop calling "dynamic" and "static" versus "runtime" and "comptime" instead ?
Also, "dynamic code generation" for "meta programming" ?
Re: Python's “disappointing” superpowers
#38Earlier quoted context omitted.
> 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.
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 ugly Union[a,b] to the more readable a | b. Something more readable could be done for Optional.
Re: Python's “disappointing” superpowers
#39I think type hints have mostly changed Python for the better but I still get frustrated by the number of half baked features and inconsistencies in the language.
You end up fighting quirks ( like isinstance not working properly with generics ) all the time and it can get pretty tedious.
Re: Python's “disappointing” superpowers
#40I 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.
You can declare a type-hint beforehand without setting the value of the variable. See: https://peps.python.org/pep-0526/#global-and-local-variable-...