6 ms·

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.

by Narhem 2y ago

daniel-s 2y ago
Do you mean like mypy and optional type hints or something different, enforceable like Typescript?
- fastball 2y ago
  I wouldn't really say Typescript is enforceable, given that the types aren't actually considered at runtime.
  - pjmlp 2y ago
    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.
  - pyrale 2y ago
    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.
  - School-Cotton 2y ago
    Almost no languages have types considered at runtime.
    - guappa 2y ago
      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.
    - deleted 2y ago
      [deleted]
- grumbel 2y ago
  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.
- KaiserPro 2y ago
  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)
  - skeledrew 2y ago
    See typeguard[0] for runtime type checking. I activate it only during testing, avoiding unnecessary overhead in prod. [0] https://pypi.org/project/typeguard/ https://pypi.org/project/typeguard/
adhamsalama 2y ago
Other than type hints?
surfingdino 2y ago
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.
- Narhem 2y ago
  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.
  - surfingdino 2y ago
    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.
    - Narhem 2y ago
      Agreed to disagree
- pjmlp 2y ago
  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.
pjmlp 2y ago
Now it only needs a proper JIT, to catch up with Common Lisp in 1984.
- amszmidt 2y ago
  Common Lisp doesn't specify anything about JIT.
  - pjmlp 2y ago
    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.
    - amszmidt 2y ago
      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).
      - pjmlp 2y ago
        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.
        amszmidt 2y ago
        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/functions.html#compile https://docs.python.org/3/library/dis.html 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...
ipsum2 2y ago
Pyre has optional strict mode typing if you want to enforce it. It also is more sound than mypy.
- IshKebab 2y ago
  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)?
  - zeotroph 2y ago
    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/google/pytype https://github.com/google/pytype https://github.com/microsoft/pyright https://github.com/microsoft/pyright
    - IshKebab 2y ago
      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.

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.

by Narhem 2y ago

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.

daniel-s 2y ago

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

fastball 2y ago
I wouldn't really say Typescript is enforceable, given that the types aren't actually considered at runtime.
- pjmlp 2y ago
  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.
- pyrale 2y ago
  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.
- School-Cotton 2y ago
  Almost no languages have types considered at runtime.
  - guappa 2y ago
    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.
  - deleted 2y ago
    [deleted]
grumbel 2y ago
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.
KaiserPro 2y ago
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)
- skeledrew 2y ago
  See typeguard[0] for runtime type checking. I activate it only during testing, avoiding unnecessary overhead in prod. [0] https://pypi.org/project/typeguard/ https://pypi.org/project/typeguard/

adhamsalama 2y ago

Other than type hints?

surfingdino 2y ago

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.

Narhem 2y ago
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.
- surfingdino 2y ago
  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.
  - Narhem 2y ago
    Agreed to disagree
pjmlp 2y ago
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.

pjmlp 2y ago

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

amszmidt 2y ago
Common Lisp doesn't specify anything about JIT.
- pjmlp 2y ago
  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.
  - amszmidt 2y ago
    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).
    - pjmlp 2y ago
      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.
      - amszmidt 2y ago
        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/functions.html#compile https://docs.python.org/3/library/dis.html 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...

ipsum2 2y ago

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

IshKebab 2y ago
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)?
- zeotroph 2y ago
  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/google/pytype https://github.com/google/pytype https://github.com/microsoft/pyright https://github.com/microsoft/pyright
  - IshKebab 2y ago
    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.