If you do this, I urge you to add lots of comments explaining what and why you are doing it. All this is relatively new and will be very confusing to the people reading your code.
Actually, zope.interface has been around for 20 years.
It just became almost abandoned like the rest of Zope with the era of Django/Flask (and the zope 3 debacle).
Nowadays I think Twisted, Pyramid and Plone are the only "famous" projects left using it
That is true, but I think there was a point in time (2000-2001?) where Zope was very much the dominant python web framework, and the Zope foundation employed many python core developers.
well, it was more or less the same thing as the python3 debacle. Imagine having a big python2 project and all the cool stuff is happening in python3. You can't upgrade without substantial effort (code & testing). Now replace python2 with zope2 and python3 with zope3. You get the idea.
It's also used by certbot, pyjwt, ckan, proxy.py, scrapy, etc. The list is pretty long but I do agree with you that the majority of packages neither use nor should use it.
I’d urge lots of comments if you’re using anything that might lead the reader in the direction of Twisted, which has the most impenetrable documentation of any Python library I’ve ever seen.
The stuff that `zope.interface` gets you is honestly on the... heavy side of what I think makes sense for a lot of scenarios (especially in Python). Which would explain it's relatively low uptake despite having been around for like... 15-20 years??
I haven't used `typing.Protocol` yet (I am mostly still working in 3.7), but it seems to roughly capture the level of 'heaviness' that seems workable.
I do get your gist though. Sometimes I wonder what I'm doing type annotating stuff.
> I do get your gist though. Sometimes I wonder what I'm doing type annotating stuff.
I have to say, I despise trying to decipher untyped functions. This arg is called "order" - do you want an instance of Order, an order ID, or a function for sorting?
Fine, I'll read the docstring. Instead of using the IDE.
GraalVM (and SubstrateVM) is actually fixing a lot of these; I had a short-lived process that I AOT compiled with SubstrateVM, and I spent a lot of time checking I had done it right and not somehow accidentally compiled in my input data as well or something -- I got a two order of magnitude speedup, with fewer than ten lines of code change.
Then you get different issues including more obscure and untested systems. I responded to someone asking why not use Java. I answered it. Please don't try to change the question after the fact when you don't like the answer.
I know you're trying to pin me as being rude, but no. Your answer is bad and ad-hoc. Just because a language is not Java does not make it magically untested and obscure. Just use Go tbh.
Edit: Okay I see the original guy stated Java. It is what it is. The real useful answer is to just use any other typed language, and not use Python.
Java's punishing startup times is not a red herring, and I'm dumbfounded someone in a forum like HN makes such a claim. Even in serverless applications like AWS Lambda, python and javascript enjoy execution times that are an order of magnitude faster than Java ones, even with hot starts and stuff initialized a priori.
The idea of an interface is fundamental to computing. No matter what you do, at the end of the day data exchanged between two systems has to be structed _some how_. E.g., machine code submitted to the CPU, register configurations, C ABI, Python structures, JSON. You _could_ be hand wavy about it, maybe even use machine learning, but then it will just be ambiguous and lead to vulns. IMO the constant insistence to try and find ways around this is a huge setback. I used Python heavily in 2008 and always was annoyed when trying to figure out the essence of an API (which is what you get when there is no concrete interface). Whenever I read a Python codebase, unsurprisingly, it's full of handwaving and the resultant bugs (some people know what they're doing, but the problem is there more than in a typed language).
It's the first time I hear about Zope, and also zope.interface. How widely is this used?
I personally would be hesitant to adopt something depending on some not-well-known library.
Then on the other side, if sth like interfaces are missing in core Python, and typing.Protocol is not quite the same thing, maybe we should try to extend the core typing for sth like typing.Interface?
Or maybe first to typing_extensions.
Or, as I understood it, maybe we just need to fix ABCMeta (for MyPy), and then already have what we want?
I'm also not quite sure I understood: Why do I need this base class zope.interface.Interface at all? Why not just implement IPlugin or whatever like it is mentioned there, but not deriving from Interface, and throw NotImplementedError in methods (tools like PyCharm then recognize this is an abstract method). And all concrete types/classes just explicitly need to derive from this IPlugin class. That's mostly what I anyway do already, and what I also see in other projects code. This approach seems to be fine. What's the problem with it?
I was a bit surprised to see zope.interfaces pop up these days. If you are not using the entire Zope Component Architecture I'm not sure how useful it has been since Python 3.
Zope and things build on top of it (Plone CMS e.g.) was fairly popular in the early-mid 2000s and was in my opinion ahead of it's time in many ways. But also overkill for most projects.
I discovered Zope in late 2000 while looking for an open source web application platform. Somehow I heard about Zope and thus learnt Python version 1.5.
Zope seemed to be on the cusp of greatness. The Zope conference in Paris in early 2001 was my first tech user group meeting. (Was anyone else reading this there?)
I stopped with Zope in 2003. Then 7 years later got a strange sense of deja vu at a bank I joined, where its trading platform used a Python object database possibly inspired by Zope's ZODB.
IMO, protocols are way better than interfaces. They're essentially the same, except you don't need to inherit from a protocol for your object to be compliant.
Thanks for writing that. I need to use Python fairly often, even though I self identify as a Lisp developer. I found the discussion of checking structure with Protocols very useful. I am going to update my current project.
With the growing use of mobile devices, minimalism is on the rise. Minimalism brings additional benefits to apps and websites, in the shape of faster loading times and better compatibility between screen sizes. Beautiful minimalist apps combined with great usability are really impressive: an easily navigated, simple app is a very powerful form of communication. Read more what should you know to create a minimalist website
https://steelkiwi.com/blog/best-practices-for-minimalist-web...
42 comments
[ 2.8 ms ] story [ 90.5 ms ] threadIt's even mentioned in the history of python https://docs.python.org/3/license.html
When I had to explain it to clients I joked it suffered from “Martian Technology Syndrome”.
https://github.com/zopefoundation/Zope/network/dependents?de...
Java has all the strong typing and static checking, all you need is to type a lot more words.
The stuff that `zope.interface` gets you is honestly on the... heavy side of what I think makes sense for a lot of scenarios (especially in Python). Which would explain it's relatively low uptake despite having been around for like... 15-20 years??
I haven't used `typing.Protocol` yet (I am mostly still working in 3.7), but it seems to roughly capture the level of 'heaviness' that seems workable.
I do get your gist though. Sometimes I wonder what I'm doing type annotating stuff.
You can use it if you install the typing-extensions package: https://pypi.org/project/typing-extensions/
I have to say, I despise trying to decipher untyped functions. This arg is called "order" - do you want an instance of Order, an order ID, or a function for sorting?
Fine, I'll read the docstring. Instead of using the IDE.
as for other stuff (web-servers, what not), I don't think python can beat kotlin / typescript / etc
Situations where you don't want the heavy-weight and complex JVM.
Cases where you need to interact with C/C++ code a lot (ML, etc.).
Companies where python is the norm and introducing another language adds a lot of overhead.
Edit: Okay I see the original guy stated Java. It is what it is. The real useful answer is to just use any other typed language, and not use Python.
I personally would be hesitant to adopt something depending on some not-well-known library.
Then on the other side, if sth like interfaces are missing in core Python, and typing.Protocol is not quite the same thing, maybe we should try to extend the core typing for sth like typing.Interface? Or maybe first to typing_extensions.
Or, as I understood it, maybe we just need to fix ABCMeta (for MyPy), and then already have what we want?
I'm also not quite sure I understood: Why do I need this base class zope.interface.Interface at all? Why not just implement IPlugin or whatever like it is mentioned there, but not deriving from Interface, and throw NotImplementedError in methods (tools like PyCharm then recognize this is an abstract method). And all concrete types/classes just explicitly need to derive from this IPlugin class. That's mostly what I anyway do already, and what I also see in other projects code. This approach seems to be fine. What's the problem with it?
Which is to say, not widely.
That was around 15 years ago roughly from memory.
Zope and things build on top of it (Plone CMS e.g.) was fairly popular in the early-mid 2000s and was in my opinion ahead of it's time in many ways. But also overkill for most projects.
[1] https://www.ukuug.org/events/linux2001/papers/html/SRichter/...
I discovered Zope in late 2000 while looking for an open source web application platform. Somehow I heard about Zope and thus learnt Python version 1.5.
Zope seemed to be on the cusp of greatness. The Zope conference in Paris in early 2001 was my first tech user group meeting. (Was anyone else reading this there?)
I stopped with Zope in 2003. Then 7 years later got a strange sense of deja vu at a bank I joined, where its trading platform used a Python object database possibly inspired by Zope's ZODB.