# NOTE: doubled this to 0.2s because of some weird test failures.When I need something like that, in my destructor I usually ask worker thread to shut down voluntarily (using a special posted message, manual reset event, or an atomic flag), then wait for the worker thread to quit within a reasonable timeout. If it didn’t quit within the timeout, I log a warning message if I can.
It's also not even a problem with slow computers or insufficient memory, __init__ does I/O here, it connects to ZeroMQ, so it could have arbitrary latency in various circumstances exceeding the 100 milliseconds that we would be sleeping for. So the joke is, this fixes the problem in your test environment where everything is squeaky clean and you know that ZeroMQ is reachable, and now you have bugs in prod still.
def _init(self):
init_complete = threading.Event()
def worker_thread_start():
FooWidget.__init__(self)
init_complete.set()
self.run()
worker_thread = Thread(target=worker_thread_start, daemon=True)
worker_thread.start()
init_complete.wait()
Normally with a FooWidget you can create one on some thread and then perform operations on it on that thread. But in the case of the FooBarWidget you can not do operations on it because operations must be done in the special thread that is inaccessible.
Except possibly for type checking, but
1. Python has duck typing anyway
2. It's debatable whether these two classes should be interchangeable
3. You shouldn't need to use inheritance just to make the type checking work.
It could be considered a clever hack in some situations, but it's completely unsurprising that it causes issues. Putting band-aids on it after you find a bug does not fix the real problem.
It would have been better to an addition start, run, exec method that does that kind of things. Even if for usage it is an inch more complicated to use with an additional call.
That breaks RAII - you shouldn't give the user a way to create the object in an invalid state. Although if it's intended to be used as a context manager anyway then maybe doing it on context enter rather than on init would be nicer.
Also, it was not supposed to be used in a context manager as there is just a close method but it is the caller that decided to wrap it in a context.
But as what you suggest, indeed it would have been a great idea to add an __enter__ and do the starting there are as it would be the proper way.
A much cleaner way (IMO) to do this is use context managers that have explicit lifecycles, so something like this:
@contextmanager
def create_db_client(host: str, port: int) -> Generator[_DbClient, None, None]:
try:
connection = mydblib.connect(host, port)
client = _DbClient(connection)
yield client
finally:
connection.close()
class _DbClient:
def __init__(self, connection):
self._connection = connection
def do_thing_that_requires_connection(...):
...
with create_db_client('localhost', 5432) as db_client: # port 3306 if you're a degenerate
db_client.do_thing_that_requires_connection(...)
[0] The second is performing "heavy", potentially failing operations outside of functions and classes, which can cause failures when importing modules.
`def __del__`
Also worth noting that the Python spec does not say __del__ must be called, only that it may be called after all references are deleted. So, no, you can't tie it to __del__.
Nope, do not ever do this, it will not do what you want. You have no idea _when_ it will be called. It can get called at shutdown where the entire runtime environment is in the process of being torn down, meaning that nothing actually works anymore.
Maybe it indirectly ensures that only one thread is created per instantiation; there are better ways of achieving that though.
While I enjoy comments like these (and the article overall!), they stand stronger if followed by an example of a solution that regards sanity, common sense and the feelings of others.
The problem still occurs, because you have to define what it means to close a FooBarWidget and I don't think python Thread has a “throw an exception into this thread” method. Just setting the should_exit property, has the same problem as the post! The thread might still be initing the object and any attempt to tweak across threads could sometimes tweak before init is complete because init does I/O. But once you are there, this is just a tweak of the FooWidget code. FooWidget could respond to a lock, a semaphore, a queue of requests, any number of things, to be told to shut down.
In fact, Python has a nice built-in module called asyncio, which implements tasks, and tasks can be canceled and other such things like that, probably you just wanted to move the foowidget code into a task. (See @jackdied's great talk “Stop Writing Classes” for more on this general approach. It's not about asyncio specifically, rather it's just about how the moment we start throwing classes into our code, we start to think about things that are not just solving the problem in front of us, and solving the problem in front of us could be done with just simple structures from the standard library.)
Friends don't let friends build complicated constructors that can fail; this is a huge violation of the Principle of Least Astonishment. If you require external resources like a zeromq socket, use connect/open/close/etc methods (and a contextmanager, probably). If you need configuration, create a separate function that parses the configuration, then returns the object.
I appreciate the author's circumstances may have not allowed them to make these changes, but it'd drive me nuts leaving this as-is.
Rust is the language I'm familiar with that does this exceptionally well (although I'm sure there are others). It's strictly because there are no constructors. Constructors are not special language constructs, and any method can function in that way. So you pay attention to the function signature just like everywhere else: return Result<Self, T> explicitly, heed async/await, etc. A constructor is no different than a static helper method in typical other languages.
new Thing() with fragility is vastly inferior to new_thing() or Thing::static_method_constructor() without the submarine defects.
Enforced tree-style inheritance is also weird after experiencing a traits-based OO system where types don't have to fit onto a tree. You're free to pick behaviors at will. Multi-inheritance was a hack that wanted desperately to deliver what traits do, but it just made things more complicated and tightly coupled. I think that's what people hate most about "OOP", not the fact that data and methods are coupled. It's the weird shoehorning onto this inexplicable hierarchy requirement.
I hope more languages in the future abandon constructors and strict tree-style and/or multi-inheritance. It's something existing languages could bolt on as well. Loose coupling with the same behavior as ordinary functions is so much easier to reason about. These things are so dated now and are best left in the 60's and 70's from whence they came.
As much fun as putting a PEP together might be, I don't think I have the bandwidth to do so. I would really like to see traits in Python, though.
(searching myself.. not much left of it)
2004 - https://simonwillison.net/2004/Mar/23/pyprotocols/
some related rejected PEP .. https://peps.python.org/pep-0246/ talking about something new to be expected.. in 2001?2005?
no idea did it happen and which one would that be..
Further work was done in this area, building on ABCs, with Protocols, original PEP: https://peps.python.org/pep-0544/
The abstract base class should use the @abstractmethod decorator for methods that the implementing class needs to implement itself.
Obviously, you can also use abstract base classes in other ways, but they can be used as a way to define traits/interfaces for classes.
https://typing.python.org/en/latest/spec/protocol.html#proto...
That's the beauty of traits (or "type classes"). They're behaviors and they don't require thinking in terms of inheritance. Think interfaces instead.
If you want your structure or object to print debug information when logged to the console, you custom implement or auto-derive a "Debug" trait.
If you want your structure or object to implement copies, you write your own or auto-derive a "Clone" trait. You can control whether they're shallow or deep if you want.
If you want your structure or object to be convertible to JSON or TOML or some other format, you implement or auto-derive "Serialize". Or to get the opposite behavior of hydrating from strings, the "Deserialize" trait.
If you're building a custom GUI application, and you want your widget to be a button, you implement or auto-derive something perhaps called "Button". You don't have to shoehorn this into some kind of "GObject > Widget > Button" kind of craziness.
You can take just what you need and keep everything flat.
Here's a graphical argument I've laid out: https://imgur.com/a/bmdUV3H
my_variable = MyType()
You are correct that you don't want an object that can be half-initialized. In that case, any external resources necessary should be allocated before the constructor is called. This is particularly true if the external resources must be closed after use. You can see my other comment[0] in this thread for a full example, but the short answer is use context managers; this is the Pythonic way to do RAII.
In python its not unusual that,
import some_third_partylib
People write such shit code, its unbelievable.
I also strongly disagree constructors cannot fail. An object that is not usable should fail fast and stop code flow the earliest possible. Fail early is a good thing.
What you should do is the fallible operation outside the constructor, before you call __init__, then ask for the opened file, socket, lock, what-have-you as an argument to the constructor.
Fallible initialisation operations belong in factory functions.
Nothing about the contract encourages doing anything fallible in __init__
You said it yourself -- if you feel like you have two objects, then literally use two objects if you need to split it up that way, FooBarBuilder and FooBar. That way FooBar is always fully built, and if FooBarBuilder needs to do funky black magic, it can do so in `build()` instead of `__init__`.
class Foo @classmethod def connect(): return Foo()._connect()
The benefit is that we can choose when we're doing 1) object construction, 2) side-effecting 3) both. The downside is client might try use the __init__() so object creation might need to be documented more than it would otherwise
If that call is necessary to ensure that the instance has a good/known internal state, I absolutely think it belongs in __init__ (whether called directly or indirectly via a method).
class MyClass:
def __init__(self, config: str):
self._config = config
def __init__(self, host: str, port: int):
This simple change makes code so much more readable and testable.
1. Keep all of your object–initialization in the main thread (i.e. call super().__init__() synchronously).
2. Defer any ZMQ socket creation that you actually use in the background thread into the thread itself.
smitty1e•5h ago
jerf•5h ago