Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Opaque Types in Python

blog.glyph.im

Post reply on HN
Print view View original

31–40 of 61 posts

Re: Opaque Types in Python

#31

Post by qrobit »

causal wrote: post #30
nayuki wrote: post #14

Java made opaque types possible from the very start by private and package-private constructors. It's sad to see that many features regarding object-oriented programming and static typing are implemented worse in Python than Java. Various examples: __str__() vs. toString(); underscore vs. private; @staticmethod/@classmethod vs. static; generic types are so clunky in Python; types are not shown in the official Python…

Python is much older than Java, and Java is a big OO-first language. It's a bit like saying Python doesn't do functional as well as Erlang.

Much older? Wikipedia says[^1][^2] java appeared in 1995 (started in 1991), while python appeared in 1991 (started in late 1980s). 4 years doesn't seem too far apart, considering both language are >30 years old now.

[^1]: https://en.wikipedia.org/wiki/Python_(programming_language)

[^2]: https://en.wikipedia.org/wiki/Java_(programming_language)

Re: Opaque Types in Python

#32

Post by prerok »

david422 wrote: post #29
nayuki wrote: post #26

Earlier quoted context omitted.

(I'd like to note that I wrote a lot of code in Java and Python, and continue to use each language in its respective strong areas. This isn't meant as a drive-by attack of "Java r00lz, Python sux"; this is an experienced take.) My real problem with the evolution of Python is that initially, the language and the community was positioned as anti-Java, anti-big-OOP-like-C++, and then it changed into the thing that it wa…

> Static typing in Python is the biggest hypocrisy ever Yes, agreed. I used to work on a large python codebase and tried to add type hints where I could. The issue is that python was not the right tool for the job - except that switching to the right tool was a non-starter. So type hints were the best I could do.

It is indeed a significant undertaking. But... it is doable. I've worked on a code base that converted several functionalities to golang. It did take a lot of effort and quite a lot of planning.

Re: Opaque Types in Python

#33

Post by prerok »

jnwatson wrote: post #3

You're holding it (Python) wrong. Python OO was a counter reaction to the bondage and discipline that languages like C++ had with private members and protected inheritance. If you have members that users probably shouldn't touch, you prepend them with an underscore. This is just a hint; It doesn't actually change anything. We're all adults here and we know the consequences of reaching into implementation details.

Are we, though? No offence but if an external module starts calling an internal function they better prepare a PR that changes the internal (yes, I know, by convention) to a public one. This is a signal to the developers of that module that they have to maintain the behavior.

That PR might well be rejected. And you have to work with the module owners to get your case supported.

Anything else is not responsible and I would not call it "adult".

Re: Opaque Types in Python

#34

Post by nayuki »

qrobit wrote: post #31
causal wrote: post #30

Earlier quoted context omitted.

Python is much older than Java, and Java is a big OO-first language. It's a bit like saying Python doesn't do functional as well as Erlang.

Much older? Wikipedia says[^1][^2] java appeared in 1995 (started in 1991), while python appeared in 1991 (started in late 1980s). 4 years doesn't seem too far apart, considering both language are >30 years old now. [^1]: https://en.wikipedia.org/wiki/Python_(programming_language) [^2]: https://en.wikipedia.org/wiki/Java_(programming_language)

Not only that, but Python had the benefit of doing a very painful break in version 3 (2008), when they had the option to cleaned up almost anything they wanted.

(Some changes in Python 3 I can recall: bytes/str/unicode being the biggest one; fixing mutable variables in nested functions; changing some obscure behavior in class hierarchies and overload resolution; changing things like range() and map() to lazy evaluation.)

For better or for worse, Java has maintained very good (not perfect) compatibility throughout, even with painful changes like generics in 1.5, lambdas in 8, modules in 9, eventual removal of applets and SecurityManager, etc. This also contrasts with C#/.NET, which I think had some breaking changes over the decades.

Re: Opaque Types in Python

#35

Post by zem »

jnwatson wrote: post #3

You're holding it (Python) wrong. Python OO was a counter reaction to the bondage and discipline that languages like C++ had with private members and protected inheritance. If you have members that users probably shouldn't touch, you prepend them with an underscore. This is just a hint; It doesn't actually change anything. We're all adults here and we know the consequences of reaching into implementation details.

nothing is stopping adult users from disabling the type checker and using your internal type directly. the newtype is just a private class mechanism that comes with better tooling to validate that you aren't breaking the intended contract.

Re: Opaque Types in Python

#36

Post by [deleted] »

jnwatson wrote: post #3

You're holding it (Python) wrong. Python OO was a counter reaction to the bondage and discipline that languages like C++ had with private members and protected inheritance. If you have members that users probably shouldn't touch, you prepend them with an underscore. This is just a hint; It doesn't actually change anything. We're all adults here and we know the consequences of reaching into implementation details.

[deleted]

Re: Opaque Types in Python

#37

Post by alanwreath »

anon7725 wrote: post #28
nayuki wrote: post #26

Earlier quoted context omitted.

(I'd like to note that I wrote a lot of code in Java and Python, and continue to use each language in its respective strong areas. This isn't meant as a drive-by attack of "Java r00lz, Python sux"; this is an experienced take.) My real problem with the evolution of Python is that initially, the language and the community was positioned as anti-Java, anti-big-OOP-like-C++, and then it changed into the thing that it wa…

> so I'm pretty sure the new preferred way is to explicitly use abstract superclasses... just like Java did all along (and is mandatory). typing.Protocol is a good fit for this use case from typing import Protocol class HasMessage(Protocol): def get_message(self) -> str: ... class A: """Implicit (duck-typed)""" def get_message(self) -> str: return "A" class B(HasMessage): """Explicit""" def get_message(self) -> str:…

Are you ever supposed to inherit from the protocol though(unless you’re defining another protocol)? One of the great things about protocols is that your class doesn’t even have to know about the protocol explicitly. What this code looks closer to doing (style wise) is an abstract base class

Re: Opaque Types in Python

#38

Post by alanwreath »

nayuki wrote: post #26
zephyrthenoble wrote: post #15

Earlier quoted context omitted.

I agree that these are implemented "worse" than Java but that's because Python wants these things to be optional! You can complain about it as much as you want but that just means it's the wrong language for you, if that's important to you.

(I'd like to note that I wrote a lot of code in Java and Python, and continue to use each language in its respective strong areas. This isn't meant as a drive-by attack of "Java r00lz, Python sux"; this is an experienced take.) My real problem with the evolution of Python is that initially, the language and the community was positioned as anti-Java, anti-big-OOP-like-C++, and then it changed into the thing that it wa…

Let it out co-internet programmer. It’s ok. The pain is real. We both love and hate our languages. It’s natural and healthy.

Re: Opaque Types in Python

#39

Post by 1-more »

ddavis wrote: post #4
jnwatson wrote: post #3

You're holding it (Python) wrong. Python OO was a counter reaction to the bondage and discipline that languages like C++ had with private members and protected inheritance. If you have members that users probably shouldn't touch, you prepend them with an underscore. This is just a hint; It doesn't actually change anything. We're all adults here and we know the consequences of reaching into implementation details.

I agreed with this 100% for a long time. Then I started working on a library at $WORK with dozens of downstream users abusing the hell out of my idiomatic underscore usage, especially in the context of lazy tests with folks writing endless mocks. When I’d “break” their test suite (blocking some time sensitive release) I’d get all kinds of shit. But _they_ were breaking the contract. Unfortunately I had little (if any…

My secret for test-only code is to provide functions whose first argument is a value that only exist in a test scenario. There are also static analysis rules for the linter in my language of choice that disallows test-only functions being called outside of test files. This gets you closer to "we're actually adults here" but still a tiny bit cheatable.

Re: Opaque Types in Python

#40

Post by dec0dedab0de »

prerok wrote: post #33
jnwatson wrote: post #3

You're holding it (Python) wrong. Python OO was a counter reaction to the bondage and discipline that languages like C++ had with private members and protected inheritance. If you have members that users probably shouldn't touch, you prepend them with an underscore. This is just a hint; It doesn't actually change anything. We're all adults here and we know the consequences of reaching into implementation details.

Are we, though? No offence but if an external module starts calling an internal function they better prepare a PR that changes the internal (yes, I know, by convention) to a public one. This is a signal to the developers of that module that they have to maintain the behavior. That PR might well be rejected. And you have to work with the module owners to get your case supported. Anything else is not responsible and I…

or they could just test and maintain the hack on their own.
Post reply on HN