| 2741 | # Remote PDB |
| 2742 | |
| 2743 | class _PdbServer(Pdb): |
| 2744 | def __init__( |
| 2745 | self, |
| 2746 | sockfile, |
| 2747 | signal_server=None, |
| 2748 | owns_sockfile=True, |
| 2749 | colorize=False, |
| 2750 | **kwargs, |
| 2751 | ): |
| 2752 | self._owns_sockfile = owns_sockfile |
| 2753 | self._interact_state = None |
| 2754 | self._sockfile = sockfile |
| 2755 | self._command_name_cache = [] |
| 2756 | self._write_failed = False |
| 2757 | if signal_server: |
| 2758 | # Only started by the top level _PdbServer, not recursive ones. |
| 2759 | self._start_signal_listener(signal_server) |
| 2760 | # Override the `colorize` attribute set by the parent constructor, |
| 2761 | # because it checks the server's stdout, rather than the client's. |
| 2762 | super().__init__(colorize=False, **kwargs) |
| 2763 | self.colorize = colorize |
| 2764 | |
| 2765 | @staticmethod |
| 2766 | def protocol_version(): |
| 2767 | # By default, assume a client and server are compatible if they run |
| 2768 | # the same Python major.minor version. We'll try to keep backwards |
| 2769 | # compatibility between patch versions of a minor version if possible. |
| 2770 | # If we do need to change the protocol in a patch version, we'll change |
| 2771 | # `revision` to the patch version where the protocol changed. |
| 2772 | # We can ignore compatibility for pre-release versions; sys.remote_exec |
| 2773 | # can't attach to a pre-release version except from that same version. |
| 2774 | v = sys.version_info |
| 2775 | revision = 0 |
| 2776 | return int(f"{v.major:02X}{v.minor:02X}{revision:02X}F0", 16) |
| 2777 | |
| 2778 | def _ensure_valid_message(self, msg): |
| 2779 | # Ensure the message conforms to our protocol. |
| 2780 | # If anything needs to be changed here for a patch release of Python, |
| 2781 | # the 'revision' in protocol_version() should be updated. |
| 2782 | match msg: |
| 2783 | case {"message": str(), "type": str()}: |
| 2784 | # Have the client show a message. The client chooses how to |
| 2785 | # format the message based on its type. The currently defined |
| 2786 | # types are "info" and "error". If a message has a type the |
| 2787 | # client doesn't recognize, it must be treated as "info". |
| 2788 | pass |
| 2789 | case {"help": str()}: |
| 2790 | # Have the client show the help for a given argument. |
| 2791 | pass |
| 2792 | case {"prompt": str(), "state": str()}: |
| 2793 | # Have the client display the given prompt and wait for a reply |
| 2794 | # from the user. If the client recognizes the state it may |
| 2795 | # enable mode-specific features like multi-line editing. |
| 2796 | # If it doesn't recognize the state it must prompt for a single |
| 2797 | # line only and send it directly to the server. A server won't |
| 2798 | # progress until it gets a "reply" or "signal" message, but can |
| 2799 | # process "complete" requests while waiting for the reply. |
| 2800 | pass |
no outgoing calls
searching dependent graphs…