Bug? in rs.AddGroup(name) when group name already exists

I ran into this just now and it’s confusing to say the least.

Run the following script in a new Rhino file with nothing in it.

import rhinoscriptsyntax as rs

for i in range(5):
    gn="Itemnumber {}".format(i)
    group_name=rs.AddGroup(gn)
    print group_name

The first time you run it, no problem, you will get this:

Item number 1
Item number 2
Item number 3
Item number 4
Item number 5

Run it however a second time and you will get this:

Item number01
Item number02
Item number03
Item number04
Item number05

Run it a third time and you get this:

Item number06
Item number07
Item number08
Item number09
Item number10

etc.

Funny thing is that I have not added anything to these groups, so running SelGroup shows a blank dialog. I guess that’s sorta normal though…

And why on earth did it take my “Item number” text, strip the original number and then start adding numbers to the end? It should, by default, just automatically give me Group 01, Group 02, etc. My feeling is that the algorithm behind the default numbering is getting confused, it finds an already used name but it isn’t looking for a “Group nn” format, it simply finds a name with a number at the end, says Eureka!, strips that number off and adds a new number.

What it should do:

First run OK
Second run:

Item number 1 01
Item number 2 01
Item number 3 01
Item number 4 01
Item number 5 01

Third run:

Item number 1 02
Item number 2 02
Item number 3 02
Item number 4 02
Item number 5 02

etc.

Worst is it also strips out the space so even if it was working correctly it might result in this:

Item number 102
Item number 202
Item number 302
Item number 402
Item number 502

Which could be REALLY confusing.

OK, lesson learned, I need to check for the existence of a group name before adding a new group with that name. Plus for now I will not number groups with the number at the end of the name. And maybe even run a routine to clear all empty groups before starting.

Note that the following “workarounds” fail with the same problem:

gn="Panel number {}.".format(i)
gn="Panel number {},".format(i)
gn="Panel number {}-".format(i)

It’s still trying to resolve a number and “,” or “.” can be a decimal, I guess. I was surprised that the “-” was considered as well, but not “+”.
But any other character after the number seems to make it behave correctly:

gn="Panel number {}|".format(i)
gn="Panel number {}!".format(i) 
gn="Panel number {}#".format(i)
gn="Panel number {}*".format(i)
etc.

Just a heads-up if anyone is interested in using or fixing this…

Thanks, I’ll get this onto the heap.

-Pascal

I do not get this - on the first & second runs I see

Itemnumber 0
Itemnumber 1
Itemnumber 2
Itemnumber 3
Itemnumber 4

Itemnumber01
Itemnumber02
Itemnumber03
Itemnumber04
Itemnumber05

Still not what’s wanted but maybe less wrong, somehow. After the second run it carries on incrementing in the second style. I’ll put it on the pile.
RH-70706 RhinoscriptSyntax - adding named groups

The algorithm removes these characters (-_,.0123456789) from the end before making it unique with a new suffix.

It’ll remove spaces from the end even if the name is already unique. Probably to prevent having “G” and "G " as 2 different names.

The counter also keeps incrementing even if you continue with a completely new group name.

I does seem strange but I think the intent is to guarantee uniqueness without caring about the meaning.

It’s easy enough to change it so it generates this:

Itemnumber 0
Itemnumber 1
Itemnumber 2
Itemnumber 3
Itemnumber 4

Itemnumber 001
Itemnumber 101
Itemnumber 201
Itemnumber 301
Itemnumber 401

Itemnumber 002
Itemnumber 102
Itemnumber 202
Itemnumber 302
Itemnumber 402

But some spaces still get removed and the problem of the counter that still keeps incrementing.

I think that if you care about more than uniqueness it’s better to generate your own names to get exactly what you want.