In article <mailman.6852.1392317509.18130.python-l...@python.org>, Ethan Furman <et...@stoneleaf.us> wrote:
> On 02/13/2014 09:57 AM, Roy Smith wrote: > > In article <mailman.6850.1392313443.18130.python-l...@python.org>, > > Ethan Furman <et...@stoneleaf.us> wrote: > > > >> Say you have a class that represents serial ports or your computer. You > >> should get the same object every time you ask > >> for SerialPort(2). > > > > Why? Certainly, you should get objects which refer to the same physical > > port. So: > > > > port_a = SerialPort(2) > > port_b = SerialPort(2) > > > > port_a.enable() > > assert port_b.is_shutdown() == False > > > > port_a.shutdown() > > assert port_b.is_shutdown() == True > > > > But, why do they have to be the same object? Why should I care if > > > > port_a is port_b > > > > is False, as long as all operations I perform on either are reflected in > > correct state changes on the other one? > > You mean use the Borg pattern instead of the Singleton pattern? As far as I > can tell they are two shades of the same > thing. Are there any drastic differences between the two? Besides one > having many instances that share one __dict__ > and the other just having one instance and one __dict__? I envision SerialPort being a thin layer on top of a bunch of OS-specific system calls to give them a pythonic interface. Things like is_shutdown() and set_bit_rate() presumably turn into ioctls. No need to have any state at all beyond a file descriptor. -- https://mail.python.org/mailman/listinfo/python-list