Just came across this one (Terry I'm sure can figure out why).

I'm sympathetic with Guilherme's wish that Tk had done this one differently, as an option to specify an existing text widget peer when creating a text widget, rather than having the original spawn a new widget. It probably has something to do with specifying a "-peer" option that you couldn't later change via "configure".

As Gregory's peerfix.diff indicated, the original Python API for this command is wrong, or at least at odds with all the rest of Tkinter. The one required argument should indeed be the parent (master) for the new peer, and not it's widget path name. The call should return the new Text widget object.

Given that nobody can be using the (unpatched) call as it is not functional, I suggest this be changed, without regard to backward compatibility concerns.

The other issue that Gregory raises is the peer being an instance of a Text subclass, e.g. _textpeer, rather than Text itself. While I'm not certain, I suspect this could likely be an issue in practice.

If it's somehow possible to create it as an instance of Text, that would definitely be preferable. I haven't closely examined BaseWidget et al., but I wonder if a hack along these lines might be possible:

 1. Create a new Text widget under the parent (call it 'dummy')
 2. Generate a new widget name (or used a passed in 'name' cnf parameter as usual)  to be used for the peer text widget
 3. Call the underlying 'peer create' with our generated name to create a new text widget on the Tcl side
 4. Modify dummy._w to use the generated name
 5. Replace the original parent.children[dummy._name] entry with one for the newly generated name
 6. Call into Tcl to destroy the dummy Text widget

It didn't look to me like there would be more housekeeping that needed doing to effectively point a widget object at a different widget.

The overhead of temporarily creating the extra Text widget should be negligible in practice.

If this seems like a feasible approach I can try to code it up.