Bug report
Generally, python can handle any number (up to 2 ** 32 - 1, actually) of targets in a list or tuple.

With a starred assignment, the numbers of expressions both before and after the * are limited, to 255 and 2**24 - 1, resp.. This is a consequence of the implementation of UNPACK_EX in ceval.c.

I assert that this should be fixed, because someday somebody will try to generate some Python code with many assignment targets and a trailing * target, and then their code will not compile!
Example
With 256 targets before the *, you get the following:

>>> exec(f'{"x," * 256}*y = range(258)')
SyntaxError: too many expressions in star-unpacking assignment

The outcome should be:

>>> exec(f'{"x," * 256}*y = range(258)')
>>> x
255
>>> y
[256, 257]

Proposed fix
I would propose a new bytecode, UNPACK_EX_TOP UNPACK_STAR_POS (or whatever), where the oparg is the count after before the *, and TOS is the count before the *. This will always be followed by UNPACK_SEQUENCE where oparg is the total number of targets, including the *. The compiler would emit:

LOAD_CONST before-count
EXTENDED_ARG ... if necessary for an after-count >= 256
UNPACK_EX_TOP after-count

UNPACK_STAR_POS (before-count)
UNPACK_SEQUENCE (before-count + 1 + after-count)
(with EXTENDED_ARG's as needed)

The interpreter will get the before-count from UNPACK_STAR_POS and then process the UNPACK_SEQUENCE as though it were an UNPACK_EX with the same before-count and after-count.

I also suggest that the normal cases, with up to 255 targets before the *, be handled as they are now, just to not break bytecode analysis programs that don't yet know about the new bytecode. The generated code is the same length as what I propose above, and doesn't involve adding a constant:

EXTENDED_ARG after_count.
UNPACK_EX before-count

Please see my subsequent comment for tips on how to implement this.