singleton ... again

[Roy Smith]

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.