Hello,
I published a package on PyPI:
with source code on GitHub:
It extends common collection types with immutable empty instances.
I’m thinking it may be a good idea to have a type system that allows to declare when:
My package suits my need but it could definitely be improved or even integrated in Python.
Thanks for reading me, best regards,
Laurent Lyaudet
You might be interested in looking into Phantom types which can be used for modelling sizes of immutable collections. There’s been previous discussions on typing-sig about modelling mutability with the type system. I still think that could be valuable but the prior discussion did not seem to gain much traction.
Thank you very much. I just read your README.md and your docs (and submitted a PR for a small typo). I like your approach but it needs that the “container” is sized to define emptyness. I’m thinking it should be the other way around, like an __empty__(self) -> bool mandatory method for “empty-testable” “container”. I think that there may be cases where you cannot define such a method because it would “consume an element of the container/iterable”, but these cases would be very niche. An even more niche case would be sized containers that are not “empty-testable”. I’m trying to look at the combinations and see if it makes sense for a particular use case. Maybe Python could neglect some cases and say that a sized container/iterable must be “empty-testable”. Maybe by automatically expanding the class with def __empty__(self) -> bool: return self.__len__() == 0 when possible.
Is there some specific use case you have in mind for this? I find it a bit hard to understand where the value in having a separate dunder method for emptiness would be, over the existing __len__. What justifies defining “emptiness” as something other than len(x) == 0?
If your proposing for static type checkers to be able to reason about this “emptiness” property, I don’t think it will be possible to define reasonable semantics without limiting the scope to immutable data types, and that already eliminates many non-sized iterables such as generators. I don’t think further limiting to Sized would make much of a difference.
The value is that from an inclusion order point of view, if you have a container/iterable, the first step is to know if it is empty, and then a further step is to know it’s exact length. Similar to some old human languages where numbers above a certain threshold are “not representable”. I’m just trying to put things in order, but I do not pretend that there would be sensible use cases apart of immutable empty objects. This is my point of view. I can understand it is not shared by many people.
I could invent some use case like a sell orders list. Every day before 17 h, your customers may tell you if they will put an order for tomorrow, and the final quantity for the order is known after 19 h. So between 17 h and 19 h, you can test __empty__() but not __len__(). This is totally made up, but you see the idea.