singleton ... again

Thu Feb 13 14:03:15 EST 2014

In article <mailman.6852.1392317509.18130.python-list at python.org>,
 Ethan Furman <ethan at stoneleaf.us> wrote:
> On 02/13/2014 09:57 AM, Roy Smith wrote:
> > In article <mailman.6850.1392313443.18130.python-list at python.org>,
> > Ethan Furman <ethan at 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.