Hacker News Reader

Comment by Narhem | Hacker News Reader

Awesome to see Python turning more into a full fledged programming tool. Would be neat to see some kind of static typing, or atleast enforced duck typing.

View on HN

No, I'd rather it stayed close to its original design in that regard. I sometimes feel like the success of Python has attracted fans of features available in other, less popular programming languages. Those people want to turn Python into their favourite language. I am not a fan of those attempts. Python is a forgiving and malleable programming language, but I sometimes want to quit when I open the repo at a new client only to find code written by someone who was told that functional programming and GraphQL are the future only to get bored halfway through the exercise of writing the app. You literally have to torch the code and start from scratch in those cases.

To those who want to turn Python into Golang/Rust/Haskell/Java ... guys, other programming languages are available.

If it’s a small application starting as functional application makes a lot of sense, it’s like putting rebar before pouring concrete. Even if you start from scratch again you know someone has already started working with the previous structure. Meaning that work was not wasted.

Anything to avoid the over complexity associated with delivering content with nodejs it’s like you missed out on building your computational foundation.

There is a problem and it is not connected to any particular language. The majority of courses, reference material, and existing code is not built around functional programming paradigms.

Agreed to disagree

As someone that has used Python on and off since Python 1.6, mostly for UNIX scripting stuff, if Python is imposed on me as big boys programming language, I at very least expect the same tooling experience as Common Lisp, Smalltalk, Scheme, SELF, JavaScript, in performance, and not having PyPy feeling like an outsider on its little corner.

I understand the sentiment. I don't think Python can satisfy one group of devs without loosing another, so the best way forward would be to stay true to itself while allowing those groups to adapt it to their expectations. I too have my own little wishes like having an option to turn off GIL much earlier. Python has become such a popular language that it's now harder to steer that ecosystem in one direction or the other.

I think it’s a bit disingenuous to put it that way. The comment you are replying to is not asking for a widely different programming style. They want typing which is perfectly understandable.

It’s common that as project grows larger and more unwieldy, people ask for more warranty and help from their tooling. I think Python position on this strikes a good balance - provide the infrastructure for adding type hint but delegates type checking to a third party.

Python uses dynamic typing by design. Removing it would remove one of it strengths (and weaknesses as some insist). It is one of the things that made Python so successful. We have learned over time that adding mypy to the pre-commit hooks is a good thing, but I think that's where we should stop. Give devs an option, but don't force it upon them.

I think you could also argue for some sort of setting that adds additional optimisations based on type hints, but it would have to default to off.

Do you mean like mypy and optional type hints or something different, enforceable like Typescript?

I wouldn't really say Typescript is enforceable, given that the types aren't actually considered at runtime.

In fact, people should see Typescript as a linter / bundler tool than a programming language by itself, ignoring the design mistakes of how enums and namespaces came to be.

That is the case for most typesystem considered safe, save for introspection use cases. For instance, haskell, a language with strong type guarantees, does erase types for runtime.

Almost no languages have types considered at runtime.

Well python does, after the famous PEP to pack all types into strings got parked (probably forever).

There's packages to typecheck at runtime, even to check the parameters to a function.

It would be nice to have typing in the core language/interpreter, including runtime type errors, instead of this weird add-on approach. I constantly run into situation where the code is fine and mypy complains or the code is broken and mypy says it's fine. It all just feels like one gigantic fragile workaround instead of a proper type system that you can depend on.

Its not runtime enforceable though. Personally whilst I do provide type hints (I have a the linter setup to remind me) They are only really useful as a documentation tool.

As they are not enforced at runtime, you can easily return bollocks and not know.

I really like how c# does it, which is have strict typing on by default, but allowing you to turn it off for things where you're wanting to be loosey goosey. Not having to do a bunch of type checks on every operation would also speed up a bunch of things inside python

However, that would make it a different language. perhaps python 4? (ducks)

See typeguard[0] for runtime type checking. I activate it only during testing, avoiding unnecessary overhead in prod.

[0] https://pypi.org/project/typeguard/

Pyre has optional strict mode typing if you want to enforce it. It also is more sound than mypy.

Interesting, first I've heard of Pyre. Seems to be a Facebook project? How does it compare to Pyright, which is also more or less sound (unlike Mypy)?

There is also the rarely mentioned pytype from Google, written in Python. And pyright from Microsoft is written in Typescript, pyre at Facebook in OCaml. Last time I checked, these had better type inference algorithms (Hindley-Milner?) than mypy.

https://github.com/google/pytype https://github.com/google/pytype https://github.com/microsoft/pyright

In my experience Hindley Milner type inference is a misfeature. Pyright doesn't use it and its typing system is very good. My only typing complaint with it is that it exactly types dict literals by default, which is usually not what you want.

By that I mean if you do

  foo = {"a": 2}
  foo["b"] = 3

you will get a type error because the inferred type of foo includes knowledge of the keys. But well written code doesn't use dicts when you know which keys are going to be present - you use a dataclass.

I guess you could argue most Python is not well written, but then most Python developers are too amateur to use Pyright anyway.

Now it only needs a proper JIT, to catch up with Common Lisp in 1984.

Common Lisp doesn't specify anything about JIT.

So what?

Lisp compiles to native code since 1962, having a JIT is pretty much given.

I only mentioned Common Lisp, because of the wide library, having already the implementation experience of Lisp Machines from Xerox PARC, TI, Genera, and being as dynamic as Python if not more so, already to sidestep the usual dynamism excuse for lack of Python JIT's.

Lisp's dynamic nature does not come from having or not having JIT; none of the implementations you mention had JIT.

Compiling to native code isn't JIT, it was very common to run just straight interpreted code on the Lisp Machines (since compiling took a long time, and then to load the final file object on slow disks).

JIT is a synonym for dynamic compiler in CS speak.

Feel free to show us the manuals of those implementations without a chapter about (compile ....), (disassemble ....) or similar.

Your claim was that JIT was something CL had, it doesn't. But now your switching topics.

The Lisp Machine compiler is incremental, but it is not a dynamic compiler, it never changes the compiled object when it has been compiled during run-time. This is similar with all Lisp implementations, and even Python. Code is also not compiled by default on the Lisp Machine, it is interpreted.

https://docs.python.org/3/library/functions.html#compile https://docs.python.org/3/library/dis.html

Python has all the building blocks that Lisp does in this regard, and has had for many many years. But I'm not allowed to quote the Lisp Machine manual on the topic, since it has chapters on the compiler so I'll jump out of this conversation now...

Nope, the topic is still the same.

http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec...

https://web.archive.org/web/20201213195043/ftp://publication...

That describes incremental compilation. Something Python is also capable of.

Dynamic compilation (i.e. compilation during execution and/or modifying the emitted compiled output during run-time -- depending on which school one prefers) was never a thing on the Lisp Machine, and is not even a thing in modern Lisp implementations like say SBCL which just does static compilation (compiled object is never modified when it has been compiled).

    (print-herald)
    LM-3 System, band 4 of AMS-LISPM-2. (LM-3)
    2048K physical memory, 16127K virtual memory.
     Experimental System     300.0
     Experimental Local-File  54.0
     Microcode               323
    AMS Lisp Machine Two, with associated machine FS.
    
    (defun foo () "bar")
    FOO
    (compiled-function-p #'foo)
    NIL

From https://en.wikipedia.org/wiki/Just-in-time_compilation

"The earliest published JIT compiler is generally attributed to work on LISP by John McCarthy in 1960"

As for the LM-3 example, I would rather be proven wrong by you pointing me to PyPy as counter example, but the poor fellow not even for this comes up.

Yeah, but that's wrong. It's the usual confusion about Just in Time dynamic compilation by the system and incremental compilation by the user.

LISP I had an incremental compiler. The user calls the compiler with a list of functions or function definitions to compile. It's not compiling dynamic by the system and also does not use information about the running function (call statistics, call argument statistics, ...).

There is no "Just in Time" functionality provided. The developer is responsible to decide what code to compile and when to compile the code. A function needs to be compiled by the developer before it is invoked, otherwise it won't run compiled. In a JIT compiled setting the system decides when to compile the code: either on start or during runtime triggered by the system. The code will be "Just in Time" compiled.

This Wikipedia article explains the difference:

https://en.wikipedia.org/wiki/Dynamic_compilation

"Just-in-time compilation is a form of dynamic compilation."

"Unlike dynamic compilation, as defined above, incremental compilation does not involve further optimisations after the program is first run."

Later Lisp systems may have aspects of JIT compilation. For example some CLOS implementations optimize code (-> method combinations) at runtime, possibly via compilation.

COMPILE is AOT, not JIT. Typical Lisp compilers will not dynamically optimize code based on runtime performance metering.

From https://en.wikipedia.org/wiki/Just-in-time_compilation

"The earliest published JIT compiler is generally attributed to work on LISP by John McCarthy in 1960"

I can naturally also go hunthing for those papers from my digital cellar.

Other than type hints?

Reply on news.ycombinator.com