I'm sorry but if you write Python functions/methods in camel case I can't take you seriously.
Just fyi, the author is https://en.wikipedia.org/wiki/Glyph_Lefkowitz, creator of Twisted.
Opaque Types in Python
11–20 of 61 posts
Re: Opaque Types in Python
#12Re: Opaque Types in Python
#13You'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…
There’s always the extra idiomatic __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED for coworkers that can’t take a hint.
Re: Opaque Types in Python
#14Java 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 standand library documentation; __init__() doesn't force you to call super() whereas it's mandatory in Java; @override (Python 3.12; year 2023) copying Java @Override (JDK 1.5; year 2004) very late; convention changing from duck typing (always available in Python) to structural typing (optional in Python, mandatory in Java).
Re: Opaque Types in Python
#15Java 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…
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.
Re: Opaque Types in Python
#16Funny, I ran into the same pattern just a few months ago! In practice, I found it difficult for coworkers to read and understand so I dropped the idea. Another limitation I found is that it breaks down when you start using inheritance. For example: ``` class _A: pass A = NewType("A", _A) class _B(_A): pass B = NewType("B", _B) def foo(a: A) -> None: pass b = B(_B()) foo(b) # Mypy is not happy: Argument 1 to "foo" has…
(On Hacker News you can do code blocks by indenting each line with two spaces.)
Re: Opaque Types in Python
#17Why not just use a dictionary, or why not just leave the type unannotated? If you really can't (or don't want to) say anything about the type, then don't. Python is dynamically typed!
Re: Opaque Types in Python
#18Earlier quoted context omitted.
Just fyi, the author is https://en.wikipedia.org/wiki/Glyph_Lefkowitz , creator of Twisted.
Seems like this is even more reason to set a good example and follow the style guide.
Twisted has had its own style guide for decades: https://docs.twisted.org/en/stable/development/coding-standa...
(Earliest mention I could find for camelCase methods was 25 years ago: https://github.com/twisted/twisted/blob/d7c19cd40d07c8c37f85... )
Re: Opaque Types in Python
#19Earlier quoted context omitted.
Just fyi, the author is https://en.wikipedia.org/wiki/Glyph_Lefkowitz , creator of Twisted.
Seems like this is even more reason to set a good example and follow the style guide.
Maybe, but the position to not listen to him at all because he doesn't do that is still a much worse look in my book.
Re: Opaque Types in Python
#20Earlier quoted context omitted.
Seems like this is even more reason to set a good example and follow the style guide.
Twisted has had its own style guide for decades: https://docs.twisted.org/en/stable/development/coding-standa... (Earliest mention I could find for camelCase methods was 25 years ago: https://github.com/twisted/twisted/blob/d7c19cd40d07c8c37f85... )
> get_someAttribute
Hell no