See also rsplit(':', 1). But instead of either of those, you should really be using library functions that already understand the format in question instead of making up your own rules.

  >>> u = urllib.parse.ParseResult('', '[2001:0db8:f00f::0553:1211:0088]:10443', '', '', '', '')
  >>> u.hostname
  '2001:0db8:f00f::0553:1211:0088'
  >>> ipaddress.ip_address(u.hostname)
  IPv6Address('2001:db8:f00f::553:1211:88')
  >>> u.port
  10443

Urllib? There has to be a better choice than that. I've been using inet_ntop and pton to canonically convert bare IPs in to sane forms.

What's the problem with urllib for this purpose?

It'll fail you with port vs. no port.

1234::5678:9876 is ambiguous. Is 9876 a port or part of the address?

The common explicit format is [1234::5678]:9876/

If you don't know if it has a port or not in advance, how can you know the last :thing is not part of the IPv6 address deterministically? If you luck into a four digit port, and the address has :: maximal compression you're SOL.

I have exclusively done this :-1 knowing I had a port.

Not all sources (tcpdump) use your canonical form.

You should read TFA.

I did. It basically said to change your input stream to avoid the problem. Not all data sources can be changed. If you don't have canonically parsable inputs, then assumptions don't work and you can't predict if an add::d:ress is with or without the :port syntax, a priori unless you know the input stream.

So between your input and your parsing library you should put a bit of code to clean up the incoming data. Don’t create a library that processes incorrect data because at some point someone will absolutely try to use it to parse different input data and it will cause problems.

Don't do ad-hoc string parsing. This case is going to explode on ipv4-mapped addresses with dot notation for the last 32bits.

https://tools.ietf.org/html/rfc4038#section-4.2

Yes. It's a weak-as expedient. I've managed to avoid mapped in the last few years.